Александр Васин (Groza.design) опубликовал трек «Русский дизайн», записанный для альманаха «Лепота».

https://www.youtube.com/watch?v=jP6gTio9e1Y

Роман Бунин рассказал, как спроектировать хороший дашборд.

— Соберите требования у всех заинтересованных сторон. Надо понять: а) как работает подразделение, которому нужен дашборд, б) кто им будет пользоваться, в) ответы на какие вопросы они будут искать и какие бизнес-решения принимать, г) в каком контексте и с каких устройств будут это делать;
— Для ответа на каждый пользовательский вопрос предложите как минимум один элемент дашборда. Например: «Какова общая обстановка? → Фактоиды + мини-графики»; «Какова динамика количества сделок? → Бар-чарт по количеству сделок во времени»;
— Вёрстка дашборда — достаточно рутинное занятие, если требования собраны качественно. Основные приёмы: F-паттерн чтения и контраст;
— Десктопную и мобильную версию обычно верстают отдельно. Здесь пригодится понимание контекста. В энтерпрайзе мобильные дашборды — редкость (в основном из-за проблем с безопасностью данных);
— Для разных дашбордов подходят разные инструменты: разовые сложные визуализации удобно делать с помощью R или Python, операционные дашборды — в Tableau или Yandex DataLens, сложную операционку с высокими требованиями к скорости и дизайну — с помощью d3.js или самописных инструментов;
— Аналитик — не специалист по проектированию дашбордов, ему не хватает навыков дизайна и правильной компоновки данных. Если в компании с дашбордами будет работать больше 20 человек, возможно, стоит нанять специалиста по проектированию дашбордов;
— Чтобы дашборды работали быстрее, не стоит собирать визуализацию «всё в одном». Правильный подход к архитектуре — проваливаться из одного отчета в другой, а не путешествовать по разным уровням детализации внутри одного дашборда.

https://sense23.com/post/kak-sozdavat-poleznye-dlya-biznesa-dashbordy-algoritm-printsipy-verstki-instrumenty-arhitektura

Опубликованы видео с Avito Text Talk 2021:

1. Виолетта Шматкова, Авито — Как выстроить взаимодействие редактора и дизайнера в продукте

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

youtube.com/watch?v=qHdMCkW_jSA

2. Маргарита Хохлова, Профи — Зачем UX-редактору дружить с поддержкой

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

youtube.com/watch?v=lFI-agXA6zk

3. Кирилл Егерев, Детский мир — Ищите троих: почему один специалист не напишет всё быстро и хорошо

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

youtube.com/watch?v=u1jeVicikM4

Кейт Каплан из Nielsen Norman Group написала о пустых состояниях в сложных продуктах.

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

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

https://ux.pub/3-rekomendatsii-po-proektirovaniyu-pustyh-sostoyaniy-v-slozhnyh-prilozheniyah/

Опубликованы видео с Mail Design Conf & Dribbble Meetup 2021:

1. Олег Турбаба (Clay), Светлана Мовчан (GeexArts), Крис Анфалова — О пользе Dribbble для дизайнеров
youtube.com/watch?v=5wnWB9zhehI

2. Signal by ONY — Бренд в эпоху уникальности
youtube.com/watch?v=lM0Hb05ZKJg

3. Музей как место встречи: доступность и инклюзивные проекты Третьяковской галереи и Музея Гараж
youtube.com/watch?v=3duS5qOK11A

4. AIC — Три дизайнера на границе эстетики и функции
youtube.com/watch?v=8mrfesNAKXI

5. Создание умной колонки Капсула Мини
youtube.com/watch?v=7XVM8hSiZ54

6. Яндекс Дзен — Дизайн себя: функция и эстетика во внешнем виде дизайнера
youtube.com/watch?v=mO_f1cOASXU

7. Лев Маврин — Советская дизайн-утопия
youtube.com/watch?v=neimjcqL4No

8. Команда Ситимобил и Ситидрайв
youtube.com/watch?v=P_Htl880yVk

9. Ультимативный гид по фестивалям от REDKEDS и RedCollar
youtube.com/watch?v=yTMVVUOPq5s

10. MaxBionic — О самых красивых протезах. Как менять жизни не просто предметом дизайна
youtube.com/watch?v=1ruqa2CR_L0

11. Даня Трабун — Как полюбить себя и причём тут 3D-обувь
youtube.com/watch?v=d-CkaOynEAE

12. Моноспекталь Сергея Гурова и Станислава Белозерова
youtube.com/watch?v=EJHBfiPKIdY

— Все видео одном плейлисте: youtube.com/playlist?list=PLzqQCeTtpSBpBdqU8095DtoD0YNfofjiv
— Альбом в ВК: vk.com/video/playlist/-50773057_49

Markswebb поделились инсайтами, как улучшить чекаут. Некоторые из них:

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

https://vc.ru/trade/309952

Викалп Кошик написал о тултипах.

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

https://deadsign.ru/ui/how-to-design-and-style-better-tooltips/

