Дмитрий Ваницкий написал введение в веб-аналитику для дизайнеров.

— Веб-аналитики заняты анализом бизнес-моделей клиентов, разработкой стратегии измерения, её внедрением, настройкой и поддержкой. Это необходимо для принятия решений и точной оценки изменений в процессах. Настольная книга: «Веб-аналитика 2.0 на практике» Авинаша Кошика;
— Что, как и зачем измерять, остаётся загадкой. Появляются фреймворки вроде HEART, но начинают сбоить или не подходят бизнес-модели, и всё откатывается к стандартным настройкам;
— Часто дизайнеры меряют, чтобы измерить. Дальше констатации фактов дело не идёт;
— Метрики, доступные из коробки: посещения и посетители, время на сайте и на странице, отказы, выходы, коэффициент конверсии;
— Чтобы понимать суть значений любого показателя, нужно смотреть на них в динамике;
— Примитивные показатели приводят к выводам о работе всей системы. Если с новым релизом увеличилось время пребывания на странице, сложно сделать вывод о причинах. И это не повод откатывать релиз;
— Воронки помогают увидеть показатели по каждому перевалочному пункту пользователей;
— Аналитики обычно не доверяют тепловым картам. Они вешают триггеры на каждый интерактивный элемент, чтобы точно знать, куда пользователь нажал, без оглядки на ширину экрана, устройство и так далее;
— Воронки могут не работать: а) важно понимать, кто именно отваливается и что с ними в принципе происходит, б) это анализ количества кликов, а не намерений, в) анализ данных в статике — плохая затея;
— Коэффициент конверсии скажет неправду, если не учесть посещения, предшествовавшие целевому действию. Иногда люди не готовы купить товар сразу;
— Усреднённый показатель конверсии или отказов тоже ничего не скажет. Надо сегментировать аудиторию, например, по источникам трафика. Может оказаться, что высокий процент отказов возник из-за плохой рекламы, создающей неадекватные ожидания;
— Сегментация — основная стратегия анализа данных, если надо докопаться до сути;
— Важно чистить данные перед анализом, например, не принимать в расчёт сессии длиной в 0 секунд;
— KPI (key performance indicator) — любая метрика, отображающая успешность работы сервиса или его части. У разных продуктов они разные;
— При выборе KPI можно скатиться к «покупкам», но стоит поискать менее тривиальные варианты вроде: процент выполнения задачи, распределение трафика, лояльность и недавность, продолжительность и глубина посещения, альтернативные каналы потребления, процент важных выходов;
— В электронной коммерции это отказы от корзины или оплаты, время и посещения до целевого действия, объём заказа, основная цель пользователя;
— Есть основные цели, критичные для бизнеса (макроконверсии, например, покупка или подписка), и вспомогательные, направленные в основном на увеличение лояльности (микроконверсии, например, получение помощи или чтение статей).

Вячеслав Лазарев написал о правилах хорошего дизайна.

— Теория близости: любые объекты, расположенные рядом, воспринимаются связанно. При вёрстке текстовой страницы заголовок ставят к тексту, к которому он относится;
— Правило внутреннего и внешнего: внутреннее ≤ внешнее. Например, расстояние между словами должно быть меньше межстрочного расстояния или равно ему. Оно в свою очередь должно быть ≤ абзацного отступа, который должен быть ≤ полей вокруг блока с текстом;
— Правило якорных объектов: объекты, которые сразу бросаются в глаза читателю (иллюстрации, заголовки, пиктограммы), должны тяготеть к якорным точкам модуля, расположенным в его углах или центре;
— Закон Фиттса: чем больше расстояние от курсора до цели и чем меньше размер цели, тем сложнее в неё попасть. Поэтому кнопки делают больше, увеличивают область нажатия вокруг иконок и не ставят кнопки «Ок» и «Отмена» слишком близко друг к другу;
— Правило тинктур: нельзя накладывать эмаль на эмаль и металл на металл. Любопытное правило из геральдики о соблюдении контраста при сочетании цветов.

