Мне очень зашла эта статья о том, как дизайнер с двадцатилетним стажем столкнулся с ностальгией: в век тачскринов с высоким разрешением перед ним стала задача собрать прибор используя только кнопки, сегментированные панели и переключатели. Это не те, которые Radiobuttons, а те, которые мы ласково называем «тумблерами».

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

👉 Супер-низкие цены. Для того, чтобы прифигачить кнопку достаточно её физически подключить, а вот чтобы запустить GUI нужны более сложные платы и чипы, что значительно увеличивает себестоимость.

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

👉 Надёжность компонентов. Компоненты выполняют одну задачу, но делают это превосходно, что значительно снижает отладочные затраты, и увеличивает надёжность всей системы за счёт распределения рисков. Если одна кнопка перестанет нажиматься её можно либо заменить, либо выполнять задачи без её участия (помните джостики в Sega, где залипала кнопка блока в MK3?). Аналогично, если выйдет из строя тачскрин — тю-тю.

👉 Компоненты не могут быть перепрограммированы. Казалось бы — это ограничение, а не преимущество. Но вот вспоминаешь радиобатоны-чекбоксы или кнопки-ссылки и сразу не до смеха. Вдобавок это помогает не расслабляться и искать элегантные решения.

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

В общем, лично я, в следующий раз подумаю при проектировании какого-нибудь прибора, нужно-ли полагаться только на GUI, или можно обойтись аналоговыми компонентами. И не только из-за вышеперечисленных преимуществ. Основная причина — это доступность, ведь любой прибор или продукт закрывает человеческую потребность. И для всего человечества будет выгодно, если эта потребность будет закрыта эффективно. И я говорю не только о дешевизне, скорее о балансе цены и качества и разумном потреблении природных ресурсов. К сожалению, с точки зрения маркетинга, это не всегда верный путь, но это не значит, что не нужно пытаться. 🛳❤️

Всё думал, о чём же написать ещё, чем порадовать. Уже было хотел поделиться отчетом о зарплате UX-копирайтеров (у них там всё хорошо, если вы волновались), но вдруг вспомнил, что у нас есть свежатина на канале: тот самый цикл лекций от Никиты Потапенко и Анны Бондаренко об этике в дизайне.

👉 В первой лекции, мы коснулись этичного процесса дизайна.
👉 Во второй узнали, что такое этичный продукт.
👉 Третья лекция поведала о том, что есть Diversity and Inclusion в формате воркшопа от Анны Бондаренко.
👉 Ну и конечно, не обошлось без вопросов-ответов с автором курса.
👉 А вот здесь, мы уже с другим Никитой, делились впечатлениями после закрытого показа лекции.

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

👍Отличный пример того, как информирование может менять поведение. Дизайнер из Яндекса представила кейс, в котором рассказала, как применяли новый алгоритм выявления агрессивных водителей. Благодаря ему, снизился процент такого поведения на дороге. К сожалению, остаётся за скобками причина таких изменений: толи водители начали видеть, где они лихачат, толи всех лихачей забанили к чертям. Но я предпочитаю верить в лучшее :)

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

Спасибо Сергею за подгон.

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

👉 Разберёмся с основными метриками,
👉 Узнаем, что не так с воронками и анализом кликов,
👉 Что делать, чтобы анализ не сбоил,
👉 Посмотрим, как правильно измерять успех, если ничего не понятно.

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

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

А вот как раз и статейка в тему: «Платим по своим дизайнерским долгам». Это третья статья цикла о дизайн-долге в которой описан сам процесс оплаты.

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

После того, как вы провели аудит вашей зоны ответственности, систематизируйте ваш долг и разбейте на стори. Например, вот какие атрибуты вы можете использовать:
👉 Название.
👉 Описание.
👉 Размер. Здесь можно обойтись T-shirt моделью или «Собаками», чтобы просто обозначить относительный объем задачи.
👉 Область продукта. Долг касается взаимодействия, внутреннего деливери, командных взаимоотношений или чего-то ещё.
👉 Зависимости. Долг может пускать метастазы в разные отделы и команды, потому так сложно оценить и объем и влияние и важность.
👉 Влияние. Можно определить по стандартной приоритизационной схеме «Усилия / Результат».
👉 Важность. Насколько решение «горит» для всех участников процесса.

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

— Если расходы на текущее поддержание > расходы на разработку,

— И если выплата долга открывает нам значительные возможности для улучшения.

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

Обязательно зацените ещё 2 статьи из цикла:
— Что такое дизайн-долг?
— Как измерять дизайн-долг?

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

Если будут какие-то идеи и предложения — пишите мне. Всем замечательного четверга 🛳❤️

🤟Антон Григорьев, автор канала 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 решения, а оставляйте себе немного этого драгоценного ресурса на эксперименты с невероятностью. Не всё в нашем мире пока можно просчитать, а потому чёрные лебеди всегда будут прилетать к нам и ставить отрасли с ног на голову. Кто знает, может следующего откроете именно вы?