Антон из X5 Tech написал о загрузочных экранах.

— Чем сложнее страница, тем дольше ждать, пока её отобразит браузер. Из-за долгого ожидания пользователь может уйти;
— Сайт может отдавать браузеру часть кода, чтобы пользователь мог что-то увидеть (загрузочный экран), пока загружается всё остальное;
— Загрузочный экран нужен, если ждать (даже периодически) надо больше 3 секунд;
— Чтобы он не мелькал при быстрой загрузке, поможет анимация появления: 350−500 мс для страницы и 250−350 мс для отдельных блоков;
— О необходимости и типе загрузочного экрана стоит думать при проектировании продукта, чтобы потом не переписывать код;
— Надо понять причины долгой загрузки: тормозить может часть страницы (большая таблица, длинный список) или отдельный компонент (получает данные из стороннего сервиса с низкой производительностью);
— На загрузочном экране может быть спиннер или другая зацикленная анимация (включая стилизацию под скелетон), которая даёт понять, что загрузка идёт;
— Технически сложнее отображать прогресс, чтобы пользователь понимал, сколько ещё ждать. Надо уметь определять, какие файлы нужны, их вес, скорость загрузки. Лучший вариант для ожидания больше 10 секунд;
— Скелетон — серые плашки вместо практически каждого элемента загружаемой страницы, показывающие реальную её структуру. Обычно с анимацией волны (для быстрой работы) или пульсации (для неспешной работы, когда цена ошибки высока);
— Отображается на доли секунды позже других загрузочных экранов, так как содержит вёрстку страницы;
— Позволяет загружать страницу частями. Если первой загрузится навигация, пользователь сможет перейти в другой раздел, не дожидаясь загрузки ненужного контента;
— Ещё можно загружать данные фоном. Пользователь выбирает файл для редактирования, можно загружать ресурсы редактора;
— Или попытаться отвлечь, отображая во время ожидания советы по функциональности, мини-игры и так далее;
— Консистентность: если используете скелетоны, спиннер в раскрывающемся списке будет выглядеть неоднородно;
— Приёмы можно комбинировать, например, отображать скелетон и ненавязчивый прогресс-бар, если загрузка длится долго.

#loader

Майя Азарова написала о хоторнском эффекте.

— Люди часто ведут себя иначе, если знают, что за ними наблюдают;
— Они склонны отвечать на вопросы таким образом, чтобы казаться лучше;
— Это проявляется в пользовательских исследованиях;
— В полевых исследованиях люди сначала контролируют свои действия, но быстро возвращаются к привычному поведению, если им комфортно (не думают, что их осуждают) и они не против присутствия исследователя;
— Важно наладить контакт. В контекстуальных исследованиях стоит выбирать сессии подлиннее (60−90 минут) и проводить несколько сессий с одним и тем же респондентом (или командой);
— Во время пользовательского тестирования респонденты могут взаимодействовать с интерфейсом более настойчиво, внимательно и терпеливо, чем делают обычно;
— Предлагайте на тестировании задачи, которые выглядят реалистично для вашей целевой аудитории;
— Разряжая обстановку непринуждённой беседой, не будьте слишком дружелюбными, чтобы участники не хотели вам понравиться;
— Заверьте, что результаты не выйдут за пределы исследования;
— «Пожалуйста, скажите нам честно, что думаете. Любая обратная связь, как хорошая, так и плохая, будет полезна. Мы не обидимся. Мы просто хотим сделать дизайн лучше»;
— «Мы проверяем не вас или ваши знания по теме. Мы проверяем дизайн. Если вас что-то сбивает с толку или вы в чём-то не уверены, нам будет полезно это знать»;
— В опросах можно предложить загрузить дополнительные материалы. Они станут доказательствами достижений, проблем или конкретных обстоятельств и помогут лучше понять контекст респондента;
— На деликатные вопросы бывает трудно ответить прямо. Можно задать серию косвенных вопросов. Люди реагируют на них менее эмоционально.

In English. #research

