Павел Григорьев написал об ошибках при создании дизайн-системы.

— Все макеты рисовали под основное разрешение (была статистика), для других разрешений прорабатывали только типовые страницы. Элементы для этих разрешений появлялись в ДС вне контекста, без примерки на реальных экранных формах. Местами поплыли пропорции, часть элементов забыли;
— На основное разрешение не всегда можно ориентироваться: пользователи иногда работают в окнах не на весь экран, увеличивают масштаб в браузере, производители ноутбуков иногда по умолчанию увеличивают системный масштаб, чтобы интерфейс не был слишком мелким;
— Подход с целевыми разрешениями себя не оправдал. Надо закладывать ресурсы на проработку экранных форм, элементов ДС и UI-кита под разные разрешения;
— Сложные модули лучше делать более гибкими, чтобы проще было их изменить (в первую очередь с точки зрения кода), так как для таких модулей сложно всё предусмотреть с самого начала;
— Набора элементов недостаточно, нужны инструкции по их правильному использованию, примеры и шаблоны с лучшими практиками;
— В шаблонах и описаниях должно быть однозначно понятно, как использовать элемент, и они должны быть привязаны к реальным примерам использования.

#design_system

Дэмиен Ньюман в 2002-м нарисовал популярную схему, иллюстрирующую дизайн-процесс.

— Создание дизайн-решения происходит в три этапа: 1) research, погружение в задачу и изучение возможностей по её решению, 2) concept, формирование концепции, которая помогает перейти к проработке нюансов, 3) design, совершенствование концепции на основе обратной связи;
— Важно не пропускать этапы. Все три шага можно повторить;
— Почему такая визуализация: всё начинается с беспорядка и неопределённости и завершается в точке ясности завершённым дизайн-решением;
— Дизайн-решения притягивают клиентов больше, чем стоящий за ними процесс. Для многих это всё ещё некий единовременный акт превращения обыденных вещей в красивые, а не систематическая работа по поиску и развитию;
— «Загогулину» можно использовать бесплатно с указанием автора (в том числе и с коммерческой целью).

In English. #process

Андрей Яремко поделился мнением о разделении на UX и UI.

— UI — как выглядит интерфейс, его логика и опыт взаимодействия пользователя с этим интерфейсом;
— UX — вообще не про дизайн, а про деньги и степень ограничения пользователя;
— Разделение UX и UI излишне, одно без другого никому не нужно. В чём ценность дизайнера, который отвечает только за красоту, когда есть множество UI-китов, с которыми любой UX-дизайнер соберёт макет?
— Опыт взаимодействия с интерфейсом — это про удобство. Но это не то же, что опыт взаимодействия с продуктом. Последнее — про деньги и внедрение в продукт ограничений и неудобств;
— Если посмотреть патенты Match Group (Tinder) или Amazon, улучшение пользовательского опыта связано не с интерфейсом, а с искусственным интеллектом, сегментированием аудитории, логикой ранжирования и подбора товаров, новыми способами заработать;
— UX пересекается с UI, формируя для последнего требования к интерфейсу и логике работы системы. Например, хороший UX в онлайн-игре формируется не балансом или интерфейсом, а наличием системы региональных серверов, обеспечивающих хороший пинг;
— UX — баланс между ограничениями и неудобствами пользователя и оптимизацией доходов.

#definition

Игорь Кузнецов написал о 10 принципах Дитера Рамса.

— Некоторые принципы понятны, а некоторые требуют обдумывания. Игорь работает в сфере дизайна интерьеров и мебели, но его расшифровки могут быть полезны и дизайнерам интерфейсов;
— Хороший дизайн — инновационный, он развивается вместе с технологиями. Осваивайте новые технологии, чтобы двигаться вперёд;
— Удобен в использовании;
— Эстетичен. Красота субъективна, но есть классические принципы композиции, баланса. Плюс, со временем человек устремляется к большей простоте и осознанности;
— Делает продукт понятным для потребителя. Дизайн объясняет структуру продукта, помогает работать с ним без инструкции;
— Ненавязчив. Практичные визуально чистые предметы хорошо встают в разные интерьеры (см. видео Антона Шнайдера «Дизайн без дизайна»);
— Честен. Самый сложный в расшифровке принцип. Дизайн не должен завышать ожидания от продукта или манипулировать ими. Напишите в комментариях, как этот принцип понимаете вы?
— Актуален. Трендовый дизайн быстро устаревает. Крутой дизайн не создать, повторяя трендовые решения (только предугадывая). Он должен идти от сердца, веры в себя, увлечённости и удовольствия от своей работы;
— Продуман до каждой детали. Ничто не должно быть случайным или оставленным на волю случая;
— Экологичен. Способствует сохранению окружающей среды, минимизирует физическое и визуальное загрязнение на протяжении всего жизненного цикла продукта;
— Как можно меньше дизайна. Фокусируйтесь на главных аспектах и задачах продукта, не отягощайте его лишними функциями.