Саша Окунев рассказал об опыте слияния дизайн-систем в Озоне.

В часовом видео:
— Элементы, из которых состоит дизайн-система: UI-кит, фронт-либа и документация. Что будет, если один убрать;
— Над чем работают дизайнеры в Озоне (80+ продуктовых дизайнеров и ~15 команд) и какие у них требования к дизайн-системам;
— Как выглядит типичный пайплайн работы дизайнеров и фронтов на небольшом проекте, и почему в крупных компаниях он становится неэффективным;
— Стратегии слияния (поглощение, создание новой дизайн-системы) и их плюсы и минусы. Пример слияния иконок, первая попытка внедрения единой дизайн-системы для веб-проектов;
— Сложность слияния на равных и важность лидера дизайна;
— Ценность новой дизайн-системы для веб-проектов: источник правды в коде, токенизация, витрина компонентов;
— Процесс создания команды дизайн-системы из 8 человек, итоги полугода их работы.

Также Саша рекомендовал посмотреть сначала 20-минутную лекцию Александра Дьякова о дизайн-системе: что это, какие задачи решает, из чего состоит и как выглядит.

Антон Жиянов написал, что должно быть в сообщении о заказе от интернет-магазина.

— Напишите: «Приняли заказ №12345, стоимость 5623 ₽, доставим в пятницу 16 июля с 10 до 14»;
— Если ваши айти-системы умеют идентифицировать заказ по номеру телефона, номер заказа можно не писать. Но может возникнуть путаница, если у клиента несколько заказов одним днём;
— Добавьте телефон, чтобы человек не искал, как с вами связаться;
— Если есть ограничения по оплате, напишите: «Оплата только наличными, у курьера нет сдачи» или «Заказ оплачен, вот чек»;
— Такой формат подходит для письма и смс. В письмо можно добавить подробностей: список товаров, как изменить время или отменить заказ, особенности (курьер звонит за час, доставка до двери);
— Адрес доставки имеет смысл указывать, если у клиента их несколько. ФИО, телефон, электронную почту — если заказ для другого человека.

#email #ecommerce

Владимир Меркушев написал вводную статью об а/б-тестировании.

— Суть в том, чтобы разделить аудиторию на части, показать им разные версии чего-либо и понять (на основе количественных данных), какая версия лучше;
— Протестировать можно, например, как разные призывы к действию влияют на конверсию, а также более долгосрочные метрики вроде среднего чека или прибыли;
— Тест лучше проводить с контрольной выборкой: для проверки 2 вариантов аудиторию делят на 3 группы, и двум из них показывают один и тот же вариант. Если метрики у этих двух групп не будут отличаться, значит, внешние факторы на результат не повлияли, и данным можно доверять;
— Если вариантов больше двух, можно провести мультивариантное тестирование. Так удобно тестировать комбинации вариантов, например, 4 призыва к действию и 2 цвета кнопки (будет тест с 8 вариантами);
— Стоит тестировать не только первое целевое действие (например, количество нажатий на кнопку), но и дальнейшее поведение пользователя (например, показатель отказов на открывшейся странице или конверсию в покупку);
— Не смешивайте выборки параллельно идущих тестов, так как варианты из одного теста могут влиять на восприятие вариантов из других тестов. Например, не стоит на главной странице одновременно тестировать кнопки меню и текст призыва к действию;
— А/б-тестирование скорее всего не подойдёт для B2B, B2G, премиального сегмента и продукта на старте, когда у него мало трафика;
— Калькуляторы для расчёта показателя статистической значимости обычно интегрированы в системы настройки тестов.

#ab_testing

Опубликованы видео с Fintech Design Conf 2021:

1. Бренд- и дизайн-команда Райффайзенбанка — Что сделали за год

2. МТС Банк — Особенности дизайна виртуальной карты

3. Хайс — Подход к дизайну и выпуску продуктов

4. Ак Барс Банк — Внедрение автоматизированных рабочих мест собственной разработки

5. ВТБ — Консистентность пользовательского опыта при большом количестве распределённых команд

6. Klarna — Влияние членов команды на создание пользовательского опыта, плоская иерархия и инклюзивность разработки продукта

7. ONY и Бланк — Идея, брендинг и стиль

8. Тинькофф — Разработка нового интерфейса банкоматов

9. Дизайн-команда Росбанка — Эволюция команды и превращение в отдельную часть компании

Все видео одном плейлисте: YouTube · ВК.

Максим Козлов написал об организации UX-исследований. О пользе вовлечения команды:

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

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

#research

Настя Овсянникова написала серию статей об отображении ошибок в интерфейсе.

