Ксения Никульшина рассказала о переходе из бизнес-анализа (10 лет опыта) в UX-исследования (уже 3 года) и поделилась выводами.

— Попробуйте лучше понять свои сильные стороны. Например, можно пройти тест high5 (бесплатный, на английском). Представьте, как вы применяете их на практике;
— «Наблюдая, как работают в дискавери, я наконец-то увидела то, чего так не хватало везде: с самого начала идти от потребностей пользователя, улучшать пользовательский опыт впоследствии — при этом не забывать про бизнес»;
— «Ещё мне очень повезло с возможностью попробовать профессию на вкус: участвовать в планировании исследования, работе с респондентами, анализе полученных качественных данных»;
— Возьмите недорогой курс по теме, на которую нацеливаетесь: во время учёбы поймёте, насколько кайфуете от выбранной области, плюс пригодится сертификат. Ксения выбрала курс Google UX Design;
— Раз в месяц считайте и взвешивайте. Какую ожидаете потерю в деньгах? Насколько она болезненна для вас? А что вам даст выход из надоевшего и переход в желаемое? А теперь?
— Не занижайте свою стоимость на рынке — мол, джуну выше N денег платить не будут. Адекватный работодатель ценит не только хард-скилы, но и опыт в других сферах, софт-скилы, потенциал. Дайте себе время поискать вакансию на желаемую зарплату;
— Сертификат, опыт в дискавери и поиск работы без спешки позволили выйти на позицию middle-исследователя с потерей всего 10−15% в деньгах относительно бизнес-аналитики.

#career

В Яндексе опубликовали исследование настроек доступности, которые включают пользователи мобильного Яндекс Браузера (iOS и Android) в России.

— 51% пользователей (более 20 млн) используют хотя бы одну системную настройку доступности, чтобы адаптировать телефон под свои нужды;
— Зрение: размер текста (35% изменили размер, 28% — увеличили), тёмная тема (27%), экран вслух, чтобы прослушать выделенный отрывок текста или весь экран (6% на iOS), отключение анимации (5% на Android), высокий контраст дисплея (2%), коррекция цвета (1% на Android), скринридер (0,02%), инверсия цвета (0,02%);
— Слух: монозвук, чтобы соединить два канала звучания и подавать их в оба наушника (3%), субтитры (2%), подключение слухового аппарата (0,1% на Android);
— Мобильность (при опорно-двигательных нарушениях): отключение функции встряхивания для отмены (5% на iOS), автоматическое нажатие, чтобы автоматически нажимать, когда курсор какое-то время неподвижен (0,5% на Android);
— Пользователи могут включать эти настройки из-за ситуативных, временных (когда человек заболел) или постоянных ограничений. В исследовании есть примеры таких ограничений, из-за которых люди включают разные настройки доступности.

#accessibility

Андрей Шапиро написал о test-driven design и полезных дополнениях: приём «Штука» и инвентаризация агрегатов.

— В проектировании надо шаг за шагом принимать решения и постоянно держать в фокусе конечную цель;
— Суть в том, что есть одно или несколько условий, которые должны быть удовлетворены, чтобы остановиться в поисках решения;
— «Штука» решает все проблемы и может принять любую форму, это абстрактная сущность, которую ещё предстоит создать;
— В общем случае любая «интерфейсная штука» показывает информацию и даёт манипулировать собой;
— Мы не знаем, как она будет выглядеть и из чего будет состоять, но можем сформулировать, зачем она нужна и что именно должна делать;
— Сформулировав требования, мы можем приняться за итеративное «выращивание» штуки;
— Test-driven development — сначала пишем приёмочный тест, например, что сложение 2 и 3 даёт на выходе 5, и только после этого — код, реализующий алгоритм;
— Подход прекрасно ложится в область дизайна: формулируем набор приёмочных критериев (вопросы, на которые можно ответить «да» или «нет») и затем конструируем решение, пока она не удовлетворит им всем;
— Инвентаризация агрегатов помогает заранее верхнеуровнево понять, из чего будет состоять конструкция. Просматриваем список критериев и выделяем агрегаты — крупные смысловые узлы конструкции интерфейса (например, мультизагрузчик файлов, насыщенная фильтрами таблица) и внутренней логики (обработчики очереди);
— Подход хорошо работает, когда на старте никто не знает, каким должен быть результат, когда нет известного паттерна;
— Позволяет легко сверять курс с другими людьми и валидировать генерируемые решения.