Энтони Ценг написал об адаптации таблиц под маленькие экраны.

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

In English. #adaptive #table

Гонсалу Диас написал об иллюзии свечения.

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

Егор Камелев поделился чеклистом и серией видео о проектировании регистрации.

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

Смотрите также статью Павла Шерера об идеальной схеме регистрации, логина и восстановления пароля. #sign_up

Я написал о функциональной спецификации интерфейса.

— Это один из артефактов, который полезно создавать при проектировании интерфейсов. Она уточняет показанные в прототипе решения и отвечает на будущие вопросы разработчиков;
— В ней можно описать то, что трудозатратно или невозможно визуализировать в прототипе, и то, что на картинках человек скорее всего не заметит;
— Также она: 1) может стать частью договора, 2) помогает перепроверить и доработать свои решения;
— Во второй половине статьи я рассказал, как её писать: когда приступать, что в неё включать и как это структурировать, что писать об отдельных элементах интерфейса и что уже выходит за рамки подобного документа;
— Это, конечно, не подробное руководство с детальными чеклистами, но неплохой материал для старта.

#docs

В Kode поделились итогами митапа о голосовых интерфейсах.

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

Виталий Фридман написал о форме подписки на рассылку во всплывающем окне на главной странице.

— Внедрение таких форм действительно повышает количество подписчиков, но не приводит к увеличению доходов. Это плохие, случайные подписчики;
— Даже такие подписчики стоят компании денег, так как всплывающие окна отталкивают часть посетителей;
— Окно появляется не вовремя и прерывает выполнение текущей задачи пользователя;
— Такие сообщения надо отображать вовремя: на страницах с пустыми состояниями и ошибками, на продуктовых страницах и в публикациях в блоге;
— На страницах, где пользователь завершает текущую задачу или достигает определённой вехи;
— Где оказывается после отправки письма для подтверждения адреса электронной почты. Здесь можно предложить указать больше информации о себе или установить пароль в обмен на скидку;
— Рядом с ценой товара, побуждая подписаться и получить скидку на первую покупку;
— Также всплывающие окна можно сделать немодальными и сворачиваемыми, чтобы к ним можно было вернуться позднее.

In English.

Александра Савельева написала о подтверждении пользовательского действия в модальном окне.

— Проблема в том, что пользователи подтверждают свои действия не задумываясь и, например, иногда удаляют не то, что хотели;
— Можно реализовать отмену действия в течение 10 секунд и отображать уведомление об этом. Так делает Gmail после отправки письма. Фактически, действие происходит на 10 секунд позднее, если пользователь не решает его отменить;
— Если разработчики не готовы так делать, можно доработать модальное окно: описать, что происходит (человек подтверждает выход именно из профиля Ozon), к чему приведёт подтверждение (перестанут отображаться персональные рекомендации). Окно станет чуть менее стандартным, повысится вероятность, что пользователь в него вчитается;
— К кнопке подтверждения можно добавить кнопку отказа от действия и сделать её акцентной. Кнопки с разрушительными действиями стоит делать красными;
— Для подтверждения самых разрушительных и редких действий (удаление проекта или профиля) можно попросить ввести в текстовое поле какую-нибудь фразу, например, название удаляемого проекта.

#modal

Игорь Штанг написал о современной русской пунктуации на примере упаковки умной розетки Яндекса.

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

#typography

Тимофей Контанистов (в фамилии опечаток нет) написал об использовании Яндекс Толоки для тестирования интерфейсов.

