🤟Антон Григорьев, автор канала UX Notes растолковал за функциональную спецификацию интерфейса и поделился опытом создания этого артефакта.

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

🧽А если проект долгоиграющий, то и разработчики там меняются — «бери мочало, начинай сначала».

Проблему эту решают по-разному: тратить время на разъяснения, или обзаводятся источником правды и ссылаться на него, когда возникают споры, конфликты и понажевщина. Источник правды решает.

Мы на проекте использовали zeroheight для этих целей и проходило все гладко: если мы принимали какое-то решение, то оно сразу фиксировалось и у всех был к нему доступ.

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

📘Напомнило мою пояснительную записку к дипломной работе, где я рассказывал, как работает интернет-магазин :) Забавно, но именно такую записку мы и писали заказчику на проекте, чтобы зафиналить PoC и подписать контракт. Опус занял 120 страниц, зато вопросов потом было... Не было вовсе.

Так что однозначно советую ознакомиться с трудом Антона и подписаться на его канал :)

🤔 Что значит быть лидером? Это когда ты принимаешь все-все решения? Когда тобой восхищаются и хотят идти за тобой на край света? Или это когда ты можешь заставить людей делать то, что им не нравится? В моём понимании, лидерство — это ответственность, которую ты на себя берёшь и с каким настроением ты это делаешь. Основное отличие менеджера от лидера в том, что менеджер отвечает за продуктивность людей: рабочий процесс, сроки, инструменты и т.д. То есть делает так, чтобы людям ничего не мешало делать их работу максимально эффективно. В тоже время лидер подаёт пример собственным поведением, вдохновляя и мотивируя так, чтобы работу хотелось делать. Но если вдаваться в детали, то я тут набрёл на статейку с примерами того, кто такой лидер.

В ней, автор предлагает 6 рабочих обязанностей лидера:
💍Сваха — женит интересы человека с интересами бизнеса,
🛳Капитан — видят полную картину происходящего и направляют команду по лучшему курсу,
🤝Дипломат — представляет интересы всей команды за столом с большими дядями,
📣Болельщик — хвалит, когда нужно и вовлекает в процессы,
🪴Садовник — планомерно, шаг за шагом культивирует окружение и растит команду,
🏋️‍Тренер — каждый день улучшает показатели качества всей команды.

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

Но саму статью тоже обязательно прочитайте :)

Сегодня вечерком мы соберемся с ребятами, чтобы немного потрещать за дизайн, а заодно перемыть косточки кассам продажи билетов. Будет интересно, приходите 😊
Работы и предложения для разбора на следующих выпусках можно слать через такую форму.
А экспертом стать, через вот такую.

🎙Посидели душевно с ребятами на 2.5 часа. Понаразбирались зато! Для тех, кто пропустил стрим мы его аккуратно, не трогая, положили на ютюбчик, с таймкодами, и всяким описанием. А если не хочется смотреть 2.5 часа, то вашему вниманию выжимка некоторых выводов из нашей беседы.

В общем, если вам нужно создать кассу билетов, то:

1. Уделите внимание выбору языка. Хорошей практикой будет использовать локальные названия стран с имоджи их флагов.

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

3. Формируйте правильные ожидания и используйте ментальные модели пользователей для проектирования.

4. Не давайте пользователю красную кнопку, ведь он обязательно на неё нажмёт.

5. Календарь — мощная штука, не нужно ограничиваться стандартным набором из двух календарей. Можно сделать его полезнее за счёт информации о наличии свободных мест или цен на билеты.

6. Не нужно использовать дополнительные связи календаря и выбора режима «в один конец»/«с обратным билетом».

7. Скрытые поля формы скорее занижают ожидания, нежели больше вовлекают пользователя (тем более, что на старте их не так много). Делите на логические шаги только большие формы, а маленькие оставьте открытыми. Так вы увеличите аффорданс.

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

9. Если куда-то полететь нельзя — не показывайте, зачем людям дополнительные надежды.

10. При выборе маршрута лучше сразу указывать количество пассажиров с дефолтным значением «1». Так мы сможем отсечь результаты, которые не подходят при путешествии с друзьями или семьёй, вместо того, чтобы проверять каждый.

11. Однозначно дифференцируйте полёты с пересадками, и обратные рейсы: можно просто написать лэйблы, развернуть самолётик или поставить стрелочки в нужных направлениях.

12. Использование ползунков в виде фильтров — грех. Для вас уже готовят котёл.

13. Также, если билетов по нужному маршруту нет, можно подписаться на обновления.

