Дарья Хуторянская написала, что проверить при передаче макетов разработчикам.

— На момент передачи макетов уже проделана огромная работа, и тем обиднее из-за перегруза задачами, ограниченных сроков или неопытности что-то упустить и затем потонуть в уточняющих вопросах разработчиков;
— Проверьте, все ли сценарии взаимодействия с объектами предусмотрели. Помните о CRUD (create, read, update, delete) — операциях, свойственных всем объектам. Составьте карту объектов, их свойств и действий с ними (концепция #ooux);
— Представьте поведение интерфейса, когда данных нет, мало, много (пагинация или скрол, обрезание длинной фамилии или перенос на вторую строку) или достигнут их лимит (технические ограничения, возможность добавить не более 10 фото в профиль);
— Учтите разные варианты завершения пользовательского сценария: успех, ошибка (пользовательская и на стороне системы), загрузка, пустые состояния, онбординг;
— Сверьтесь с ролевой моделью. Например, как будет выглядеть объект, если пользователь может и не может его редактировать;
— Опишите сложные компоненты-организмы: зона клика, поведение при изменении ширины и высоты, разном объёме данных. Спецификация может быть там же, где вы собираете макеты;
— Покажите адаптивные состояния для разных разрешений экрана;
— Соедините макеты стрелочками, объедините отдельные сценарии в блоки макетов, опишите сценарии текстом;
— Если какие-то макеты не ушли в релиз, добавьте комментарии для тестировщиков;
— Добавьте ссылки на описания сложных компонентов.

#handoff

Гифка из статьи ↑, чтобы отправить своим разработчикам

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

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

#research

Александр Мачуговский написал о неактивных кнопках и расположении кнопок в мобильных формах.

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

#form #button #mobile

Александр Григоренко написал о проектировании перетаскивания.

— Drag and Drop — взаимодействие с объектами, состоящее из трёх последовательных операций: захвата (Drag) объекта, перемещения и отпускания (Drop);
— Отлично подходит для: 1) перемещения элемента на новую позицию, 2) изменения размера или формы элемента;
— В отличие от реального мира, в цифровой среде непонятно, что и куда можно перемещать, как захватить (элемент доступен полностью или есть «ручка захвата») и что произойдёт после перемещения;
— Для ручек захвата в интерфейсе нет единой графической метафоры, но есть с годами сложившиеся варианты. Важно придерживаться выбранного варианта;
— Есть специальные курсоры: Grab и Grabbing (macOS) и Move (Windows) для перемещения, No-drop для пересечения с зонами, где элемент нельзя сбросить, с префиксом Rezise для изменения размера;
— Если на объект можно и просто нажать, подберите не слишком быструю или долгую длительность нажатия, которая приведёт к перетаскиванию (50–500 ms);
— Проблема лишних небольших движений курсора при нажатии (Sloppy Clicks) решается порогом дистанции, прохождение которой запускает перетаскивание (3–5 px);
— Объект при перетаскивании должен визуально отличаться от остальных;
— В списке или гриде важно определить, когда сдвигать элементы, чтобы перетаскиваемый мог занять их место. Лучше всего — в момент пересечения края перетаскиваемого объекта с центром статичного. Также потребуется ненавязчивая анимация перемещения элементов (100–500 ms);
— Проще в разработке — не двигать сразу элементы списка или грида, а показывать индикатор возможного положения перетаскиваемого объекта. И так легче не терять контекст старого положения элементов (полезно при работе с mindmap);
— Если зона сброса находится за пределами экрана, поможет автоскрол страницы вслед за перетаскиваемым объектом. На мобильных аккуратно подбирайте его скорость. Ещё можно показывать временное окно для сброса объекта в пределах текущего окна (Drag Lens);
— Предусмотрите отмену перетаскивания клавишей Esc и сбросом элемента в нейтральную зону;
— В целях доступности добавьте альтернативные способы выполнить то, что даёт перетаскивание.

#drag_and_drop

Станислав Хрусталёв собрал примеры, как разнообразить список товаров.

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

#ecommerce

Игорь Штанг (уже давно) написал о висячей пунктуации из 120-го параграфа «Ководства».

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

#typography

Иван Мрачко написал о пользе прототипов в заказной разработке.

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

#prototype

⚡️ Изящно проработанный сценарий получения фидбека.

Vlad Dugnist разместил вот такое сообщение в iOS приложении. Его видно по лонг-тапу, обычно перед попыткой удалить аппку. В итоге c этой точки прилетает 50% от всего фидбека от юзеров.

@tg_knl

Никита Прокопов написал о круглых чекбоксах [In English].