— Когда дизайнер несколько недель подряд работает над одним и тем же макетом, у него замыливается глаз;
— Иногда сложно выбрать один вариант дизайна, а проводить всё через AБ-тестирование — долго и дорого;
— Практически нет инструментов для анализа результатов Толоки, сортировать и оценивать ответы приходится вручную. Нужны навыки работы с таблицам;
— С другой стороны, нет ограничения по типу заданий. Пользователям можно предложить всё: от сравнения двух текстов до похода в магазин и проведения контрольной закупки;
— Не подходит для тестов в узких сферах. У сервиса широкая целевая аудитория, на которой удобно проверять массовые продукты и сервисы;
— Можно сочетать с другими сервисами. UsabilityHub даёт классные возможности по аналитике, но аудитория там англоязычная, а тесты — дорогие. Можно создать тест в бесплатной версии UsabilityHub, а через Толоку привести туда пользователей;
— Четыре вида тестов на Толоке: 1) side-by-side, сравнение двух вариантов, 2) first click, 3) five second test, что пользователь успевает увидеть и понять за несколько секунд, 4) тест на понятность;
— Перед запуском на большую аудиторию проверяйте понятность вопросов на небольшой аудитории;
— Есть пользователи, которые не вникают в задания. Для борьбы с ними можно: 1) использовать ловушки для читеров, 2) добавлять вопросы, на которые нельзя ответить не подумав, 3) собирать базу проверенных респондентов, 4) увеличивать количество респондентов;
— Проведение тестов прокачивает дизайнера: развивает критическое мышление, учит задавать больше вопросов и не принимать первое решение как единственно верное.

#user_testing

Главное событие, где все ждут инноваций — презентации Apple. Но самая важная преза случилась еще до Apple, в 1968 году (ее так и назвали: «The Mother of All Demos»).

Там произошло то, что сделало интерфейс компьютера таким, какой он сейчас.

Дуглас Энгельбарт впервые показал всё наше родное добро: мышку, окна, ссылки, навигацию, работу с текстовым документом, механику copy/paste, drag&drop… Более того, он показал real-time коллаборацию аля Figma, и даже ВИДЕО-ЗВОНКИ (алло, 1968 год). Чувак на кучу лет опережал своё время.

На минуточку: первые домашние ПК появились только через 15 лет.

Благодаря Энгельбарту появилась идея того, что компьютер это не просто гигантский калькулятор. Он может быть инструментом для повседневных человеческих задач и хранения знаний. После «The Mother of All Demos» те концепции продолжили развивать Xerox, Apple и Microsoft.

Наверное, это самое важное демо в истории компьютеров. А Энгельбарт — одна из ключевых персон в HCI.

Поглядеть можно тут: полная версия, короткая версия.

В Sparkbox написали о мобильной навигации по большим контентным сайтам [English].

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

Так себе перевод со слетевшими картинками. #navigation

Александр Чудеснов написал, как сделать доступным продукт из множества приложений, которые написаны разными командами.

— Страница с правильной цветовой контрастностью, структурой заголовков и HTML-вёрсткой, скорее всего, уже отвечает критериям доступности;
— Есть нюансы: разная реализация некоторых функций в разных браузерах, отдельные неудобные элементы вроде нативного поля ввода даты;
— Проблема в том, что Single Page Applications выходят за рамки возможностей HTML. В них много компонентов, которые не предоставляет сам браузер. При их создании надо отвечать на множество вопросов о взаимодействии с помощью клавиатуры, разметке для скринридеров, управлении фокусом;
— Дизайн-система не всегда спасает: проработанный компонент из ДС может не подходить продукту и не использоваться;
— Относитесь к ДС как к продукту: собирайте статистику использования и обратную связь, отслеживайте и исправляйте проблемы;
— ДС должна решать проблемы команд, предоставлять компоненты с разумными дефолтами, которые можно менять в определённых рамках. Без инструкций в формате «собери сам»;
— Есть проблема в совмещении визуальных и интерактивных паттернов. Кроме визуального стиля компонента важно прорабатывать способы взаимодействия с ним и возможную композицию с другими элементами;
— ДС может содержать визуальный слой, слой интерактивных паттернов и отдельно — собранные готовые компоненты (как в ДС Adobe Spectrum);
— Не пренебрегайте автоматическим тестированием. Тестировать компоненты в разных состояниях проще в Storybook, чем в продакшене. После ручного аудита (в Lighthouse или axe DevTools) стоит написать автоматизированные тесты (axe-Selenium);
— Важно, чтобы доступность интерфейсов стала частью культуры компании: помогите сформировать запрос на доступность, зовите на тестирование людей с инвалидностью, дайте сотрудникам возможность научиться создавать доступные продукты, установить цели, связанные в том числе и с процессами («80% команд знают и используют принципы обеспечения доступности»).