14. При отсутствии билетов на нужные даты предлагайте альтернативы: или даты или средства передвижения.

15. Время загрузки можно использовать с пользой, обучая человека тонкостям работы: рассказать про программу лояльности, отзывы, хотекеи. Главное дать достаточно времени на изучение, даже если страница загружается быстро, и возможность скипануть.

16. Выносите за скобки только не нужную информацию (год, секунды), а нужную оставляйте там (информация о рейсе, маршрут).

17. Будьте лояльны к ошибкам пользователя — «Ну забыл переключить раскладку, ну что такого?»

18. Однозначно показывайте разницу в классах билетов: если получится, опишите различия в виде сравнительной таблицы (feature list) или покажите разницу визуально, используя фотографии.

19. При выборе мест, используйте чёткую легенду мест, с указанием цен. Помните про доступность и выбирайте верные цвета.

20. Не нужно полагаться на выбор режимов (табы) для выбора мест на рейс. Лучше разделить на два шага.

21. Визуальные схемы самолётов, поездов и автобусов помогают выбрать правильное место и донести преимущества, но стоит быть аккуратными с данными и перепроверять, как это работает для разных самолётов/поездов/автобусов.

22. Для введения даты рождения гораздо эффективнее использовать три поля и механический ввод, чем календарь.

23. Продавая дополнительные услуги ваша задача сделать так, чтобы человек захотел это приобрести. И лучший способ здесь не лить воду в тексте, а показать, что из себя представляет услуга через визуальные образы.

24. В агрегаторах, во время выбора ресейлера (если вы не продаёте билеты сами) желательно формировать ожидание, что сейчас пользователь будет перенаправлен на другой сайт.

25. Не разносите кнопки сабмита и саму форму, а тем более не прячьте их за куки-баннер. Это же очевидно.

26. Потратьте немного времени на проектирование билета и композицию с учётом потребностей пользователя: ему не так важно видеть сколько он уже потратил и сколько мест купил, как то, когда отправление поезда, какие у него места.

27. Помните, что конверсия может происходить далеко не сразу, потому нужно помогать пользователю вспоминать свой выбор: добавлять в избранное, формировать список «вы недавно смотрели».

Вот так вот :)

☀️Подгончик на выходные. Если будет желание почитать что-то клёвое и поэкспериментировать с чем-то интересным, то советую «Ультимативный гайд по дизайн-токенам». Не в том плане ультимативный, что «так и никак иначе», а в том, что обязателен к прочтению :)

Автор канала «Мамкин дизайнер» Евгений Шевцов, как я понял, совместно с корешами из фронт-энда, решили сделать одну статью про всё о дизайн-токенах:
— Там и история с подводочкой про атомарный дизайн,
— И про семантику в наименовании стилей и токенов,
— Кинут гусь в сторону того, что из себя токены представляют и как их используют в разработке,
— Потроганы примеры того, как реализуются разные компоненты на этих самых токенах,
— Есть вагончик и про то, как дизайнер может работать с токенами (используя всё тот же знаменитый плагин),
— Наличествует разбор тулов, помогающих синхронизировать работу дизайнеров и фронт-энд разработчиков,
— И фаталити в виде создания компонентов ручками из кода.

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

И при этом, в копилочку полезных материалов эта статься отправляется однозначно.

Недавно впал в ступор стараясь определить, как правильно стирать новые шорты. Если думаете, что это легко, то попробуйте сделать это для одежды, в которую вы облачены, пока читаете эти строки. Посмотрите на этикетку. У меня для вас несколько вопросов. С утюгом всё понятно, а сколько точек там максимум? Что означает треугольник? А круг? А квадрат? Если вы давно в стирочном бизнесе, то, может, и без труда ответите на эти вопросы, но если вы, как и я — 🤯

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

Хотите, проведём конкурс на переделку? Тогда собираем 100 лайков )

Ds rjulf yb,elm… Блин. Вы когда-нибудь писали сообщение, которое приходилось стирать из-за неправильной раскладки? А как насчёт пары матерных слов, которые вы выкрикивали, когда пароль «не подходит», хотя вы нажали Caps Lock?

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

Взять к примеру хоть режим работы сервиса без доступа к интернету. Если вы работаете над классическим веб-сервисом, то и проблемы нет — пользователь просто не сможет подключиться. Но если ваш сервис использует сеть только чтобы сохранять изменения, или это тот же PWA, то вам придётся сказать, что сейчас интернета нет, так что изменения не сохранятся сразу.

