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

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

Хотите, проведём конкурс на переделку? Тогда собираем 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. Как идея, можно вообще заменить рейтинговую систему на «палец вверх» или «палец вниз», но тогда нужно перепродумывать формулу определения рейтинга ресторана. Возможно использовать модель персонализации, а не глобальный рейтинг.

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

🤑Пока новости о том, что Adobe обзавелась Figma за 20 лярдов будоражит дизайнерскую общественность, «аналитики» строят прогнозы о том, что же будет с нашим любимым инструментом. Кто-то уже прощается с бесплатными тарифами, кто-то смотрит на цены Creative Suite, кто-то штампует мемасы, а CEO Figma говорит о том, что ничего не изменится.

Не люблю строить прогнозы, ведь они никогда не сбываются, но одно для меня очевидно — как раньше не будет. Когда такой гигант, как Adobe, покупает что-то за 20 миллиардов, не думаю, что они делают это только для того, чтобы сказать «Ребята, мы не будем лезть, делайте всё также, мы постоим в стороне». Такого НИКОГДА не будет. Стоит инвесторам надавить и у руля станет кто-то из Adobe и начнёт наводить там «реорганизацию».
Лично я считаю, что пока рано судить о том, чем это может обернуться. Возможно, что для Figma откроются новые возможности и потенциал роста используя ресурсы прародителя Photoshop, но вместе с тем, это и большой риск, который я описал выше. Но вытрете слёзы, думаю, что изменения начнутся не сразу, так что у нас есть ещё немного «лета».

А пока будущее Figma туманно, есть смысл присмотреться к другим инструментам и попробовать что-то новенькое. Благо это сделать не составляет труда. Взять хоть Framer (кто бы сомневался 🤗). Cmd+C, Cmd+V, и вот уже лапы Adobe до вас не дотянутся, а заодно можно и CMS прикрутить и анимации навестить, и сразу в веб запаблишить. Лепота.

Натолкнулся на отличную статью о hard-argument-driven design. Этот тот же data-driven design, только без налёта булшита и иррациональных решений. Всё больше компаний применяют на практике концепцию измерения успеха через данные: выставляют себе KPI и OKR, обвешивают всё хуками и на годовых собраниях щеголяют отчётами с растущими графиками и зелёными трендами. И в самом по себе подходе ничего плохого нет, я и сам нахожусь в процессе создания measurement strategy, но есть риск угодить в пару волчьих ям:

🤯 Невнятные и сложные критерии всегда фейлят точность, так как они… ну невнятные и сложные. Если интернет-интернет магазин берёт за основную метрику что-то другое, кроме денег, то у него проблемы, так как любая не связанная с прибылью метрика будет вносить искажение в принятие решений. Например, эти «метрики тщеславия» — лайки, пользователи, шэры. Они могут оказаться важными только в случае, если ваш проект не коммерческий, а информационный или развлекательный. Иначе, эти «росты аудитории» ничего не стоят, если за ними не стоит конверсия. Как говориться «likes don’t pay bills, purchases do».

🃏 Измерение хоть чего-нибудь. Порой на проектах у людей появляется великолепная идея — измерять успех. Но так как не могут придумать или не знают, как это сделать правильно, то начинают измерять всё подряд и потом в этой куче данных пытаются найти взаимосвязи и корреляции. И находят. Правда в достоверности приходится сомневаться, ведь вряд ли годовая прибыль отдела имеет прямую связь с выпитыми чашками кофе. Коэффициент корреляции там никак не 1… ну 0.7.

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

Как заключение: я не призываю отказываться от data-driven подхода, а напоминаю, что это инструмент, который позволяет вам принимать более взвешенные и обдуманные решения. Но этого советника нужно слушать не всегда, а то закончите, как Теоден, король Рохана из Властелина Колец.

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

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

Та-да-дан! Итак, внимание, вопрос: каким способом вы это сделаете?
👉 нажмёте на «крест животворящий» — закроете сразу три слоя,
👉 свайпнете вниз — аналогично закроете все слои,
👉 нажмёте на область вне модалки — … я хз, что произойдёт,
👉 свайпнете влево = нажмёте на браузерный «бэк» — перейдёте на главную страницу,
👉 воспользуетесь аппаратным бэком — тоже самое.

Как видите, загадка достойна вопроса на собесе на равне с задачей двух стульев. Так что делать в патовой ситуации, где нет выхода? Нильсен Норман рекомендует следующее:

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

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

→ Старайтесь не использовать полноэкранные модалки без веской необходимости по той же причине. Затемненное пространство — это тоже выход.

→ От меня. Если это возможно, приведите все способы выхода из модалки к одному поведению — шагу назад. И помните, что у пользователя может быть и клавиатура, на которой есть «Esc».

→ От меня. Если это возможно, формируйте ожидания при помощи лэйблов, говорите, что произойдёт после нажатия на стрелку или крест.

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

Скажу прямо — я не большой фанат Apple. Я не слежу за пресс-релизами, не смотрю презентации и не стою в очереди за новыми девайсами. Какие-то продукты мне очень нравятся (буки на М-чипе — шедевр), к каким-то я равнодушен (ну Air Pods Pro — не моё), а какие-то ставят меня в тупик (выпиливание 3.5 из iPhone).