Маргарита Романова написала об управлении доступом к платным возможностям Фигмы.

— Проблема: непонятно, откуда в пространстве появляются редакторы, за которых надо доплачивать сверх плана;
— Команда в Фигме — общее пространство, где хранятся проекты с файлами;
— На тарифе выше Professional появляется сущность «Организация», которая может включать несколько команд;
— У Фигмы есть Design seat и DevMode seat, к каждому может быть доступ Full (платный), Viewer и Viewer-restricted (бесплатные);
— Причина проблемы: в отличие от Viewer-restricted, пользователь с доступом Viewer может самостоятельно переключиться на Full;
— Это происходит, например, когда он переносит файл из черновиков в пространство команды, создаёт файл в проекте, редактирует файл, которым поделились с доступом «Can edit» (на плане Professional, Organization), нажимает на «Edit file» (на плане Enterprise);
— Запретить это можно, установив Viewer-restricted каждому пользователю с доступом Viewer. Можно сделать его доступом по умолчанию для всех новых пользователей (настройка Default seat type);
— Если у пользователя Full seat в 2 разных командах, которые не в одной организации, за доступ заплатит каждая команда;
— На месячном тарифе (на плане Professional), оплата списывается только за пользователей, у которых Full seat на день оплаты;
— На годовом можно выдавать Full seat в пределах количества, выбранного при подписке. Раз в месяц (в число, когда происходит годовая оплата) Фигма проверяет количество Full seats и выставляет счёт, если это количество превышено;
— Добавить мест в годовую подписку можно в любой момент (оплата спишется в конце года), убавить — за 2 недели до годовой оплаты;
— На планах Organization и Enterprise Фигма раз в квартал проверяет количество Full seats. Если есть превышение, в течение 2 недель можно подтвердить добавление этих мест в подписку (с оплатой в конце года), перевести часть на бесплатные места или ничего не делать, тогда дополнительные места добавятся автоматически;
— Можно настроить ежедневный Seat upgrade digests и узнавать обо всех повышениях доступа до Full с комментарием, превышают ли они ваш план.

#figma #management

Никита Денисенко поделился мыслями о дизайне экосистем.

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

#ecosystem

Анастасия Жичкина и Константин Ефимов написали, сколько респондентов достаточно.

— Люди по-разному используют ваш продукт. Эти отличия могут быть описаны как сегменты или персоны;
— Ответ на вопрос о количестве респондентов зависит от ответов: 1) Сколько человек на сегмент нужно; 2) Сколько сегментов берём;
— На первый ответ большое влияние оказывает давление ситуации: сроки и бюджет. Поэтому авторы почти никогда не берут 10 человек на сегмент, как рекомендует Штейнберг;
— Виктор Йокко предложил формулу, которая хорошо описывает реальность формирования выборки: (3 человека на сегмент × Коэффициент неизученности × Количество сегментов / Опыт исследователя) − Ограничение ресурсов;
— Коэффициент неизученности: существующий продукт (1), создание нового продукта (2), обобщение, не связанное с выпускаемым продуктом (3);
— Опыт исследователя: нет (1), за каждые 5 лет опыта (+0,1);
— Ограничение ресурсов: нет (0), есть (вычитаем произвольное количество респондентов, если не хватает ресурсов);
— Можно сделать сплиттинг — взять меньше человек для изучения менее важных сегментов;
— Сколько сегментов брать? Штейнберг выделяет сегменты: 1) Типичные носители практики — взяли кредит у нас; 2) Нетипичные носители практики — взяли кредит у нас, получая пенсию по инвалидности; 3) Носители типичных свойств, но не практики — взяли кредит у конкурентов; 4) Эксперты — кредитный аналитик;
— Обычно достаточно типичных носителей практики: чужие клиенты нужны для поиска конкурентного преимущества, экспертов искать сложнее и дороже, а нетипичные носители практики приносят меньше прибыли;
— При этом может быть несколько вариантов практик, например, ипотека и потребительские кредиты;
— Сегмент — это люди, которые одинаково используют, покупают или воспринимают продукт. Как до исследования узнать о различиях между людьми? Можно предположить, например, разделив их по сумме кредита, полу и возрасту;
— Но итоговая сегментация может отличаться. В ходе исследования может выясниться, что пол и возраст не важны, а на использование продукта влияет, например, нужен кредит срочно или человек готов подождать;
— Экспертов стоит включить: а) когда ничего не известно о рынке и нужная информация не гуглится, б) когда информации много, но она противоречива и её тяжело обобщить.