#heuristic

Фейфей Лиу написала о переключателях языка (страны, валюты) в интернет-магазинах.

— По умолчанию отображайте языковую версию, ориентируясь на настройки браузера и IP-адрес пользователя;
— Если так сделать проблематично, показывайте специальную страницу, на которой пользователь может выбрать регион и язык и перейти на региональный сайт (Zara);
— Размещайте переключатель в правом или левом верхнем углу на десктопных версиях сайтов (Asos), на мобильных — в верхней части (обычно занята более важной информацией) или в меню (Amcal+);
— Название языка пишите на том же языке, то есть вместо «Испанский» пишите «Español» (см. Airbnb и мобильный сайт Burberry);
— Если список вариантов стран и языков большой, в отдельном блоке можно отобразить предложения языка и страны для быстрого выбора: что часто выбирают или что соответствует настройкам браузера пользователя (Airbnb);
— Переключатель обозначайте сочетанием текста и иконок (флаг, символ валюты). Так его легче заметить и распознать, он подсказывает о возможности, например, выбрать валюту для оплаты (Selfridges);
— Флаг прямоугольной формы распознать проще, чем стилизованный круглый (Asos);
— Разрешите настраивать язык, страну и валюту независимо друг от друга (AliExpress).

In English. #localization #ecommerce

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сергей Шандарин написал о поиске работы дизайнером за рубежом (после 24 февраля).

— Будьте готовы к более формальному и длинному процессу найма, чем в России. Самая быстрая компания сделала оффер через месяц после заявки. Компания, оффер которой Сергей принял, — через 7 недель;
— Как правило, проходит от 2 до 6 отборочных этапов;
— Итоговая конверсия из заявок в офферы — 4%;
— Во всех компаниях на интервью задают идентичные вопросы, имеет смысл отрепетировать ответы;
— Отказы на поздних этапах иногда содержат обратную связь («не хватило А, Б, В»), но бывает, она противоречит тому, что происходило во время звонка. Или комментариям другой команды. Обращайте внимание только на то, что упомянули несколько разных людей;
— Сергей не встретил негатива от собеседующих из Украины и стран Восточной Европы, но сложилось впечатление, что отказов на поздних этапах от таких команд было больше. Полезно узнавать о составе команды как можно раньше;
— Если переезжаешь, зарплату предлагают одинаковую: 80–90 тысяч евро в год в Европе и 90–120 тысяч евро в Великобритании. В большинстве компаний за релокацию предлагают 5% от зарплаты;
— Портфолио оформляйте в виде сайта. Разместите там а) красивые картинки сделанных проектов с кратким описанием вашего вклада и результатов или б) детальные разборы сделанных проектов. Их никто не читает, но они показывают, что вы умеете делать не только визуал;
— Всё должно быть переведено на английский, особенно макеты;
— Важнейший фактор отбора — есть ли у вас разрешение на работу в стране. Выясните заранее, насколько реально его получить. Сергею не ответил никто из США, так как не было рабочей визы и единственный в году розыгрыш виз уже прошёл;
— Если не принципиально, куда ехать, фокусируйтесь на странах с адекватными визовыми условиями. Если выбрали конкретную страну, сразу подавайте документы в консульство (для этого оффер на руках не требуется);
— Срок годности вакансии: от 1 до 3 дней с момента публикации. Потом откликов становится слишком много, и их перестают смотреть;
— В известных компаниях срок годности: от 1 до 3 часов. Постарайтесь найти сотрудника компании, который вас порекомендует;
— Компании, которые просят указать в заявке текущую или ожидаемую зарплату, обычно платят ниже рынка. Укажите честные цифры, чтобы они поняли, стоит ли начинать процесс;
— Рекрутёры отвечают в пределах 3–4 дней. Долгие ответы в самом начале — индикатор беспорядка в мелких и средних компаниях и бюрократии в крупных;
— Нанимающие судят не по качеству вашего дизайна, а по тому, насколько хорошо вы можете его презентовать. Это совершенно отдельный нарабатываемый навык;
— Сорсер — человек, который ищет специалистов под заданные требования (в них не разбираясь) и приглашает поговорить. Если вы сами откликаетесь на вакансии, говорить с ним не придётся;
— Перед звонком ваше резюме не будут внимательно читать. Все важные и интересные факты о себе стоит проговаривать при разговоре с новым человеком;
— Презентация — это готовая последовательность слайдов о проекте: от формулировки проблемы до полученных результатов;
— Тестовые задания не очень популярны. Их дали только 4 компании из 15, с которыми Сергей серьёзно общался;
— Важно не воспринимать их буквально. Если для решения, хорошего для пользователей и бизнеса, надо оспорить задачу, значит, аргументированно её оспаривайте;
— У нанимающих менеджеров можно поинтересоваться, чего ожидать от предстоящего разговора с топ-менеджером. Он обычно заинтересован, чтобы у вас всё получилось;
— Текущую или ожидаемую зарплату называть не стоит. Если рекрутёр настаивает, можно ответить, что в среднем по рынку такие специалисты получают X. Это даст пространство для манёвра в будущем;
— Лучшая компенсация — не всегда более высокая зарплата. Это может быть пакет акций, подписной бонус, удалённая работа, больше дней отпуска, более гибкий график. Предложенную компанией компенсацию почти всегда можно улучшить.