Тут чисто мое мнение. Глупо спорить с фактом, что все, что выпускает Apple быстро становится трендом, захватывая умы и вдохновляя. И при этом, меня поражает тот факт, как слепы мы к этим «проведениям» до того, как о них заговорят в яблочном офисе. По моему субъективному мнению все флагманские фичи Apple уже успешно существовали на других платформах (в том или ином виде): face recognition, picture in picture, multitasking, widgets. И каждый раз это продается с таким шиком, что все считают это революцией.

Так и сейчас этот невероятный прорыв дизайнерской мысли, Dynamic Island, мне не кажется чем-то большим, чем розовым костылем. Слишком много шума вокруг свистоперделки. «Ого, да теперь вокруг мертвого пространства можно плясать хороводы!» Только пространство из-за этого не оживёт. «Да вы что? Будут дёргаться палочки, когда играет музыка?! И даже можно будет увидеть, какой играет трек?»... «Можно будет увидеть стрелочку направления, когда проложил маршрут?» звучит по-прорывному. И пох, что все уже давно умеют показывать картинку в картинке и даже прокладывать маршруты в дополненной реальности — убогая стрелка реально решает. Так и хочется сказать: «Давай, ты можешь украсть что-то получше! Да хоть работу с буфером обмена!»

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

No comments. А у вас?

Наверняка вы уже сталкивались таким паттерном, как Infinite Scroll. 100%, инфа верняк. Я думаю, что уже не осталось активных пользователей сети, которые не стирали об него пальцы. Изобретённый в 2006 этот вид навигации стал популярным благодаря устранению для пользователя задержки и прерывания на перелистывание страниц, снижает косты на запросы к серверу, ведь подгружается только контент (это теперь возможно и для постраничной навигации), а также infinite scroll отлично подходит для мобилок. В один момент всем показалось, что пагинация уже не в тренде и это для стариков. Но за столько лет бесконечный скрол так и не смог вытеснить постраничную навигацию, но занял место под солнцем.

Все использовали Infinite Scroll, но далеко не все проектировали листинг с таким паттерном, а значит не в курсе следующих проблем:
1. Подгрузка данных происходит не мгновенно, потому может возникнуть ситуация, когда пользователь так или иначе упрётся в «пол» и прерывание возникнет так или иначе. При этом пользователь может подумать, что «достиг дна» и свалить.
2. Листать бесконечную ленту удобно, но только для одноразового контента, найти что-то быстро во второй раз практически невозможно.
3. Также невозможно посмотреть футер страницы, если контента достаточное количество.
4. Невероятные проблемы с Accessibility — если неправильно выстроить работу с клавиатурой, infinite scroll становится смертельной ловушкой для пользователя.
5. Также данный паттерн увеличивает время загрузки страницы и ухудшает SEO (прим. автора — тут сомнительно, но NN говорит так).

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

👉Например, можно использовать кнопку «Load more» и количества отображённых товаров из возможных. В совокупности с нормальным алгоритмом определения релевантности, такой паттерн будет использоваться не часто и будет отлично заменой бесконечному скролу на небольших выборках контента. Для сервисов с постоянным генерированием контента он вообще не подойдёт.

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

А достоин ли Infinite Scroll вашего проекта? Решать только вам... и пользователям.

Ребята, если хотите провести немного времени вместе, забивайте завтра слот на новую критик-сессию :) Поговорим про всякие интересные паттерны работы с музыкальными сервисами 🎧

Вот тут ссылка на youtube и на комьюнити платформу:)

Недавно мы так душевно пообщались с Артёмом и Аркадием на тему музыкальных стриминговых сервисов. Из нашей почти двухчасовой беседы я попробовал вынести некоторые самые сочные и полезные рекомендации. Если вы вдруг захотите сделать «убийцу Спотифая», вам не лишним будет ознакомиться 😁

👉 Музыкальные платформы — это персонализированная среда, где без внимания к личным интересам пользователя нечего ловить.

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

👉 Определение релевантности контента — сложная задача с использованием математических моделей. Можно протегировать контент, разделив его на категории и провести связи «похожести» (люди, которые слушают Slipknot, также слушают Korn).

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

👉 Как альтернатива контентной модели можно базировать рекомендации на похожести профилей людей. Например, я слушаю рок и Пётр слушает рок, наш индекс «похожести» по совпадению песен, которые нам нравятся — 80%. Значит, если Пётр лайкнет песню, то с определённой долей вероятности она понравится и мне.

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

👉 Во время уточнения интересов не забирайте у пользователя возможность искать группы самому.

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

👉 Использование бесконечной ленты рекомендаций может себя оправдать с точки зрения конверсии, чтобы слушатель включил хоть что-то, тольк не забывайте говорить о том, на основе чего сделана подборка («Потому, что вам понравился…»).

👉 В дополнение к предыдущему пункту. Бесконечная лента всё-таки может надоесть, если подборки будут выглядеть одинаково. Вместо бесконечных линий Netflix-style, используйте разнообразие: рекомендуйте сами песни, выводите чарты, напоминайте о том, что пользователь слушал ранее, предлагайте группы и их свежие релизы.

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

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

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

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

👉 На странице артиста не игнорируйте возможность рассказать о ближайших концертах — монетизируйтесь.