#accessibility

Майкл Виллар написал о скролбарах.

— Их стиль и поведение отличается для разных операционных систем, браузеров и устройств прокрутки: мыши с колёсиком, Magic Mouse, трекпада. Например, скролбар в macOS может ездить по отдельной видимой дорожке (мышь с колёсиком) или просто поверх контента (трекпад и Magic Mouse);
— Для второго случая следует предусматривать дополнительный отступ справа, чтобы скролбар не закрывал контент;
— Кастомные скролбары помогают сохранять консистентность продукта на разных платформах и не перегружать интерфейс видимыми дорожками;
— Скрытые скролбары, которые отображаются после начала прокрутки, затрудняют обнаружение скрытого контента. Также сложно нажать на сам скролбар — он быстро исчезает после окончания прокрутки;
— В Height скролбар отображается при наведении курсора на блок с прокруткой;
— Кастомные скролбары дают полный контроль над тем, когда их отображать. Например, на канбан-досках имеет смысл показывать скролбары всегда, чтобы можно было быстро оценить количество задач в каждом столбце;
— VSCode на видимой дорожке отображает места, где на странице находятся результаты поиска.

In English. #scrollbar

Кэтрин Тотц написала об отображении цен и скидок на странице товара.

— Цена — одна из самых важных характеристик товара, влияющая на решение о покупке;
— Цена не должна теряться на фоне других элементов страницы. Очевидный совет, но посмотрите в статье примеры сайтов, на которых цены найти весьма непросто (Adidas, Patagonia);
— Стоит учесть, что пользователи просматривают каталог и страницы товаров быстро, а цена (в долларах особенно) может быть довольно коротким текстом;
— Если пользователь не увидит цены, он может посчитать, что магазин намеренно скрывает важную информацию. Появится недоверие;
— Хороший вариант отображения скидки: новая цена и зачёркнутая старая;
— Отображайте скидки, описания спецпредложений и иконки с метафорами скидки рядом с ценой. Пользователи могут не понять, что предложения и скидки относятся к товару, который они изучают, или даже полностью их проигнорировать;
— Неудобно, когда безусловная скидка на товар отображается только в корзине;
— Не стоит писать об одном и том же спецпредложении несколько раз. Люди начинают путаться в том, что же они получат в итоге;
— Если о спецпредложении надо рассказать на странице несколько раз, его описания должны быть одинаковыми (или почти), чтобы пользователь понял, что это одно и то же;
— Стоит отображать размер скидки: в абсолютном выражении и в процентном. Если места хватает только для одного варианта, выбирайте тот, где цифры получаются больше. Если скидка 20→15 долларов, то лучше написать, что скидка 25%. Если 1000→900, то лучше скидка $100.

In English. #price #ecommerce

Станислав Хрусталёв написал о лучших практиках работы с корзиной.

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

#cart #ecommerce

Роман Местер написал о коридорном тесте.

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

#user_testing

Павел Шерер описал идеальную схему регистрации (через электронную почту и соцсети), логина и восстановления пароля.

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

«Кто из нас не сталкивался с тем, что тупит перед формой входа, не помня, как именно он регался на этом сервисе: через почту или какую-то из соцсетей? И таких примеров тьма. Но самое грустное в том, что мы сами считаем это нормой, и чаще всего виним себя и свою забывчивость, тогда как чаще всего виноват в этом именно сервис».

#sign_up #log_in

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

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

#interview

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

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

#design_system