#career

Игорь Штанг написал, что делать с текстом в скобках (например).

— Скобки — парный знак препинания. Они больше шумят и занимают места, чем запятая или иной одинарный символ;
— «Аренда телеги (за час)» → «Аренда телеги, за час» или «Аренда телеги / за час»;
— Можно убрать знаки препинания и выделить текст кеглем, цветом или начертанием и таким образом создать визуальный слой. Скобки на такое не способны;
— Если примечаний много или они однотипные, их стоит сгруппировать в отдельной колонке или в другом отдельном блоке.

#typography

Ироничные тексты повышают когнитивную нагрузку, но хорошо заходят шутникам

Получила пуш и вспомнила про исследование, которое недавно читала. Исследователи из Ноттингемского университета решили проверить, как люди воспринимают сарказм и иронию в тексте. Тест проводили с помощью айтрекинга — смотрели на фиксации взгляда при чтении.

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

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

🔸 Формулировки с отрицанием люди больше склонны воспринимать как саркастичные, чем утвердительные. Сарказм с «не» считывается проще.
То есть из вариантов: «он лучший учитель» и «он не самый лучший учитель» люди примут за сарказм второй, трактуя это как: он далекооо не самый лучший.

Стас Аки написал о принципах дизайна интерфейса Readymag. Некоторые тезисы:

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

In English со стильной вёрсткой. #principles

Михаил Руденко написал, как определить проблему потребителя.

— У бизнеса нет подходящего языка для описания сущности, которая выступает причиной, приводящей клиента к покупке. В продакт-менеджменте её называют проблема, в маркетинге – потребность, но нет нормального определения;
— Нет универсальной модели, применимой для любых потребителей и продуктов, которая позволит не только понимать поведение клиентов, но и адекватно на него отвечать, создавая ценностные предложения;
— Почему сложно ответить на вопрос «Какую проблему клиента решает продукт»? Проблема не существует сама по себе, а проявляется в контексте;
— Надо определить а) желаемое состояние, которое характеризуется определёнными объективными обстоятельствами и субъективными переживаниями, б) ситуацию возникновения потребности со своими обстоятельствами (давление ситуации) и переживаниями (дискомфорт), в) барьеры, мешающие перейти в желаемое состояние;
— Желаемое состояние должно возникать именно в связи с попаданием в ситуацию возникновения потребности. Можно годами смотреть в зеркало и представлять себя стройным, но ничего для этого не предпринимать. В спортзал человека приводят ситуации: не влез в любимую одежду, услышал, что называют толстяком, и так далее;
— Барьеры, мешающие перейти в желаемое состояние, — проблемы, за решение которых клиенты готовы платить. Они тоже могут быть связаны с обстоятельствами или субъективными ощущениями. Их полезно разделять на барьеры, связанные и не связанные с опытом (своим и чужим) использования альтернативных решений;
— Проблемы лучше формулировать в риторике присутствия: «Отсутствие таск-менеджера» → «Неразбериха с задачами». У первой проблемы есть только одно решение — внедрение таск-менеджера, нет выбора и конкуренции решений;
— Иногда путают проблему и задачу: «Мы решаем проблему подготовки документов для налоговой». Подготовка документов — задача, которую надо выполнить. Само её наличие не гарантирует, что клиент купит для этого какой-то продукт;
— Потребность — это про то, что клиент хочет. А проблема — почему клиент не может получить то, что он хочет, не потратив свои деньги.