#interview

Егор Камелев написал, что делать со странной обратной связью клиентов.

— Если клиент предложил какую-то дичь, не стоит сразу резко возражать. Он может не понимать специфики, не знать терминов;
— Поблагодарите за идею и постарайтесь выяснить, в чём суть, откуда идея возникла и какие цели преследует;
— Покажите заинтересованность в её реализации, прикинув, во что она выльется, и обсудив преимущества и недостатки;
— Клиент не захочет отстаивать провальную идею. Но будьте готовы, что она может и превзойти ваше изначальное решение;
— Полезно сохранять отброшенные в процессе варианты. Так можно показать, что проработали и забраковали определённые идеи (среди которых может оказаться и идея клиента). И что предлагаете не первое попавшееся решение;
— Чем больше комментариев клиента учтено, тем ценнее для него результат (что это за когнитивное искажение, напишите в комментариях);
— Если он преждевременно комментирует что-то незаконченное (список товаров без постраничной навигации), можно ответить «Отличное замечание, добавлю», а не говорить, что это лишь промежуточный результат и вы всё равно собирались её добавить;
— Если вы отдали результат 2–3 недель работы, его непросто изучить. Ждите нескольких пачек комментариев, иногда странно сформулированных и противоречащих друг другу. Лучше получать обратную связь чаще по меньшему объёму работы.

#client

Ирина Сильянова рассказала, как писать интерфейсный текст. Вот некоторые из рекомендаций:

— Представьте, что интерфейс — это диалог. Заголовки, подзаголовки и подсказки — ваши реплики. Текст на кнопках и других контролах — пользователя. Ира Моторина делает так же в сторифреймах;
— Текст на кнопках органичнее от первого лица («Save my spot»). Когда пользователь на кнопку нажимает, он как будто произносит свою реплику;
— Текст должен отражать, что произойдёт после нажатия. Не «Стать инвестором», а «Открыть счёт», так как сначала пользователь откроет счёт, потом пополнит и только потом купит акции;
— Не обещайте того, чего не можете гарантировать. Не «Получить код», а «Отправить код», если смски с кодом иногда теряются;
— Если надо убедить пользователя что-то сделать, сначала объясните, зачем, потом расскажите, как: «Чтобы X, сделайте Y»;
— Не объясняйте, как взаимодействовать с элементами интерфейса. Вместо «Введите имейл» достаточно поля с лейблом «Имейл». В поле поиска лучше писать не «Поиск», так как с лупой и так всё понятно, а подсказать, что именно можно найти;
— Осторожнее с неконкретными заголовками вроде «Почти готово», «Кое-что ещё». Они могут хорошо работать, когда соответствуют тону и появляются в связных сценариях. Но если на таком экране отвлечься от сценария, придётся потом вчитываться в остальной текст. Заголовок и кнопки должны быть понятны без основного текста;
— Если есть техническая возможность, избавьте пользователя от вычислений. «Вы можете пополнить депозит максимум на $1000 в течение календарного месяца» → «До 31 января вы можете пополнить счёт на $400»;
— Чтобы люди меньше задумывались, избегайте отрицаний. «Не используйте специальные символы и пробелы» → «Используйте только цифры и буквы». Плюс запреты никто не любит;
— Всю важную информацию размещайте в начале текста. Детали, вводные и вежливые слова оставьте на потом. От чрезмерной вежливости вообще стоит отказаться ради лаконичности.

In English. #writing

Я создал чат для читателей UX Notes. Он должен стать пространством для уважительного общения профессионалов, работающих в сфере UX-дизайна и смежных сферах.