#process

Самхита Танкала написала о запросах на использование файлов cookie.

— Они обязательны, если у вас есть пользователи из стран с законами, дающими людям право контролировать сбор информации о себе;
— Пока человек не согласится, сайт не может использовать cookie, которые хранятся на устройстве пользователя, и создавать новые;
— Эти запросы всё ещё всех раздражают, но уже стали привычными, и люди сформировали разные привычки работы с ними. Не все в нетерпении нажимают «Принять все», часть пользователей настраивает разрешения и ищет возможности отклонить запрос;
— Предоставьте варианты действий: принять все, только необходимые, настроить, отклонить все. Если вариантов слишком мало, часть пользователей это может оттолкнуть;
— Не стоит манипулировать выбором, делая «Принять все» основной кнопкой, пряча альтернативные варианты (например, за ссылкой Learn more) или используя странные формулировки (вроде «Accept without tracking» рядом с кнопкой «Accept all»);
— Желательно не размещать в окне запроса крестик или кнопку «Закрыть», так как непонятно, нажатие на неё — это «Принять все» или «Отклонить все»;
— Не перекрывайте окном запроса содержимое страницы, так как некоторые пользователи хотят сначала понять, что это за сайт, прежде чем соглашаться на использование кукисов.

In English. #legal

20 самых популярных постов UX Notes в 2023 году в Телеграме:

1. Кинерет Ифра написала о пустых состояниях. 66 лайков

2. В Heads and Hands написали о законах UX. 61 лайк

3. Александр Овчаренко написал о красной ночной палитре интерфейса. 60 лайков

4. В Альфа-Банке поделились результатами исследования, как форматирование текста влияет на восприятие и эмоции читателя. 53 лайка

5. Илья Бирман написал об онбординге. 52 лайка

6. Артур Валиуллин написал, как регулярно и весело прокачивать и оценивать навыки дизайнеров с помощью быстрого дизайна. 52 лайка

7. Тарик Шебл написал, почему лучше начинать дизайн с оттенков серого. 51 лайк

8. Никита Семёнов написал о презентации дизайн-решений. 50 лайков

9. Маргарита Романова показала, как без больших трудозатрат повысить интерактивность прототипов в Фигме. 48 лайков

10–13. Николай написал о механиках сервисов знакомств, перспективах развития, особенностях поведения их пользователей и почему люди ими пользуются. 46 лайков

10–13. Никита Геннадьевич изучил исследования о тёмной теме и поделился выводами. 46 лайков

10–13. Евгений Бондковски написал, как упростить восприятие и увеличить скорость работы с таблицей, оформив её содержимое. 46 лайков

10–13. Кира Калимулина написала о тексте для пустых состояний и ошибок. 46 лайков

14. Никита Семёнов поделился своим чеклистом для проверки дизайна интерфейса. 45 лайков

15. Адам Григорян рассказал о презентации дизайна. 44 лайка

16. В Purrweb написали о дизайне приложений для телевизоров. 43 лайка

17–18. Максим Десятых написал, как выбрать наставника в дизайне. 42 лайка

17–18. В Сбербанке подготовили гайд о двух адаптированных вариантах языка: ясном и простом. 42 лайка

19–20. Виталий Фридман написал, как сделать области нажатия в мобильных интерфейсах удобнее. 41 лайк

19–20. Полина Старцева и Анастасия Белокобыльская написали о тёмных паттернах. 41 лайк