#problem

В Purrweb написали об адаптации интерфейса для стран Ближнего Востока.

— Там пользователи читают справа налево, поэтому текст и числа на арабском выровны по правому краю, а привычная компоновка элементов отзеркалена по горизонтали;
— Слова или предложения на английском (или другом языке, на котором читают слева направо) выравнивают по правому краю, но порядок букв не трогают (то есть название PayPal так и будет отображаться);
— Если на английском целый абзац, его выравнивают по левому краю;
— Имеет смысл на 10% увеличивать кегль для текста в заголовках и на кнопках, так как в арабском языке и иврите нет заглавных букв;
— Числа (и номера телефонов), записанные западными арабскими цифрами (1235) пишутся слева направо, а восточными — справа налево. Исключение: цифры как часть контрола по оценке рейтинга будут располагаться в соответствии с направлением чтения;
— В направлении чтения надо разворачивать иконки, где показано движение (мотоциклист будет ехать справа налево, звук из источника лететь влево), символ текста, есть метафоры направлений назад и вперёд (стрелки «Назад» и Undo будут указывать вправо), ползунки для выбора значения в фильтрах;
— Не надо разворачивать: иконки с направлением движения по часовой стрелке и против часовой, объектами реального мира (в том числе у которых ручка справа — они просто ориентированы на правшей), логотипы и универсальные знаки (вроде галочки Check). А также аудио- и видеоплееры.

#localization

Джейсон Ван написал о мышлении новичка.

— Это состояние, когда человек открыт для нового, даже если ему знаком процесс или предмет, с которым он взаимодействует;
— Человеческая природа такова, что мы быстро привыкаем к повседневным вещам и уже через эти привычки воспринимаем окружающий мир. У людей обычно нет вопросов к привычным вещам;
— Это возможность для дизайнеров: сложившийся порядок вещей может быть не оптимальным или вовсе неправильным;
— Мышление эксперта противоположно мышлению новичка: все границы очерчены, а решения известны и ограничены. Кстати, об этом писал Генри Форд: «Но таковы уж все умные люди: они так умны и опытны, что точно знают, почему нельзя сделать то-то и то-то, и везде видят ограничения и препятствия. Поэтому я никогда не нанимаю на работу чистокровного специалиста. Если бы я хотел уничтожить конкурентов, я предоставил бы им полчища специалистов. Получив массу „полезных“ советов, мои конкуренты не смогли бы даже приступить к работе»;
— Мышление новичка полезно для инноваций, но его надо тренировать: осознавать, что привыкли использовать мышление эксперта, отбрасывать предубеждения и задавать вопросы, почему что-то работает именно так;
— Обращайте внимание, когда люди при взаимодействии с продуктом немного расстраиваются, но считают, что всё нормально. Возможно, они просто привыкли.

In English. #thinking

В Heads and Hands написали о приоритизации фич по модели Кано.

— Все фичи можно разделить на базовые, желаемые и восхищающие. Первые определяют жизнеспособность продукта, а остальные — его конкурентоспособность;
— Базовые фичи должны быть в продукте по умолчанию. Люди к ним привыкли, раздражаются и перестают пользоваться продуктом, если их нет. Например, отправка и получение электронных писем;
— Желаемые — повышают уровень сервиса и помогают выделиться среди конкурентов. Чем лучше они развиты, тем выше люди оценивают продукт и тем больше готовы платить. При этом они не перестанут пользоваться продуктом, если их нет. Например, облачное хранилище для документов из электронных писем;
— Восхищающие — вызывают вау-эффект и запускают сарафанное радио (92% клиентов доверяют ему больше, чем рекламе), люди не ожидают их увидеть. Например, встроенный сканер документов;
— Чтобы понять, какие фичи к какой категории стоит отнести, можно опросить представителей целевой аудитории (пример анкеты есть в статье);
— В первую очередь надо инвестировать в базовые фичи и доводить их до идеала. Далее надо выбрать и развивать несколько желаемых фич, чтобы продукт стал конкурентоспособным. Потом можно переходить к восхищающим;
— Важно помнить: восхищающие фичи завтра могут стать желаемым, а через несколько лет — базовым.