В комментариях к постам в UX Notes это общение было ограничено темами публикаций, в чате же такого ограничения нет. Приносите ссылки на свои материалы, мероприятия и вакансии ваших компаний, обсуждайте принесённое и так далее. Но прошу уважать собеседников и не спамить.

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

— Егор Камелев, @ekamelev — о проектировании, работе на фрилансе и создании своего продукта;
— Игорь Штанг, @nobelfaik — о типографике и вёрстке и отдельно о дизайне таблиц;
— Саша Бизиков, @bizikov — о дизайне презентаций.

Присоединяйтесь: @uxnoteschat

Вячеслав Лазарев написал о баннерной слепоте.

— Это способность пользователей игнорировать баннеры на сайтах;
— Человек обращает на них внимание, когда видит впервые. Затем он осознанно избегает то, что похоже на баннеры. Со временем это приводит к неосознанному игнорированию;
— Таким образом, реже их игнорируют люди с небольшим опытом взаимодействия с сайтами: дети и пожилые;
— Так как структура многих сайтов похожа, люди могут игнорировать целые области, где обычно находятся баннеры;
— Ненадолго повысить заметность баннера можно, выбрав для него необычное местоположение;
— Баннерная слепота — не частный случай перцептивной слепоты, так как низкая когнитивная нагрузка не делает баннеры заметнее;
— Но отказываться от баннеров не стоит. Их видит около 60% пользователей. Их довольно легко внедрить;
— Люди, которые не видели баннеров, потом их узнавали. То есть баннеры могут повысить узнаваемость товаров и брендов;
— Лучше распознаются баннеры релевантные и без яркой эмоциональной окраски (свойственной рекламе).

#psychology

Юля Кондратьева написала о сложностях при создании интерфейсов для арабских пользователей.

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

#localization

Илья Полянский рассказал, как делать чистые градиенты.

— Градиент — переход одного цвета в другой;
— Грязными принято называть градиенты, у которых в середине перехода можно увидеть серое пятно;
— Цветовую моделью RGB можно представить в виде куба, в ядре которого находятся оттенки серого;
— Поэтому все градиенты, проходящие через ядро (например, от жёлтого к синему) или рядом, будут довольно грязными;
— При переходе по поверхности куба (например, от жёлтого к зелёному) градиент будет чистым;
— Если нужен чистый переход именно от жёлтого к синему, можно добавить промежуточную точку или несколько;
— В цветовой модели HSB можно пропускать серые зоны, увеличивая значения Saturation и Brightness на 5−15 единиц. Hue не стоит увеличивать больше чем на 5 единиц, иначе появятся цвета, слабо связанные друг с другом;
— Есть сервисы, генерирующие радиальные переходы.

Копия статьи. #image #color

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

В UX Notes с тегом #career есть уже немало материалов от ребят, которые искали работу и поделились своим опытом:

— Дима Марков рассказал о поиске работы дизайнером в Германии;
— Сергей Шандарин написал о поиске работы дизайнером за рубежом (после 24 февраля);
— Маргарита Романова написала о поиске работы продуктовым дизайнером в Европе;
— Ксения Стернина рассказала, что международные компании ценят в UX-специалистах;
— Ольга Шаврина написала о поисках работы UX-дизайнером в Барселоне.

Если у вас есть подобные статьи на примете, закидывайте в комментарии ↓

Виталий Фридман написал о хлебных крошках.