Если ситуация вам не чужда, советую ознакомится со статьёй о работе с режимами. Если кратко, то проблемы с ними можно разбить на 2 типа:

👉 Проблемы с нахождением переключателя режимов. Это когда вы во время презентации пытаетесь найти кнопку «Пошарить экран» в корпоративной туле заказчика и тянете это «Ooooooooooneeeeee seeeeeeeecoooooooond… Alrightcanyouseemyscreen?»

👉Проблемы нечёткой индикации, когда человек может «провалиться» в другой режим и так этого не заметить.

Лечатся эти проблемы простым набором действий:

1. Подумайте, нужен ли другой режим: нет режимов — нет проблем.

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

3. Формируйте ожидания от переключения режимов: хинты, типсы, видео-демо.

4. Чётко обозначайте в каком режиме находится система: нотификации, рамки, тосты — всё идёт в ход.

5. Чётко очертите «дорожку к выходу» из режима. Чтобы это не было дверью без возврата. Лучшим решением будет тоггл — где вошёл, там и вышел.

6. Будьте толерантны к ошибкам, давайте возможность отмены или поставьте «естественные ограничения» в виде подтверждений.

Вот так вот. Всем прекрасного xtndthuf… БЛИН!

Доброго вечера, ребята :) Завтра в это же время, только на час пораньше состоится наша вторая критик-сессия с моими коллегами Артёмом и Илоной (автор канала Поясни за UX).

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

Всех жду, обещаю, что не затянем :)

Вот и прошла наша вторая сессия критики с Артёмом и Илоной. Вместе разбирали сервисы по букингу жилья и выявили несколько интересных инсайтов, про которые хорошо бы помнить, если делаете что-то подобное.

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

2. Во время поиска давайте возможность настроить сразу специальные фильтры, значимые для пользователя.

3. Пытайтесь работать с уже предоставленными данными: если пользователь укажет, сколько собак с ним едет, можно сразу проставить фильтр «Pets friendly».

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

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

6. Не жадничайте, и вместо того, чтобы делать все объявления горящими, сделайте тройку-ротатор в самом начале поисковой выдачи. Если выделяете всё — не выделяете ничего.

7. Аналогичный совет касается давления на пользователя при помощи дефицита. «Спешите!», «Последний номер!», «Осталось всего 340 номеров!» — так вы только приобретаете репутацию торгаша.

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

9. Рационально взвешивайте отношение полезного пространства к рекламе, которую всё равно кто-то всунет. Так лучше это будете вы и встроите её аккуратно, чтобы ничего нигде не треснуло.

10. Изменение вида отображения не должно влиять на примененные фильтры, за исключением карты, где объявления фильтруются по видимой части.

11. Кстати о карте. Не лепите все объявления в кучу, так по ним фиг попадёшь на отдалении. Но и убирать «неугодные» объявления тоже не стоит, ведь иначе пользователь просто может не узнать о том, что они существуют. Вместо этого, лучше стекать объявления в групповой пин с легендой.

12. Чтобы пользователь не сломал себе шею мотая головой от карты к листу объявлений, лучше открывать на карте поповер с листалкой объявлений в группе.

13. При этом нужно использовать именно поп-овер с закрытием по клику, а не ховер.

14. Карта может содержать не только объявления, но ещё и инфраструктуру: детские сады, школы, остановки, магазины и т.д.

15. На карте, да и в списке помечайте объявления, которые пользователь уже смотрел — это очень полезно для отсева.

16. Самая главная страница сервисов по аренде — страница объявления и относится к ней нужно соответствующе: не нужно лепить всё в одну большую мясорубку и впихивать в фолд невпихуемое. Вместо этого уделите время информационной архитектуре.

17. Люди покупают образы, потому не стесняйтесь эти образы рисовать при помощи больших фотографий и галлерей. Но не переборщите, иначе получится сток :)

18. Увеличивайте сканируемость сразу предоставляя доступ к списку «благ и особенностей» используя при этом информативные пиктограммы.

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

20. Оу, и последнее, если пользователь не может забронировать номер в отеле или снять квартиру, то не нужно её показывать. Так только раны солью покроете.

Если кто-то хочет посмотреть живые примеры, то милости просим в видео, всё там есть. На этот раз всего полтора часа — стараемся. В следующий раз точно уложимся в час… Наверное.

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