#prioritization

Я не читала книгу «Спроси маму», потому что считала, что она для новичков в интервьюировании. Но она попалась мне в фикспрайсе (там кстати клевые книги продают, прикиньте да) и я решила, что это судьба.

Вобщем, книга реально для самых маленьких, а ещё она сама маленькая и читается за 3 часа.
Короче, вот основные тезисы (но прочитать стоит целиком ради смешных примеров):

⭐️ говорите с людьми об их жизни: проблемах, заботах, целях, ограничениях

⭐️ не пытайтесь продать свою идею, вообще о ней не говорите, просто задавайте вопросы о жизни респондентов

⭐️ начинать интервью с фразы «мы разрабатываем приложение для N и хотим задать вопросы об этом» - такое себе.

⭐️ люди начинают врать, чтобы вас не обидеть, как только вы даёте повод (выпрашиваете похвалу, спрашиваете о будущем или продаёте им идею)

⭐️ спрашивайте о фактах в прошлом, а не мнение о будущем

⭐️ мнения бесполезны

⭐️ люди знают о проблемах но не знают как их решать

⭐️ некоторые проблемы фактически не являются проблемами, а люди просто ноют. Уточняйте насколько важна проблема.

⭐️ наблюдая мы видим реальные проблемы, а не то как люди о них говорят

⭐️ если потенциальные клиенты не пытались найти решение проблемы самостоятельно, они не обратят внимания на ваше решение

⭐️ люди не будут вам помогать без понятной на то причины

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

⭐️ переходите к конкретике и уточняйте ответы вида «я всегда…», «я бы поступил так…», «я бы мог…»

⭐️ если вам предлагают решение, копайте зачем оно и как без него сейчас. Возможно, вполне неплохо.

⭐️ спрашивайте об эмоциях

⭐️ не надо быть воодушевлённым своей идеей, вас будут жалеть и врать

⭐️ меньше говорите

⭐️ задавайте вопросы, которые могут до основания разрушить вашу идею

⭐️ идея может оказаться 💩, но это хорошая новость

⭐️ интервью - не панацея от рисков выпустить 💩

⭐️ отбросьте формализм: пусть интервью превратится в «случайную» беседу в рандомном месте (в курилке, после собрания, на кухне)

⭐️ «добро пожаловать на интервью, спасибо что согласились уделить нам время» - такое себе. Не душните

⭐️ в живую всегда лучше


Ещё там кучка советов для стартаперов, но нам-то до них какое дело, правильно, мы тут пиксели двигаем

Юлиана Пономарёва написала, как презентовать команде результаты исследования.

— В «Контуре» есть внутреннее агентство, которое помогает командам без UX-исследователей: погружается в контекст настолько, чтобы провести качественное исследование, но не настолько, чтобы принимать решения;
— Обычно это начальные и средние стадии развития продукта, и команде ценна каждая мелочь, которую получается узнать о пользователях;
— Результаты исследования оформляли в виде лонгрида и презентовали на встрече (1–1,5 часа): гипотезы, выборка, результат проверки гипотез, что говорили пользователи (с цитатами, нарезками аудио, описанием их специфики), выводы, рекомендации, что ещё стоит поисследовать;
— Перед презентацией полезно докрутить формулировки с основным заказчиком исследования — помогает закрыть боль с недостаточным погружением в процессы, предметную область и принятые в команде термины;
— Команды работали с результатами самостоятельно и возвращались к исследователям уже потратив много лишних ресурсов. У исследователей возникало ощущение работы в стол;
— Изменили цель встречи: максимально полная передача контекста → принятие решений о дальнейших шагах. Лонгрид → доска в Miro; дословные транскрипты → резюме; много текста → скриншоты, стикеры, emoji; длинный монолог исследователя → рассказ на 15–20 минут с информацией, необходимой для принятия решений;
— Добавили 30 минут работы со списком всех обнаруженных проблем, идей и связанных с ними рекомендаций. Задача: по каждому пункту зафиксировать решение или дальнейшие шаги;
— Команды стали быстрее принимать решения на основе исследований, исследователи стали видеть результаты своей работы;
— Важно выбирать структуру и состав ребят на встрече (надо знать, кто за что отвечает), отталкиваясь от цели и тех решений, которые сейчас важно принять.

