Бывает, сервисы прикидываются добрыми друзьями, пока платишь.

А как только перестаешь платить, переобуваются и переходят к формализму и снисходительному тону.

Те, кто не платит, всегда могут вернуться и заплатить. А когда они возвращаются, это отличный шанс напомнить, как хорошо было вместе и показать кратчайший путь.

Netflix остаются друзьями до конца и держат тональность и с теми, кто не платит. Давай, говорят, обновим платежную инфу и будем снова наслаждаться. Приятно.

Чтобы не прогадать, можно вообще не прикидываться другом и всегда держаться нейтрально, как Apple Music.

Как генерировать идеи для продукта

Внешние источники:

1. Тренды в вашей индустрии: что происходит на рынке
2. Что делают конкуренты
3. Какие фичи просят пользователи конкурентов
4. Что делают похожие бизнесы на других рынках (например, Amazon vs InstaMart in India)
5. Что обсуждают на конференциях/форумах/спец ресурсах в вашей индустрии
6. Какие фичи просят ваши пользователи

Внутренние источники

7. Что пользователи делают в продукте (или не могут сделать); как выглядит user journey
8. Что говорят пользователи, которые перестали пользоваться продуктом
9. Что говорят другие отделы, которые общаются с пользователями (саппорт, сейлзы, маркетинг)
10. Что говорит руководство компании/топ менеджеры/лидеры
11. Что делают другие команды в вашей компании, есть ли возможность для коллаборации или заимствования
12. Догфудинг (интенсивное использование продукта самой командой)
13. Небольшие сфокусированные дискуссии с командой
14. Работа в "обратную сторону" от видения: если вы хотите достичь X, какие проблемы должны быть решены

Важно помнить, что все это лишь источники идей, а не руководство к действию. Все идеи нужно попытаться кластеризовать и выделить темы на уровне проблем/возможностей для пользователей; а дальше уже определить потенциальный импакт от решения этих проблем и MVP для проверки гипотезы.

Парадигма навигации

Для навигации по приложению мы выбрали таббар. В 2018 году это выглядит очевидным, не было даже вариантов, что может быть по другому. Вопрос был скорее в том, какие пункты меню выбрать.

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

Об окончательной победе таббара над бургер-меню можно говорить хотя бы потому, что гугл давно добавил таббар в гайды материал дизайна, и сейчас практически все приложения от гугла навигируются именно таким образом (не важно ios это или android).

Окей, с навигацией разобрались. Теперь как понять, какие функции у приложения основные и что из них вынести в таббар? Можно пользоваться простой логикой — ради этой функции в таббаре я буду запускать приложение.

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

Искусство задавать вопросы

Если задать 5 почему подряд — можно, наконец, докопаться до сути проблемы. Навык задавать правильные вопросы отличает опытного дизайнера от новичка.

История
В середине 60-х в США в маркетинговую компанию обратился магазин мебели с целью повысить свои продажи.
Маркетологи начали свою работу с того, что стали задавать вопросы:
Как происходит процесс продажи?
Продажа происходит по каталогам.
Как вы доставляете эти каталоги?
Их кладут в почтовые ящики
Что с ними происходит дальше?
Люди забирают рекламные каталоги и хранят их дома.
Чем ваша продукция отличается от конкурентов?
Особо ничем не отличается — у конкурентов представлен схожий ассортимент.
Тогда как покупатели выбирают, где сделать покупку?
Чаще всего люди просто берут первый попавшийся буклет и делают заказ.

На основе полученной информации маркетологи решили изучить, как именно эти буклеты хранятся в домах. Они пришли к выводу, что обычно такие буклеты хранят где-нибудь в чулане одной большой стопкой, а при необходимости сделать покупку — берут самый верхний.
Тогда, они решили сделать буклет меньшего размера, чем у конкурентов, чтобы на него было неудобно складывать остальную бумагу.
И это сработало! Продажи повысились, задача была выполнена.

Искусство задавать вопросы от Жени:
• Спрашивать только про опыт — как человек занимался чем-либо. Например, вместо вопроса — что вы думаете об этой функции, лучше спросить — когда вы в последний раз пользовались этой функцией?
• Если респондент обобщает — значит он врет. Маркерами могут являться такие фразы как: «в целом мне все нравится», «если разобраться, то ничего сложного нет» и т.д.
• Если человек не пытается решить проблему — значит её нет.
• Задать 5 почему подряд

Чем отличается результативность, продуктивность и эффективность друг от друга?

Если привести пример на человеке, которые изготавливает какую-либо продукцию, то получится следующая картина:

Результативность — это когда 100 гаек за 8 часов.

Продуктивность — это когда те же 100 гаек, но за 6 часов.

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

В этом и есть эволюция дизайнера — опытный дизайнер всегда сначала задается вопросом зачем нужна это кнопка/функция/экран, а не какого она должна быть цвета или в каком месте экрана её расположить. Потому что пользователю не нужна конкретная кнопка — ему важно, как можно быстрее удовлетворить свою потребность.

Боязнь простых решений

Я часто замечал, что люди недоверчиво относятся к простым решениям.
Например, приносишь дизайн заказчику, а он: "Слишком просто, давайте добавим чего-нибудь этакого!"
Добавляют. Проект стартует, а ухаживать за "чем-нибудь этаким" довольно сложно.

Бояться надо сложных решений.
Любое решение, в котором есть куча "если" — бомба замедленного действия.

"Мы предусмотрели в проекте 500 экранов! Если так, то такой экран и логика.
Если этак — такой экран и логика. Всё очень индивидуально."

Чем больше "если", тем больше проблем в поддержке, в развитии, в понимании.
В итоге, в какой-то момент на отдельные логические ветки начинают забивать или забывать: что-то развивается, а что-то начинает устаревать.

Если вместо 500 экранов можно сделать 100 — надо делать 100. Пусть потеряется где-то индивидуальность, но решение не будет протухать.
У нас в Велвике такой принцип — если решение кажется сложным, то мы останавливаемся, отматываем назад и смотрим, где можно упростить.
Простое работающее решение придумать сложнее, чем нагородить кучу "если".

В общем, надо стремиться к упрощению.

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

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

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

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

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

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

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

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

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

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

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