— Чекбоксы от радиокнопок отличаются тем, что они квадратные, внутри отображается галочка, когда чекбокс выбран, можно выбрать любое количество чекбоксов в группе. Радиокнопку в группе можно выбрать только одну;
— В ранних версиях операционных систем (Mac OS 7.5, 1994 год и Windows for Workgroups 3.11, 1993 год) можно встретить крестики вместо галочек;
— Но форма радиокнопок и чекбоксов отличалась уже в 90-х, и операционные системы придерживались этого правила;
— В последнее время в вебе можно было встретить радиокнопки с галочками (Twitter), а также квадратные радиокнопки с галочками (Yandex Maps);
— Веб всегда был пластичнее, но подобное стало встречаться и в нативных приложениях (Telegram for macOS);
— В некоторых продуктах (Yandex Maps, опросы в Telegram Web) рядом можно встретить радиогруппу и группу чекбоксов, которые работают по-разному (чекбоксов можно выбрать несколько), но визуально вообще никак не отличаются;
— Создатели операционных систем до сих пор придерживались изначальной концепции, но теперь в библиотеке Apple для visionOS появились круглые чекбоксы. Видимо, стройной концепции с круглыми радиокнопками и квадратными чекбоксами пришёл конец.

#radio_button #checkbox

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

— Допустимо ли их использовать, зависит от сферы продукта, целевой аудитории, географии и Tone of Voice;
— Скорее да: сервисы для детей, сфера красоты, дизайн. Скорее нет: B2B, B2G, медицина, ToV задаёт строгий официальный стиль;
— С эмодзи 73% людей считают вас более дружелюбным. Но люди постарше чаще воспринимают их негативно;
— Одни эмодзи могут по-разному воспринимать в разных странах. Например, в арабских странах 🙏 (сложенные руки) почти не используется, так как не ассоциируется с молитвой, в Китае 👋 (взмах руки) символизирует разрыв отношений и дружбы;
— Эмодзи хорошо работают на приветственном экране (сделать первый контакт как можно дружелюбнее), при выборе пола или страны (можно заменить иконки), в пустых состояниях (разбавить сухой текст), диалогах (более человечное общение, визуальные якоря), как бейджи (объединить товары в группу), в попапах (показать, позитивное это сообщение или нет, и если нет — немного сгладить негатив);
— Кроме того их часто используют в пушах, формах обратной связи, некоторых кнопках (как замена иконки или усилитель текста);
— В некоторых продуктах вроде Ноушена эмодзи помогают пользователю лучше ориентироваться в своём контенте.

#image

Женя Крупина написала о прокачке нетворкинга в компании через совместный просмотр докладов.

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

#management

Андрей Шапиро написал о схеме преобразования данных в системе с интерфейсом.

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

#analysis

Павел Шерер написал 4-ю статью цикла о функциональной архитектуре.

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

#functional_architecture #process

Я написал, как быстро сделать в Фигме прототип формы, поля которой можно заполнять в любом порядке.

— С этим помогут локальные переменные (Variables) и условия (экшен Conditional);
— Если их не использовать и просто переводить пользователя с одного экрана на другой, для формы из 4 полей потребуется 16 экранов (включая полностью заполненную форму и полностью незаполненную);
— Поля, с которыми будет взаимодействовать пользователь, надо заменить на локальные компоненты с вариантами «Не заполнено» и «Заполнено»;
— Когда пользователь заполняет поле, это надо сохранять в локальную переменную;
— При отображении формы надо проверять переменные и переключать компоненты заполненных полей на нужный вариант: триггер After delay, повешенный на компоненты конкретных полей, плюс экшен Conditional.

#figma #prototype #form

Даниэль Виленчук написал о категоризации фидбека.

— Вы начали собирать обратную связь от пользователей и получили таблицу с 3000 отзывами. Как с ними работать?
— Удалите отзывы без текста. Они могут занимать до половины таблицы;
— Практика показывает, что из отзывов короче 10–15 символов почти невозможно извлечь инсайт. Можно отфильтровать таблицу, бегло просмотреть отзывы короче 5 символов и удалить бесполезные. Повторить для 10, 15 и 20 символов. Так очищается не меньше трети документа;
— Отсортируйте отзывы от А до Я. Самые первые, скорее всего, будут мусорными: состоять из цифр и случайных символов;
— Далее по ключевым словам определите родительские категории, например, сценарии («Оплата и промокоды», «Авторизация») или типы пользователей («Покупатели», «Продавцы»);
— По типу возникающих проблем определите дочерние категории: «Оплата и промокоды / Просроченный промокод»;
— В первый раз придётся самостоятельно идти по отзывам, придумывать категории и расставлять их вручную. Так вы познакомитесь с языком ваших пользователей и сформируете набор ключевых слов, по которым отзыв можно отнести к той или иной категории;
— Проставленные категории дадут статистику, какие проблемы вызывают больше обращений пользователей, и позволят работать с фидбеком точечно, передавать конкретным командам;
— Категории и ключевые слова сохраните для категоризации будущих отзывов.