— Навигация бывает 3 типов: которая помогает двигаться вперёд, назад и вбок;
— Выделение текущей страницы в меню упрощает движение назад и вбок, если человек не смог решить на ней свою задачу;
— Хлебные крошки (Breadcrumbs) показывают, где пользователь находится в иерархии сайта, и позволяют двигаться не только назад, но и вбок (шаг назад и шаг вперёд);
— Они нужны, если у сайта 3 и более уровней в структуре. Вместо хлебных крошек, состоящих из одной ссылки, лучше разместить название раздела рядом с заголовком страницы. Но чтобы было похоже на ссылку, как в The Economist;
— Из поисковых систем люди часто переходят сразу на внутренние страницы сайта. Хлебные крошки помогают понять, куда человек попал и как организован сайт;
— Ссылки в хлебных крошках часто разделяют стрелками, направляют их обычно вправо;
— Располагайте хлебные крошки под основной навигацией сайта;
— Иногда встречаются дополнительные «хлебные крошки» над хедером, позволяющие перемещаться между связанными сайтами;
— Все названия страниц более высокого уровня должны быть ссылками и визуально отличаться от указателя текущей страницы;
— Иногда его не отображают. Можно не дублировать название страницы, если хлебные крошки рядом с заголовком. Но если далеко, этот текст поможет пользователям ориентироваться;
— Не сокращайте текст ссылок, иначе будет сложнее понять структуру. Если хлебные крошки не влезают, лучше раскрывать часть ссылок по нажатию на многоточие;
— На мобильных сайтах иногда отображают по одной ссылке (родительской) за раз, но лучше показывать столько ссылок, сколько возможно. Можно показывать всё, но с горизонтальной прокруткой.

In English. #breadcrumbs

Богдан Игнатьев написал, как проходить дизайнерский Whiteboard Challenge (частая практика в западных компаниях).

— Он позволяет в реальном времени оценить способности кандидата креативно мыслить, решать задачи, коммуницировать, презентовать, работать с ограничениями и неопределённостью;
— И всё это в стрессовых условиях: среди незнакомых людей, на важном собеседовании, за ограниченное время (час);
— Почему не тестовые задания: дизайнеры часто отказываются от неоплачиваемых тестовых, они занимают много времени, сложнее увидеть ход мыслей, кандидат может попросить кого-то помочь с тестовым;
— Как проходить. При постановке задачи записывайте. Так вы покажете, что активно слушаете и уделяете внимание деталям, и не забудете важные данные;
— Проговорите, как вы поняли задачу и что должно быть на выходе. Так вы убедитесь, что всё поняли правильно;
— Задавая уточняющие вопросы, объясняйте, чем вам поможет ответ;
— Будьте готовы разделить проект на части и выделить минимально необходимую функциональность;
— Расскажите об обязательных фичах, на реализацию которых вам не хватит этого часа;
— На этапе идеи (20 минут): чем больше идей и чем лучше они проработаны, тем лучше;
— Знайте свой инструмент (горячие клавиши и так далее). Чем меньше водите курсором по экрану, тем больше успеете сделать;
— Забудьте о красоте. В первую очередь оценивается UX и подход к поиску решения;
— На этапе обратной связи: если работодатель не говорит, что хорошо, что могло быть лучше, и можно ли считать, что задача решена, спросите сами;
— Говорите вслух, объясняйте ход своих мыслей;
— До собеседования: практикуйтесь в решении задач (например, UX Challenge или UX Tools) и быстрой и эффективной визуализации идей на белой доске.

#career #whiteboard_challenge

Аня Попова рассказала о таком способе тестирования юзабилити как домашнее задание.

— Обычное модерируемое тестирование не подходит, если выполнение задачи занимает у пользователя более 2 часов, требует вникать в документацию и использовать другие сервисы;
— Домашнее задание — это задание, приближенное к рабочим задачам, которое пользователь выполняет в удобное время (и даже в несколько подходов), записывая экран и комментируя происходящее;
— В инструкцию для участников включите, как сделать запись экрана и что делать после завершения задания;
— Вводное интервью на 15 минут позволит лучше узнать профиль респондента, подробнее рассказать о процессе, согласовать сроки, ответить на вопросы;
— Важно донести, что вы не тестируете их навыки и компетенции, а хотите выявить проблемы при использовании продукта;
— Выполняя задание, респонденты будут задавать вопросы, поэтому предусмотрите, кто и через какой канал связи будет на них отвечать. Учтите, что часто это происходит в нерабочее время;
— Респонденты могут быть профи с загруженным графиком, из-за чего домашка отодвинется на второй план. Связывайтесь с ними во время исследования, чтобы напомнить о сроках и узнать, нет ли у них проблем с выполнением задания;
— Опыт Selectel: около 10% из них отвалится, сроки исследования сильно растянутся;
— Финальное интервью на 30 минут с участием продуктовой команды позволит респондентам поделиться общим впечатлением и основными сложностями, а вам — прояснить детали из видеозаписей;
— Небольшой опрос, суммирующий опыт респондента, поможет собрать более структурированную обратную связь;
— Плюсы: наблюдение за процессом целиком (походы на сторонние сайты за помощью, как люди вообще действуют, решая задачу) позволяет получить более глубокие инсайты, естественная среда, информативнее интервью, убедительно для команды;
— Минусы: задание ≠ рабочая задача, требует много усилий от респондента, долгий цикл исследования.