Указанное количество лайков = очевидно позитивные эмоции минус очевидно негативные.

А вот 20 самых популярных постов, если считать по лайкам и репостам в ВК.

6 статей попали и в вкшный и в телеграмный топ:
— Heads and Hands о законах UX;
— Никита Семёнов о презентации дизайн-решений и чеклисте для проверки дизайна интерфейса;
— Маргарита Романова о повышении интерактивности прототипов в Фигме;
— Евгений Бондковски об оформлении содержимого таблиц;
— Виталий Фридман об областях нажатия в мобильных интерфейсах.

Никита Семёнов — единственный, у которого по две статьи в каждом топе.

Никита Черемисинов и Федор Раклов написали о методе генерации идей Playing the Future.

— Метод наиболее эффективен, если встроен в процесс дизайн-мышления и следует после эмпатии с фокусировкой, когда уже есть данные исследований;
— Команда должна быть кросс-функциональной, чтобы рассмотреть проблемы под разными углами. Например, разработчики помогут разобраться с техническими ограничениями;
— Перед генерацией идей надо изучить тренды (совсем далёкие вроде колонизации планет, наверное, стоит отбросить) и технологии в своей области. Например, пользовательские тренды: инклюзивность, управление жестами и голосом, персонализация, омниканальность;
— Важно раскрыть участникам всё, что известно о пользователях. Задача — не просто решить проблему (она может быть не озвучена прямым текстом), а сделать своего пользователя круче;
— Затем надо описать портреты пользователей и проблемы, с которыми они сталкиваются;
— Фреймворк How Might We: кто, проблема (безопасно передавать рабочие документы с телефона на ноутбук), чтобы что (не получить штраф за нарушение политики безопасности);
— Далее надо объединить проблему со случайно выбранным трендом и 5 минут побрейнштормить. Например, проблема — необходимость работать с телефоном в перчатках, тренд — управление жестами, идея — запускать функции движением телефона (потрясти, чтобы разблокировать или включить фонарик);
— Выбрать жизнеспособные идеи можно с помощью диаграммы Венна с 3 областями: ценность для пользователя, ценность для бизнеса, техническая реализуемость (по сути, табуретка Нормана).

Название статьи, конечно, претенциозное. #process

В Creative написали о проведении исследований с участием детей.

— Чем младше ребёнок, тем ему важнее, чтобы рядом был близкий взрослый. Но взрослые иногда вмешиваются с подсказками и наводящими вопросами;
— Обеспечьте их присутствие, но продумайте, где они будут находиться, чтобы не сковывать свободу ребёнка слишком близким контактом;
— Попросите не вмешиваться. Объясните, что вы оцениваете не ребёнка, а качество вашего продукта;
— Обстановка важна. Идеально, если ребёнок находится у себя дома;
— Обязательно обсудите с родителями, прежде чем дать ребёнку сладости;
— Наполните пространство интересными вещами: книжки-картинки для малышей, сказки и энциклопедии для детей постарше, всем интересны игрушки с блёстками, механизмами, вынимающимися деталями;
— Заложите время на их изучение;
— Не задавайте сразу много вопросов, посмотрите на реакцию. Если с первых вопросов ребёнок всё больше замыкается, лучше спросить, хочет ли он продолжать или вы встретитесь в другой раз;
— Золотая середина общения: на ты, уважительно, без сюсюкания и сложных слов. Адаптируйте язык под возраст;
— Ребёнку может быть сложно выразить свою мысль. Не подталкивайте, ждите, дайте возможность ответить самостоятельно;
— Поддержите и поблагодарите за разговор, но не формальными фразами. «Спасибо! Мы здорово провели вместе время, мне очень понравилось разговаривать с тобой».

#kids #research

Илья Бирман написал, что ответить заказчику, который спрашивает, за что он платит, если он всё придумал за дизайнера.

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

#client

Ксения Гаврилова написала о предпосылках создания дизайн-системы и выводах, которые сделала в процессе её создания.

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

