Мы учили продукт, продукт учил нас

Хорошо, когда ты пишешь с рождения продукта и можешь придумывать всё с нуля. Но чаще будет не так. Будут продукты, в которых кто-то уже годами писал до твоего прихода. Будет наследие, с которым придётся что-то делать. И если дать слабину, наследие победит. Чем больше продукт, тем сильнее его влияние.

Тут есть две крайности. Можно бросаться на амбразуру и менять всё на корню. Но тогда рискуешь поломать то, что было всё-таки ок. Допустим, кривоватые формулировки, к которым пользователи привыкли настолько, что не поймут, если написать по-другому. Другой вариант: сдаться и просто делать в том же духе, что и раньше. Но зачем тогда ты?

Думаю, умение взаимодействовать с тем, что делали до тебя, не ломая дров, но и не прогибаясь, — важный навык в любой творческой профессии: дизайнера, UX-писателя, да даже кондитера.

Возвращение

Всем привет! За время отсутствия я сделал две крайне важные для меня вещи — закончил британку и сменил работу. Этим и была обусловлена пауза на канале, но теперь я полон решительности завершить начатое и рассказать чем закончилась история моего обучения.

На чем мы остановились?
Оборачиваясь назад хочется отметить, что защита прошла очень неплохо. По ощущениям у нас не было идеального проекта и команды, но нам удалось правильно расставить акценты и в итоге презентация выглядела как законченная история. Но об этом чуть позже.

В ближайшие дни я разберу историю нашего проекта до конца (да да, это будет потерявший актуальность рассказ про исследование и работу над визуальной концепцией), но зато после я расскажу непосредственно про сам процесс обучения, а также попрошу дать такую же обратную связь ещё нескольких одногруппников. Так что если вы сейчас думаете о том, стоит ли идти в британку, то эта информация будет для вас полезна.

Прежде чем продолжить, для самых искушенных быстрые ссылки на прошлые серии:

Про бриф, особенности бизнес модели и большое легаси профиру — https://t.me/bukhtiyar/88

Дальше история продолжается рассказом о том, как мы примеряли сервис на себя и познали проблему курицы и яйца — https://t.me/bukhtiyar/88

Ну и как же без классической истории поиска решения — взяться за все проблемы сразу, чтобы в итоге найти одну самую большую и важную — https://t.me/bukhtiyar/88

А дальше я начал рассказ о том какие исследования мы провели и какие инсайты получили. Успел затронуть историю нашего заказа качестве клиента профиру, а также о том насколько непросто выманить мастеров для интервью — https://t.me/bukhtiyar/112

Закончилось все на предательском «Про полученные инсайты и конкурентов расскажу завтра.» 😂
Ну и вот спустя два месяца пожалуйста — история про конкурентов.

Вы правы, мало кто пройдет по ссылкам, поэтому вот, совсем краткий синопсис предыдущих серий:

Погрузившись в тему мы решили сфокусироваться на проблемах специалистов, так как в сервисе давно назрел вопрос о том, чтобы улучшить их пользовательский опыт.
Это связано с желанием снизить порог входа, чтобы привлечь больше специалистов в сервис, а также с переходом к модели обратного аукциона, чтобы автоматизировать процессы и отказаться от армии администраторов.

Хочу с вами сегодня поделиться несколькими правилами, которые помогают держать мой календарь (и встречи) под контролем.

1. У нас в команде есть no meetings Wednesday - день без встреч. Это договоренность с командой, что в этот день встречи мы не назначаем и полностью блокируем день. Очень крутая штука для фокуса! Важно, что такая традиция должна уважаться не только другими людьми в вашей компании, но и вами самим: если вам прилетает приглашение на этот день, обязательно спрашивайте – насколько это срочно? В большинстве случаев люди спокойно готовы подождать несколько дней.

2. Я также блокирую как минимум один часовой слот в день под сфокусированную работу и бронирую "встречи" на то время, когда я недоступна (например, с 6 до 10 вечера). Еще лучше, если на то время, когда вы хотите уходить с работы, у вас стоит какое-то занятие (например, спорт).