Если коротко, то меня до жути накаляли случаи, когда дизайнер вносит атомарные изменения в библиотеку и не смотрит, как они влияют на существующие компоненты. Всё летит к чертям и потом приходится или откатываться или переделывать работу и тратить время. Хотелось найти тул, который бы помогал вычленять разницу между мастер-компонентом и измённым. В идеале ещё, чтобы в случае нарушений он хренячил дизайнера сцаной тряпкой в убедительной форме разъяснял, что изменения не проходят валидацию. Но ничего такого на рынке пока нет. Есть только вот такой мануальный подход к визульному тестированию компонентов. То есть, ни о какой автоматизации речи не идёт: закатываем рукава и хренячим вариативные тест-кейсы на изменение свойств и отсутствие контента. 🚜

Как вы могли понять по интонации, в эффективность данного подхода я не верю. Давайте быть реалистами: никто не будет тратить стольно времени на подготовку процесса, которому никто не будет следовать. 🤐 Идея придётся кстати только в том случае, если у вас ОГРОМНЫЙ, как мои сомнения, проект, где постоянно вносятся изменения в атомарную структуру. Скептики взвоют: «Ну как же! А если вдруг придётся вносить изменения в атомы, когда компания переделает брендбук!» Вот когда переделает, тогда и скажите, а пока придержите аргументы при себе. Такая ситуация за мою практику случалась всего 4 раза, и в эти разы было проще руками проверить каждый элемент. Как бы дико сие не звучало.

Также мне надоели ситуации, когда к вам приходят разработчики и говорят «Мы сделали, проверяй!» и ты сидишь и сравниваешь отступы, размеры, кегль, начертания… всё. И потом выносишь это в Жиру и ждёшь пока тикет закроют, чтобы всё начать сначала. И знаете, для такой ситуации тоже ничего путного нет :) Только плагин PixelParallel, который хоть немного но облегчает этот процесс. В остальном — это дикий запад, где каждый сам за себя.

Не знаю, какой вывод можно сделать из всего сказанного, кроме хорошей идеи для стартапа :)

Помню время, когда для регистрации на сайте не требовалось делать ничего, кроме ввода логина и пароля. Но потом на сцену вышли боты и всё пошло по наклонной: сперва просили ввести код с картинки, потом надиктовывали цифры, потом мы решали простые примеры, ну а сейчас отмечаем на картинке гидранты и дорожные знаки. Если AI и Machine learning будут развиваться и дальше, я не удивлюсь, что для защиты от них нам придётся проходить тест Тьюринга, чтобы проверить почту. 🤖 Но эту тему оставим для другого раза. Пока давайте решать проблемы, которые мы можем решать, например, максимально облегчить вход и регистрацию.

И поможет нам в этом Виталий Фридман, который описал свои мысли по этому поводу. Итак, вот его рекомендации:

1. Не блокируйте возможность копипастить пароль. Сделав это вы, конечно, обезопасите себя от бот-атак, но ещё и обеспечите пользователям нехилую головную боль от перепечатывания паролей из Password Keepers. А если они используют кодовые фразы на 25 символов… сосуды могут не выдержать. 💔

2. Убедитесь, что поле пароля содержит атрибут autocomplete="new-password", так вы сможете облегчить пользователю придумывание пароля, соответствующего всем критериям безопасности. При это сэкономите ещё и место на отображении светофора с этими самыми критериями.

3. Не надейтесь только на пароль. Большинство пользователей не в состоянии использовать безопасные пароли из-за их сложности для запоминания. Всего 34% американцев используют менеджеры паролей, остальная доля приходится на память и стикеры. Но пароли всё равно забываются.

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

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

5. Пользователям однозначно нужна возможность восстановить пароль, но вот секретные вопросы для этого подходят плохо — они тоже забываются. Вместо этого вы можете использовать туже 2FA (2 factor authentication) или волшебные ссылки. И как альтернативы, можно использовать что-то из списка в самом посте.

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

Только что дочитал преинтереснейшую статейку о Data-driven approach, и о том, почему он может работать некорректно. Впечатлила схожесть мыслей автора с тем, что давно циркулировало у меня на подкорке: мы слишком сильно надеемся на данные в принятии решений. 🔥😈🔥Вижу пара человек уже отправилась в чертоги разума за вилами, но выслушайте меня, прежде, чем повторять сцену из финала Ведьмака.

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

А вместе с тем, динамика изменений на рынке — это мало прогнозируемая область.🔮 Все, кто говорят, что знают «куда ветер подует», либо Джоны Сноу и нихера не знают, либо… действительно знают. Но вероятность встретить настоящего «знающего» равна практически нулю, потому я бы ею пренебрёг.