#design_system

Дима Марков рассказал о поиске работы дизайнером в Германии.

— Через рефералов откликаться эффективнее. Найдите людей из компании, где хотите работать, и попросите вас зарефералить. Участники слак-сообщества berlinru составили таблицу со своими компаниями;
— Долгое молчание компании после отклика — нормально. С рефералом у вас появляется человек, у которого можно спросить о судьбе вашего отклика;
— Большие компании охотнее помогают с переездом, у них обычно хорошо налажен этот процесс;
— Можно найти шаблоны для отслеживания своих откликов и истории взаимодействия с компаниями: job application tracking spreadsheet;
— Резюме должно быть в PDF. Онлайн-резюме может быть дополнением;
— Резюме: без фото, с номером телефона и имейлом, местоположение — действительное, а не желаемое. Фраза «Visa sponsorship required» = «Я готов переехать, чтобы начать работать в компании»;
— Проблема портфолио в Фигме: пока всё загрузится, рекрутёр уже переключится на следующий отклик;
— Если есть время, макеты в портфолио можно перевести на английский, чтобы было понятно, что там происходит. Описание проекта переводите обязательно;
— Обычно если есть White Board challenge, Design exercise, то нет тестового задания. Посмотрите на Ютубе про эти челленджи. Задавайте как можно больше вопросов;
— Также на Ютубе можно подготовиться к Portfolio review и Problem solving. Но сначала решите вопрос с резюме, а уже потом готовьтесь к более поздним этапам;
— В Берлине для трудоустройства в 90% случаев нужен английский. Чтобы получить работу, надо не учить язык, а готовиться пройти на нём интервью: рассказать о себе, проектах, ответить на вопросы («Top questions asked on an interview»);
— Немецкий нужен в крупных корпорациях вроде BMW и Siemens и вне вашей компании, при решении бытовых вопросов;
— Средняя зарплата синьора 80 000 € до вычета налогов в год (исследование 2021 года), после налогов примерно 4500 € на руки в месяц.

#career

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

— Они помогают защитить решение. У конкурентов не всегда есть подходящие кейсы. Советы экспертов вроде Nielsen Norman Group основываются непонятно на чём (как эксперт к ним пришёл?);
— Найти информацию можно по довольно общим темам (исследование шрифтов с засечками и без, а не конкретного семейства), вопросам с одним неизвестным (расстояние между карточками в интернет-магазине), не касающихся трендов;
— Искать — в Гугл Академии на английском. Если полный текст недоступен, часто можно нагуглить PDF или вложения. Чтобы узнать всё, что надо, обычно достаточно картинки и абстракта (краткое описание статьи);
— Если хотите действительно разобраться в теме, придётся собрать максимум материалов и критически на них посмотреть. Область применения может отличаться (пагинацию и скролинг изучали на новостных ресурсах, а у вас магазин), респонденты в эксперименте могут отличаться от ваших пользователей;
— Они помогают сгенерировать новые гипотезы и просто узнать что-то новое (например, что участники встреч, включающие камеры, устают больше);
— Зайдите на сайт с рейтингом научных журналов, выберите тему (Human factors and ergonomics или Human-computer interaction), отсортируйте журналы по индексу Хирша (как часто они цитируются другими), открывайте те, что отмечены Q1 и Q2;
— Можно читать то же самое в виде новостей, но иногда в них не хватает деталей и выводы оказываются перевранными;
— Авторы статей внимательно относятся к исходным данным и почти всегда перечисляют ограничения текущего исследования (например, маленькая выборка или что не проверили какой-то аспект) и предлагают будущие исследования (какие корреляции можно было бы проверить).

Видео. #research

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

— На момент передачи макетов уже проделана огромная работа, и тем обиднее из-за перегруза задачами, ограниченных сроков или неопытности что-то упустить и затем потонуть в уточняющих вопросах разработчиков;
— Проверьте, все ли сценарии взаимодействия с объектами предусмотрели. Помните о 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