#research

Алисия Суска написала о дизайн-долге.

— Долг UX-дизайна характеризуется несогласованностью при взаимодействии с продуктом, более сложным внедрением новых функций. Это самый распространённый и важный тип дизайн-долга. Погашать его надо в первую очередь, так как такой продукт хуже привлекает новых и удерживает старых клиентов;
— Операционный долг — невыстроенные процессы или недоработки в рамках текущих процессов. Например, отсутствие дизайн-системы (когда она необходима), устаревшие макеты, отличающиеся от реализации, хаос в слоях, стилях и компонентах. Он замедляет скорость работы дизайнеров и разработчиков;
— Визуальный долг — непоследовательность в визуальной части продукта. Если этим пренебрегать, продукт будет выглядеть менее профессиональным и надёжным, и доверие к нему может снизиться;
— Они возникают из-за: 1) Отсутствия доработки после внедрения первой версии новой функциональности; 2) Ограниченного бюджета и срока, что влияет на полноту дизайн-процесса; 3) Технического долга, когда на дизайн влияют ограничения текущей инфраструктуры; 4) Отсутствия лидеров, которые могли бы управлять уровнем дизайн-долга, обучая команду, выбивая нужные ресурсы, формируя единое видение и правильные процессы; 5) Отсутствия инвестиций в решения, которые позволяют масштабировать продукт;
— Чем больше и старше компания, тем больше у неё дизайн-долг. Влияет на это и количество продуктов, и особенности в процессе принятия решений. Но у таких компаний больше ресурсов для погашения дизайн-долга, если это будет в приоритете.

In English. Смотрите также статью Сэма Айронса о дизайн-долге. #process

Опубликованы видео со 2-й конференции по цифровой доступности (о пользовательском опыте людей с разными нарушениями).

1. Евгений Арнапольский — незрячий пользователь программ экранного доступа (скринридеров). Проводя аналогии между физическим и цифровым миром, рассказал об ассистивных технологиях, а также на примерах Госуслуг, Вконтакте, Сбермаркета и других сервисов показал барьеры в интерфейсах.

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

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

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

5. Алексей Цаплин — слабовидящий пользователь, использующий одновременно увеличение и программу экранного доступа. С какими трудностями он сталкивается на примерах Пятёрочки, Самоката, Вконтакте и других.

#accessibility

Костя Малков выписал главные мысли и примечательные цитаты из книги Кена Косиенды «Творческий отбор. Как создавались лучшие продукты Apple во времена Стива Джобса».

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

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

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

#process

Эдвард Скотт написал о хлебных крошках в мобильных версиях интернет-магазинов.

— Основная навигация в них обычно скрыта: пользователю сложнее понять, где в иерархии сайта он находится, а также сложнее перемещаться через главное меню;
— Хлебные крошки делают жизнь пользователя проще;
— Размещайте в них полный путь к текущему товару или хотя бы ключевые уровни иерархии;
— Чтобы они не были слишком длинными: а) избегайте чрезмерной категоризации (то, что должно быть фильтром, может быть ошибочно реализовано как категория), б) уберите из них ссылки на главную страницу (на неё можно попасть, нажав на логотип) и текущий товар, в) сократите названия категорий;
— Если строка с хлебными крошками всё ещё слишком длинная, дайте прокручивать её по горизонтали. Для большинства пользователей это естественно (особенно, если начало или конец строки будут обрезаться и тем самым намекать на возможность прокрутки);
— Добавьте отступы, чтобы строка с хлебными крошками не сливалась с другими элементами в верхней части страницы;
— Их оформление должно отличаться от других элементов на странице. Используйте подчёркивание и стандартные разделители > и / между уровнями иерархии.

In English. #breadcrumbs #ecommerce