#unmoderated

В Контуре подготовили гайд, как навести порядок в макете.

— Настройте автолейауты и констрейнты. Разработчик быстрее поймёт задумку и воспроизведёт её средствами CSS и HTML;
— Назовите слои единообразно и так, чтобы было понятно, что это за элементы. Multi-edit станет работать лучше;
— Размеры элементов задавайте так, чтобы было понятно, как они ведут себя при изменении содержимого и размеров контейнера. Произвольные размеры мешают понять, как работает макет;
— Группируйте элементы так, как они будут связаны в вёрстке. Можно показать область ховера, объяснить логику отступов между ними;
— В компонентах используйте варианты вместо скрытия слоёв или множества отдельных компонентов. Заполненные значения не будут сбрасываться, меньше нагрузка на компьютер;
— В их описаниях пропишите ключевые слова с синонимами, как люди называют такие элементы;
— Компонент, который используется только внутри других компонентов, можно сделать приватным, поставив _ в начале его имени. Он не будет опубликован в библиотеке;
— Как только начинаете использовать компонент в разных частях системы, переносите его в библиотеку и подключайте её к нужным макетам;
— В стили можно добавить не только цвета и типографику, но и изображения (например, аватарки), обводки, сетки, тени и другие эффекты;
— Старайтесь не использовать лишних элементов. Аватар можно сделать с помощью заливки фигуры картинкой вместо маски и 2 объединённых в группу элементов;
— Не дублируйте всю страницу целиком, чтобы описать поведение отдельного элемента. Чтобы показать, где происходит изменение, достаточно показать страницу один раз;
— Показывайте состояния элементов рядом, используйте подписи, если они нужны;
— Давайте осмысленные названия секциям. Они видны при зумировании, так проще найти нужные фрагменты макета.

#figma #handoff

Илья Чернышев написал, как уменьшить процент плохих лидов с лендинга.

— Такая задача может возникнуть, если приходит много заявок, которые перегружают отдел продаж, но не приводят к сделкам;
— Добавьте полей в форму заявки, чтобы отсеять недостаточно заинтересованных пользователей;
— Форму можно усложнить, увеличив количество обязательных полей;
— Явно укажите цены на ваш продукт, чтобы фокусироваться на аудитории, готовой к вашим ценам;
— Для услуг можно добавить поле «Бюджет» с вариантами для выбора, из которых будет понятен минимальный бюджет: 10−30к, 30−40к, 40−50к, более 50к;
— Если у вас услуги для бизнеса, можно разместить логотипы крупных брендов, с которыми работали. Но сделайте это не в конце, как обычно делают, а в верхней части лендинга;
— Добавьте фильтрующий вопрос. Например, на лендинге обучающих услуг для детей добавили вопрос «Имя вашего ребёнка», чтобы получать заявки только от родителей. Видя это поле, дети теряются и покидают сайт, а родители спокойно заполняют;
— Оцените эффективность разных способов связи (форма на сайте, чат, звонок и так далее) и сделайте акцент на самых эффективных. Если это звонки, номер телефона сделайте заметнее, повторите несколько раз на странице, а форму заявки перенесите в конец страницы;
— Явно укажите условия, которые могут быть неприемлемыми для нецелевых клиентов. Например, длительные сроки изготовления или доставки, предлагаемые способы оплаты, необходимость предоплаты;
— Можно указать сегменты, с которыми работаете или не работаете. Например, что не работаете с индивидуальными предпринимателями или работаете только в определённых странах или городах;
— Сориентируйте клиента, что после заполнения формы ему надо будет пообщаться с менеджером. Например, это может быть текст кнопки «Запросить звонок менеджера» вместо «Оставить заявку».