И совершил бы ошибку, но о ней позже.

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

Разберёмся сперва с медлительностью и желанием всегда быть уверенными во всем. Парадоксально, но именно маловероятные события, зачастую, и меняют рынок. Благодаря тому, что происходит то, чего никто не ожидал, и обеспечивается скачкообразное развитие отрасли. Такой феномен носит название 🦢«чёрный лебедь» и ввёл его в обиход профессор математики и статистики Нассим Талеб. Не буду вдаваться в детали появления термина, но приведу примеры: ипотечный кризис 2008, Уотергейт, биткоин, сканер отпечатка пальцев и т.д. Эти события, все считали невозможными или крайне маловероятным, ибо такого раньше не случалось, потому к ним никто не был готов. Оттого последствия их были настолько большими и сейчас, ретроспективно, их наступление кажется очевидным.
В нашей дизайнерской отрасли тоже хватает примеров революционных, а не эволюционных открытий и их становится всё больше. А к ним никто не готовится, ведь… это маловероятно.

А теперь вернёмся к проблеме слабой методологической базы. Ставший каноном data-driven подход уже научил нас обращать внимание на качество и чистоту данных. Но вместе с тем, отчего-то исследовательский период на большинстве продуктов не превышает двух недель. Понятно, что бизнес хочет двигаться быстрее, но вместе с тем он обрекает себя на сбор искажённых данных. При значительных изменениях в структуре сервиса, бизнес модели или опыте, будут присутствовать так называемые предвзятости и искажения.

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

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

Так что же делать? Отказываться от data-driven в пользу карт таро 🃏 и стеклянного шара точно не следует, и при этом я призываю вас обратить внимание на то, насколько методологически правильно вы подходите к анализу данный, и зачем вы в принципе это делаете. И самое главное — рискуйте и берите на себя ответственность. Не тратьте 100% вашего времени на risk-proof решения, а оставляйте себе немного этого драгоценного ресурса на эксперименты с невероятностью. Не всё в нашем мире пока можно просчитать, а потому чёрные лебеди всегда будут прилетать к нам и ставить отрасли с ног на голову. Кто знает, может следующего откроете именно вы?

Бывало, что «рыба» или «заглушка», принималась разработчиками буквально и имплементировалась на продакшен? Помню своё удивление, когда команда демила новый лендинг продукта и я увидел там своих Людмилу Живодёрову и Константина Миролюбова расхваливающих продукт в самых кринжовых фразах. На вопрос, «а почему не поменяли на реальные?», ребята ответили, что пока так повисит, а как соберём отзывы от настоящих пользователей, то сразу заменят. Не стоит говорить, что когда я уже три года работал в другой компании, ничего так и не поменялось.

Но такое случается не только на продуктовом уровне, но и на глобальном уровне целой индустрии. Например, вас не забавляло, почему Bluetooth называется именно так. Это не акроним, не технологическая метафора, и даже не комбинация имён создателей. Звучит, как плейсхолдер. Так это он и есть :)

Когда лидеры отрасли Intel, Nokia и Ericsson решили стандартизировать технологию передачи данных на короткие расстояния, то один из участников митинга предложил использовать кодовое имя Bluetooth, в честь Короля Гарольда «Синезуба» Гормссона, который в 958 году объединил Данию и Норвегию. И у него действительно был посиневший мёртвый зуб. 🦷

Позже проект хотели переназвать в RadioWire или PAN (Personal Area Networking), но второй вариант оказался занят, а исследование рынка для первого не смогли закончить в срок, потому решили оставить плейсхолдер. И он стал невероятно популярным и быстро прижился. Логотип Bluetooth, кстати и состоит и рунических символов Hagall (ᚼ) и Bjarkan (ᛒ), инициалов синезубого короля.

Вот так-то, так что в следующих раз пишите рыбу осознаннее. Кто знает, может ваша Людмила Живодёрова получит Пулитцеровскую премию за свой «отзыв».

На глаза попались интересные рассуждения о том, почему тач-скрины в машинах — это не всегда хорошо. Я уже писал об этом ранее (вроде как 🤔), но повторение — мать учения. В этот раз говорить будем не о космических шаттлах, где всё сделано на тумблерах и физических кнопках потому как сенсорные экраны тупо не будут работать в толстых и неуклюжих перчатках. Вместо этого поговорим о чем-то более приземлённом — машинах.

