VanillaTime

2022-08-30 16:22:52 А вот кстати и интерьер Honda E Open / Comment

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2022-08-03 21:20:07 Недавно я упарывался по теме автоматизированного регрессивного визуального тестирования, пытаясь найти инструмент, который бы облегчал этот процесс.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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