#feedback

Алексей Тюрин написал, как обезопасить ввод пинкода на телевизоре, когда экран видят другие люди.

— Пинкод закрывает детям и сожителям доступ к настройкам телевизора, подпискам и покупкам, платёжным данным. Особенно актуально, если телевизор находится в публичном месте;
— Также им можно ограничить детей от взрослого контента;
— Люди могут использовать тот же пинкод, например, в банковском приложении, что повышает ставки, если кто-то подсмотрит его во время ввода на телевизоре;
— Раньше не было проблемы ввести код, не выбирая цифры на экране, так как цифры были на пультах;
— Проблему легко решили на приставках (PlayStation, Steam): на контроллере много кнопок, которые можно нажимать вместо цифр;
— В Android TV, Sony Bravia, Samsung Tizen есть безопасный ввод: стрелками ↑ и ↓ на пульте пользователь выбирает на экране группу цифр (1-2-3, 4-5-6, 7-8-9), а кнопками ←, OK, → незаметно для стороннего наблюдателя выбирает левую, правую или центральную цифру в группе;
— Коды иногда используют для отключения родительского контроля. Если ребёнок дошкольного возраста, вместо пинкода для разблокировки взрослого контента можно просто просить ввести решение несложного математического выражения (3×8=?) или цифры, написанные на экране словами (Zero, One, Zero, Two);
— Стоит ожидать появления разблокировки отпечатком пальца или лицом через встроенные в пульт сенсоры.

#tv #login

Таня Мисютина поделилась советами, как упорядочить визуализацию.

— Если на дашборде надо не просто показать общую ситуацию и высокоуровневые данные, но и объяснить, почему так сложилось, в визуализации должна быть та сложность, что была в исходных данных. Дашборд не может быть примитивным;
— Внутренняя сложность не прощает внешней небрежности и запутанности, они сразу оборачиваются нечитаемостью и перегруженностью;
— Используйте один формат для визуализации одних и тех же данных, чтобы не сбивать пользователя с толку разными представлениями;
— Разное должно выглядеть по-разному. Скорее всего, так и будет, если выбирать форматы, отражающие суть данных;
— Придерживайтесь единых и логичных правил отображения элементов на экране (заголовков, фильтров, графиков и конролов) для всех состояний визуализации. Учитывайте иерархию показателей и срезов — от большого к малому, от важного к менее важному;
— Продумайте схему переходов между состояниями визуализации, разными дашбордами в системе. Ни один экран не должен быть «вещью в себе»;
— Используйте одинаковые термины для обозначения одинаковых понятий.

#data_visualization #dashboard

Егор Камелев написал о проектировании форм.

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

#form

Ксения Толокнова и Марина Сапожникова написали о поиске в мобильных приложениях.

— Точкой входа в поиск может быть поле поиска (в верхней, нижней части экрана и ближе к середине; поиск в этом случае — ключевая функция или основной способ взаимодействия с контентом), иконка лупы в нижней навигации (важность функции меньше), иконка лупы в навбаре (важность ещё меньше). Точка входа может быть спрятана, например, в раскрывающемся меню;
— Поиск может быть глобальным (по всему приложению) и локальным (по экрану или разделу), открываться на новом или на том же экране (для локального поиска и фильтрации контента);
— Поисковая выдача может быть простой (однородной), с категориями и фильтрами, с секциями (если хочется разделить контент и не вводить навигацию в виде категорий и фильтров);
— Мультипоиск позволяет обрабатывать несколько запросов одновременно. Например, искать недвижимость в нескольких районах (Zillow) или по фото и тексту одновременно (Google);
— Продумайте, как пользователь будет очищать ввод в поле (скорее всего крестиком в поле) и выходить из режима поиска («Отменить» в iOS, стрелка «Назад» в MD3);
— Результаты лучше выводить после ввода 1–3 символов. Запрос лучше отправлять, когда возникает пауза во вводе;
— Рекомендации до ввода поискового запроса крайне полезны. Кроме повышения удобства (сохранённые, недавние, популярные запросы) они могут стать инструментом дополнительных продаж;
— Не забывайте о подсказках внутри нативной клавиатуры. Их немного, но больше, чем можно разместить в поле поиска.

#search #mobile