На сегодняшний день всё реже можно встретить авто, в которое не проник бы сенсорный дисплей. После того, как мир увидел экран Теслы, индустрия перестала быть прежней. Если Илон Маск может, то почему не можем мы? Тем более, что замена олд-скульных кнопок, релле и тоглов на иконки не только делает интерьер машины минималистичным, но и удешевляет производство. А денежки всегда двигали индустрии. 🤑

Но с полным отказом от аналоговых средств управления есть одна проблема — экраны отвлекают внимание водителей от дороги. Если в «аналоговых друндулетах» можно было без лишних раздумий подкрутить кондиционер протянув руку в привычное место, то в «современных нео-мобилях» на эту операцию тратится в 4 раза больше времени. Данные последних исследований.

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

Но и у последних есть проблемы. Часто они носят множественные функции: нажал один раз — переключил станцию радиоприёмника, нажал и подержал — вот ты уже настраиваешь часы. На каждую функцию свою кнопку не впилишь, иначе мы точно на рокетах будем летать.
Поэтому я предлагаю компромисс: использовать аналоговые контролы для самых распространённых функций во время езды, а сенсорные экраны для нечастых действий перед началом вождения или во время остановок. Как, например, в моей новой любимой Honda E. Меру нужно знать.

А вот кстати и интерьер Honda E ❤️

Ребята, простите, я совсем замотался, но если у вас есть желание, то прямо сейчас начнётся DS: Critique Session #3: Food delivery. Подключайтесь, задавайте вопросы, будет интересно… надеюсь )) https://youtu.be/hb1QffTOdJM

Составил для вас takeaways из нашего недавнего разбора приложений для доставки еды.

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

2. Если решили использовать Coaching screens, говорите о том, как пользователю решить его задачи. Не используйте промо-тексты, их время было до того, как пользователи поставили себе приложение.

3. Количество coaching screens лучше ограничить тремя — это количество даёт оптимальное снижение дроп-рейта.

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

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

6. Упрощайте всё что можно — приложение должно напоминать молоток, выполняя одну функцию. Там не нужны три уровня навигации и навороченные фильтры.

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

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

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

10. Явно обозначайте границы карточки, для того, чтобы пользователю было понятно, что он добавляет в корзину.

11. Пространство тоже хорошо работает для отделения айтемов.

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

13. Сокращайте количество шагов добавления блюда в корзину — детали понадобятся нечасто, ведь вся ценная информация есть в названии, так зачем добавлять лишний шаг?

14. Для отображения деталей лучше использовать bottom-sheet, там же можно и размещать и экстра-добавки.

15. Чётко обозначайте следующий шаг в оформлении заказа. Например, приклеивайте однозначную кнопку на всю ширину экрана, иначе рискуете столкнуться с блокером в сценарии.

16. На странице ресторана не стоит размещать ненужную информацию, типа условий, отзывов и длиииииииииинных описаний — пользователь здесь не за этим.

17. Функция группового заказа может казаться привлекательной, однако стоит проверить её необходимость через исследование. Возможно, она будет полезной, а может станет пустой тратой и усложнением.

18. В корзине лучше по-прежнему использовать картинки блюд для проверки. Без них, конечно, список будет короче, но «Унаге-сяки-маки-вассаби-кимоно» остануться без проверки.

19. На этапе проверки заказа можно спросить о том, нужны ли клиенту приборы, а также использовать мягкие подталкивания: выставить по-умолчанию «Нет» и рассказать о пользе для окружающей среды.

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

21. Количество шагов доставки заказа, отображаемое пользователю не должно быть слишком большим, чтобы не перегрузить пользователя. Само собой дробление процесса на каждый «чих» губительно. Здесь лучше придерживаться деления на «зоны ответственности»: на стороне клиента «оплата», на стороне сервиса «согласование заказа», на стороне ресторана «приготовление» и на стороне курьера «доставка». Остальное пользователей не сильно заботит.

22. Думайте о пост-взаимодействии: интересуйтесь о заказе, доставке, а также помогайте вспоминать, что человек уже заказывал в ресторане. Вы даже можете внедрить функцию «Повторить».

23. Обратную связь лучше спрашивать отдельно о доставке, и о качестве и вкусе блюд, а также можете уточнять, что именно понравилось или не понравилось.

24. Как идея, можно вообще заменить рейтинговую систему на «палец вверх» или «палец вниз», но тогда нужно перепродумывать формулу определения рейтинга ресторана. Возможно использовать модель персонализации, а не глобальный рейтинг.

Надеюсь, это было познавательно :)