— С точки зрения взаимодействия между пользователем, клиентом и сервером можно выделить виды ошибок: а) Сбой клиента; б) Результат валидации данных на клиенте и сервере; б) Результат обработки данных и команд; в) Потеря связи с сервером;
— Потеря связи с сервером происходит, если пропал интернет, проблемы с VPN, сервер упал или от него вообще нет ответа;
— Обстоятельства, при которых обнаруживаются ошибки: а) Приём данных от пользователя; б) Скачивание или подгрузка данных по его инициативе; в) Перенаправление на другую страницу; г) Перенаправление в модальное окно;
— Единые решения по отображению 4 видов ошибок при 4 видах обстоятельств позволяют: а) Команде говорить на одном языке; б) Не создавать макеты ошибок для каждой ситуации и сохранять консистентность; в) Упростить подключение новых членов команды;
— При сбое клиента решили перенаправлять пользователя на особенную страницу в виде Configuration Item, которая существует вне информационной архитектуры и всегда может быть отображена клиентом, но на ней нельзя показать разные варианты текста ошибки в зависимости от контекста;
— Ошибка валидации данных может быть связана с отдельным полем или группой полей. Во втором случае сообщение должно быть визуально связано со всей группой (например, отображаться над ней);
— Если нет связи с сервером, на странице решили показывать баннер-растяжку сверху, а в модальном окне — алерт под его заголовком;
— Если есть фоновая проверка связи с сервером, и пользователь просматривает модальное окно, сообщение о потере связи лучше показывать после того, как он на что-нибудь нажмёт или закроет окно;
— Если ошибка произошла после перенаправления пользователя на страницу, решили отображать полноэкранную ошибку с соответствующим текстом. После перенаправления в модальное окно — алерт под его заголовком;
— На странице Configuration Item не стоит размещать кнопки и ссылки и советовать перезагрузить страницу (это ни к чему не приведёт). Стоит подсказать, куда обратиться и что сообщить сотрудникам техподдержки;
— Если суть сообщения об ошибке одна, а сущности разные, можно использовать общие грамматические конструкции. Например, когда сущность уже есть там, куда её добавляем, можно использовать конструкцию «Такой(-ая) [сущность] уже входит в [сущность]»;
— То же самое, если меняются не сущности, а значения параметров. Например: «Загрузите 1 файл до 100МВ в формате .docx, .pdf или .xlsx». Меняется количество файлов, лимит мегабайтов и форматы;
— Для специфических полей (номер телефона, дата или сумма) можно зафиксировать отдельные ситуации. Например: «Дата окончания периода не может быть раньше даты начала»;
— Ошибка может отображаться по-разному (полноэкранная, алерт, нотификация) с разным контентом. Стоит предусмотреть текстовые токены, из которых можно собрать любое отображение ошибки. Например: заголовок, полный текст, краткий текст, основное действие, второстепенное действие.

Настины статьи:
— Как возникают ошибки;
— Выбор способа отображения ошибки в интерфейсе;
— Выбор контента для описания ошибки пользователю.

#error

В Canvs написали об офбординге.

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

Об отписке от Яндекс Плюса.

Илона Саркисова написала первую статью из серии о Customer journey map.

— В 1998 году в IDEO по заказу Amtrak пытались понять, как повысить привлекательность поездок по железным дорогам. Возможно, это первое использование термина;
— CJM рассматривает человека как клиента компании и показывает, как тот узнаёт о сервисе, решает им воспользоваться, пользуется, а затем остаётся лояльным (жизненный цикл взаимодействия). Изучение пользовательского интерфейса здесь отходит на второй план;
— Подходит для анализа существующего сервиса и планирования нового;
— Нет смысла строить CJM, если а) человек ничего не покупает и нет взаимодействия по оказанию услуги, б) вы хотите проиллюстрировать только работу пользователя с интерфейсом;
— При построении CJM сначала надо понять, какие у сервиса есть (или должны быть) клиенты и описать персоны. Если их несколько, будет несколько CJM;
— Далее надо выписать точки взаимодействия и проблемы в каждой точке. В CJM можно включать любые элементы, которые помогут в проектировании сервиса;
— Например, можно выделить моменты истины — взаимодействия, в ходе которых клиенты решают, воспользуются они сервисом или нет;
— Также можно зафиксировать поставщиков услуг (кто оказывает сервис и несёт ответственность), эмоции (что клиенты чувствуют в каждой из точек взаимодействия), возможности (как можно улучшить взаимодействие) и так далее;
— CJM помогает увидеть сервис с высоты птичьего полёта, найти способы улучшить обслуживание и придумать новые услуги. Это инструмент на грани продуктового Customer Experience и маркетинга.

#cjm

Денис Тамбовцев рассказал, как меняется роль дизайнера интерфейсов, если это интерфейс для VR/AR.

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

В «Собаке Павловой» написали, как собрать UX-портфолио, работая в команде над большими коммерческими проектами.

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

#career

Илона Саркисова написала, как применять Customer journey map для проектирования нового сервиса.

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

Заметка о трёх типах персон. #cjm

Владимир Бугай написал, как верстать таблички с режимом работы.

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

#layout

Игорь Штанг написал об алгоритме вёрстки.

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

Ещё пара примеров. #layout

Роман Горбачёв написал об иерархии погружения (с очень понятными примерами).

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

#layout