#conversion

Маргарита Романова написала первую статью из серии об эффективном прототипировании в Фигме.

— Нелинейный прототип позволяет пользователю отойти от идеального сценария, совершить ошибки. Взаимодействие становится реалистичнее, а инсайты — качественнее;
— Можно проверить интерфейсы, в которых к цели ведут несколько путей;
— В Фигме есть экшен Navigate to, но его лучше использовать для переходов между страницами, а не состояниями одной и той же страницы. Иначе получится куча связанных фреймов, и редактировать такой прототип больно;
— Для возвращения назад используйте экшен Back, он сразу добавляет обратную анимацию;
— Экшен Change to переключает инстанс компонента в заданное состояние. Его достаточно, когда взаимодействие ограничено этим инстансом. Например, пользователь навёл курсор на кнопку, и она изменила цвет;
— С помощью переменных, привязанных к слоям и компонентам, можно сделать так, чтобы действие запускало событие (экшен Set variable), которое будет определённым образом модифицировать эти слои и компоненты;
— Но в этом случае без Smart animate, только Instant;
— Один триггер (например, нажатие на элемент) может приводить к комбинации экшенов. Например, Navigate to и Set variable;
— Популярная ошибка: с помощью Change to настроить, чтобы нажатие на чекбокс ставило или снимало флаг. Если в конкретном сценарии нажатие на него должно делать что-то ещё (разблокировать кнопку), будет 2 конкурирующих набора экшенов, срабатывающих на один триггер (нажатие на чекбокс);
— В этом случае сработают экшены инстанса в сценарии, то есть кнопка в форме разблокируется, а флаг в чекбоксе не появится;
— Решение: сделать интерактивный компонент, но логику привязать к переменной, а не триггеру.

#figma #prototype

Максим Кононов написал о 13 базовых цветовых токенах (без токенов для ховеров).

— Блоки в интерфейсе — контейнеры для элементов и других блоков. Они должны выделяться на фоне родительского блока, создавая структуру слоёв;
— View (1) — блок, на котором отображается контент. Navigation (2) — блок с навигацией, который управляет тем, какие View отображаются;
— Border (3) может отделить два находящихся рядом блока, а также обвести немодальный блок, находящийся поверх остальных (плюс тень);
— Если блок модальный, для затемнения лежащего ниже контента — полупрозрачный Overlay (4);
— Элементы — всё остальное: текст, иконки, кнопки, поля ввода. Они управляют вниманием пользователя, выделяя важное, показывают состояние элемента;
— За внимание отвечают цвета элементов: Primary (5), Secondary (6) и Accent (7), перебивающий Primary;
— Характер задают: Danger (8), Success (9), Warning (10);
— Для фона кнопки — Background (11);
— Указанные выше яркие цвета можно применить не к тексту или иконке в кнопке, а к её фону. Тогда для её содержимого потребуется OnAccent (12);
— Кнопка в состоянии фокуса может иметь обводку с цветом Accent (с небольшим отступом, чтобы не сливаться, если у кнопки такой же фон), а в заблокированном состоянии — красить содержимое в цвет Disabled (13);
— Он же пригодится для плейсхолдера в поле ввода (логичнее было бы его назвать просто Tertiary);
— Также в статье есть о том, как подобрать цвета для этих токенов для светлой и тёмной темы.

Да, в заголовке статьи написано о 12 токенах, но это ошибка.

#color #design_system

В Pathway подготовили минигайд, как проводить немодерируемые исследования. Некоторые рекомендации:

— Исследование должно давать новое знание, которого нет в лучших практиках и предыдущих исследованиях. Не надо проверять иконку лупы в контексте поиска, но можно узнать, понятно ли, что текст «Поехали» означает отправку поискового запроса;
— В общем случае для количественного исследования стоит привлекать 100 человек на сегмент. С уровнем значимости 95% максимальная погрешность будет ≈10%;
— Сценарное тестирование — вид теста, когда респондент совершает простое действие, ради которого нет смысла проводить модерируемое исследование. Пример задания: «Выберите способ оплатить доставку еды на этом экране»;
— В заданиях иногда нужен контекст, чтобы человек понял, что происходит на экране. «Купите ОСАГО» → «Представьте, что вы уже выбрали тариф, срок и вид ОСАГО, заполнили анкету. Пожалуйста, оплатите страховку»;
— Если предлагаете варианты ответа, добавьте вариант «Другое» с возможностью оставить комментарий. Иначе респондент может не найти подходящего варианта, и вы получите недостоверные данные;
— В вопросах не указывайте на элементы интерфейса. Если кнопка называется «Оформить подписку», нельзя спрашивать «Куда нажать, чтобы оформить подписку»;
— Не используйте термины и профессиональную лексику. «Чекаут», «точка входа», «футер» наверняка вызовут затруднения;
— Если возможно, не запускайте тест сразу на всю выборку. Пилотная версия на 20−30 респондентов позволит отловить и исправить проблемы;
— К немодерируемым можно отнести: тест первого клика, Preference-тест или Side-by-side, пятисекундный тест, карточная сортировка, сценарное тестирование;
— В Preference-тесте макеты должны различаться всего одной деталью, отличие должно быть заметным. Лучше не сравнивать похожие оттенки или шрифты, тексты уведомлений или кнопок;
— Перед пятисекундным тестом не предупреждайте об ограничении в 5 секунд и не говорите, на что надо обратить внимание.

#unmoderated

Влад Шиляев написал о синхронизации команды с помощью CJM.

— CJM может быть любой, её структура зависит от того, какую задачу вы решаете;
— Проблема постоянно развивающегося большого (когда разные команды дорабатывают разные части) продукта в том, что у отдельных специалистов (особенно тех, кто не связан с разработкой) нет полного понимания пользовательского пути;
— Иногда нельзя просто взять и пройти путь пользователя, чтобы это понимание получить (а если можно, это требует времени): ограничения разных типов клиентов могут влиять на флоу, не все сценарии могут быть доступны сразу, в них могут быть развилки, в которые за один подход не попасть;
— Стейдж — среда тестирования, которая точно повторяет прод и позволяет создавать тестовых пользователей. В идеале проходить сценарии на реальных устройствах, а не в Xcode или Android Studio;
— Описание всего пути от начала до выполнения поставленной цели позволяет увидеть общую картину и конкретные интерфейсы, найти слабые места и ошибки флоу, сгенерировать новые идеи;
— Структура: цели, шаги и действия пользователя, мобильный флоу (скриншоты интерфейса, по сути Screen flow), десктопный флоу, боли и барьеры, позитивные моменты, идеи по улучшению, отслеживаемые метрики;
— Дополнительно такая карта сокращает обращения к дизайнерам за нужными флоу (можно добавить ссылки на макеты), помогает найти нестыковки между макетами и продом и запланировать их исправление, а также адаптировать новых сотрудников;
— Стоит добавить оглавление с типами пользователей, рассмотренными сценариями, ответственными (к кому обращаться с вопросами и проблемами), а также логи обновлений, чтобы была ясна актуальность карты;
— Так как за стрелками следить сложно (и иногда их бывает слишком много), удобно вставлять блоки с развилками — описанием путей, по которым может пойти сценарий и якорными ссылками на соответствующие участки карты;
— Карта быстро устаревает, если её не обновлять. Обновление карты надо делать частью процесса разработки, выделять на это время в спринте.

#cjm