3. В пятницу вечером я смотрю на свое расписание на следующей неделе и стараюсь, чтобы все встречи организовывались в блоки. Если у вас 3 встречи и между ними по получасовому перерыву, это крайне непродуктивно: скорее всего, все эти перерывы вы либо будете прокрастинировать (так как не сможете быстро переключить контекст), либо сделаете какие-то мелкие дела типа проверки почты. Если же переставить встречи в один полуторачасовой блок, у вас появится дополнительный час, который можно потратить уже на более крупные задачи.

4. Я никогда не участвую во встречах, где непонятна повестка и ценность от моего участия. Если прилетает приглашение типа "Анна-Антон" или "Проект Х", я всегда отправляю автоматический ответ – а какая цель у этой встречи и зачем я вам там нужна? Удивительно, но часто этот вопрос приводит к тому, что вся встреча отменяется, и вопрос решается в другом формате (через чат или таски, например).

5. Дефолтная продолжительность моих встреч - 25 минут; 5 минут на то, чтобы осмыслить action items и переключить контекст на следующий митинг.

6. Если вы идете на встречу, уважайте своих коллег: будьте вовлечены в дискуссию, не сидите в телефоне и закройте-таки свой ноутбук.

@proproduct

Действие, не состояние

Всегда, когда мы что-то пишем в интерфейсе, мы хотим повлиять на то, что пользователь сделает дальше. Именно поэтому информацию по возможности лучше переводить в формат: «сделайте», а не сообщать факт и ждать, что человек сам разберётся.

Неизвестная ошибка

Кажется, что просто сообщили информацию. Но мы же сделали это для какой-то цели? Наверное, чтобы пользователь сделал какое-то действие с этой информацией: обратился в поддержку, вернулся на предыдущий этап и больше не пытался или чтобы попробовал снова.

То есть мы предполагаем действие, но не говорим его. Почему бы тогда не сказать прямо:

Ошибка — попробуйте ещё раз или напишите нам

Или вот вы тест с несколькими вариантами на выбор. Если пропустить, появляется красненькая надпись:

Не выбрано ни одного пункта

Вроде пытаемся что-то донести, но что — еще надо додумать. Почему бы не избавить пользователя от лишних додумываний?

Выберите хотя бы что-то

Действует практически во всём. Попробуйте еще раз и напишите, если не получится.

Иногда нужно обойти дерево узлов

Например, чтобы найти родительский элемент и заменить его содержимое, или найти соседний элемент и переключить на него фокус.

Для этого есть набор методов:

let el = document.querySelector(".someClass")
el.childNodes // дочерние элементы
el.nextSibling // сосед справа
el.parentNode // родительский элемент

Подробнее в видео: https://youtu.be/MoEWUWIDFDs

И в примере с кодом: https://codepen.io/detepr/pres/mQqKZO


✨Домашнее задание ✨

Взять пример из урока: https://codepen.io/detepr/pen/rQYYbx
1. Посчитать сумму цен всех подарков и вывести её в консоль
2. Отсортировать подарки по цене

Шейн Дойл написал о неидеальных состояниях интерфейса.

Многие дизайнеры проектируют только идеальное состояние, когда всё отображается корректно и контент идеален. Но есть ещё состояния:

  1. Пустое: контент ещё не добавлен, нулевые результаты поиска, пользователь удалил контент.
  2. Загрузка: когда загружается контент или выполняется какое-то действие. Важно донести до пользователя, что программа не зависла.
  3. Частичная наполненность: когда есть только часть контента. Подумайте, как помочь пользователю сделать так, чтобы получить идеальное состояние.
  4. Неидеальное: слишком длинный или короткий текст, изображения в неправильном формате или отсутствуют, нет части контента. Пользователь не должен думать, что программа сломалась.
  5. Интерактивное: фокус на элементе, заполнение поля и другие изменения интерфейса после взаимодействия с пользователем.
  6. Ошибка: нет подключения к сети, пользователь сделал что-то не то, системная ошибка. Важно, чтобы пользователь понимал суть ошибки и что ему делать.
  7. Выполнение действия: когда пользователь справился со своей задачей. Состояние может отличаться для разных пользовательских задач.

https://ux.pub/proektirovanie-razlichnyh-sostoyaniy-interfeysa/