Вайрфреймы и прототипы: быстрая проверка идей до кода

К этому месту трека у вас есть знание о задаче: что людям нужно (исследования), для кого и зачем (персоны и JTBD), из чего состоит продукт (информационная архитектура) и как человек движется к цели (потоки). Интерфейса ещё нет. Момент, когда знание превращается в конкретные экраны, — самый дорогой в проектировании: принятые здесь решения закрепляются кодом, тестами, документацией и привычками пользователей. Главная мысль статьи: прототип — не «черновик макета» и не этап процесса, а эксперимент, у которого есть вопрос. Если вы не можете сказать, что именно узнаете, когда прототип будет готов, — вы не прототипируете, вы рисуете.

1. Экономика поздней ошибки

Стоимость изменения решения растёт ступенями, и каждая ступень — новый артефакт, который придётся переделывать вместе с решением.

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

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

2. Точность (fidelity) — четыре оси, а не одна шкала

Спор «lo-fi или hi-fi» почти всегда бесполезен: слово «точность» скрывает несколько независимых величин. Классическая работа Стефани Худ и Чарльза Хилла «What do Prototypes Prototype?» (Handbook of Human-Computer Interaction, Elsevier, 1997) предлагает различать, что именно моделирует прототип: роль вещи в жизни человека, внешний вид и ощущение или реализацию. Практически это удобно развернуть в четыре шкалы, которые поднимаются по отдельности.

Прикладной смысл: поднимайте только ту ось, по которой задан вопрос. Понятна ли структура экрана — нужна реалистичность контента (настоящие названия и длины) при низкой визуальной детализации. Находят ли действие — нужны иерархия и один клик интерактива. Не раздражает ли анимация — нужен только интерактив, и лучше сразу в коде. Влезает ли таблица в 13 дюймов — нужны охват и реальные данные. Типичная же дорогая ошибка — «сделаем сразу hi-fi, всё равно потом понадобится». Следствий три. Смещается обратная связь: на красивом макете обсуждают цвет кнопки, на сером — порядок шагов; чем «готовее» выглядит артефакт, тем меньше собеседник считает себя вправе трогать основу (поэтому бумажные скетчи до сих пор работают — NN/g о бумажном прототипировании). Растёт привязанность автора: три дня работы делают отказ эмоционально дорогим. Съедается бюджет итераций: одна попытка вместо четырёх, а хорошее решение почти никогда не первое.

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

3. Цикл: вопрос → артефакт → проверка → решение

Вся дисциплина — в первом узле. Шаблон формулировки: «мы считаем, что [кто] в ситуации [когда] сможет [что сделать], если мы [что изменим]; мы поймём, что ошиблись, если [наблюдаемый признак]». Плохо: «проверим, удобен ли новый экран» — «удобно» не наблюдаемо, из результата не следует ни одного решения. Хорошо: «бухгалтер, получивший письмо о расхождении, найдёт кнопку “Сверить” на карточке счёта за 15 секунд без подсказки; ошиблись, если больше двух из пяти сначала пойдут в “Отчёты”». Здесь есть признак, порог и следствие: если ошиблись — менять не подпись кнопки, а место входа в сценарий.

Про пятерых участников: правило Нильсена (why you only need to test with 5 users) верно для качественного поиска проблем в одном сценарии, а не для измерения чисел — подробности в статье про юзабилити-тестирование.

4. Вайрфрейм как аргумент, а не картинка

Вайрфрейм — схема экрана без оформления: блоки, их размер, порядок, приоритет и подписи. Ценность в том, что он заставляет принять решения о содержании и иерархии раньше решений о стиле и не даёт спрятать слабую структуру за красивой подачей.

Что отличает рабочий вайрфрейм от «серых прямоугольников»:

• Реальный контент вместо lorem ipsum. Латинская рыба одинаковой длины прячет ровно те проблемы, ради которых артефакт делается: заголовок товара на 120 символов, клиент без отчества, отрицательная сумма, статус «Ожидает подтверждения контрагента», не влезающий в бейдж. Возьмите пять настоящих записей из базы — включая самую длинную и самую пустую.
• Иерархия объясняется задачей. На каждый блок — ответ на вопрос «зачем человек смотрит сюда в этот момент». Нет ответа — блок убирается или уезжает вниз. Это единственный способ спорить о композиции без «мне кажется».
• Одно главное действие. Три кнопки одинакового веса означают, что никто не решил, зачем нужен экран.
• Настоящие подписи. «Кнопка» и «Заголовок» — отложенное решение, которое примет разработчик в 11 вечера; формулировки — часть проектирования (текст в интерфейсе).
• Аннотации обязательны. Рядом с блоком написано: что при клике, что при пустом значении, что при ошибке, что при 500 элементах, куда уходит фокус.

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

5. Разбор: почему эта форма неудобна

Типичная форма оформления заказа, собранная без проектирования:

<!-- Было: форма, которую больно заполнять -->
<form>
  <div class="row"><input placeholder="Имя"><input placeholder="Фамилия"></div>
  <select><option>Выберите страну</option><!-- 195 вариантов по алфавиту --></select>
  <input placeholder="Номер карты (без пробелов)">
  <div class="row"><select><!-- месяц --></select><select><!-- год --></select><input placeholder="CVV"></div>
  <input type="checkbox"> Я согласен со всем
  <button>Отправить</button>
</form>

Каждый дефект — с причиной и починкой:

1. Placeholder вместо подписи. Как только человек начинает вводить, подпись исчезает: проверить, что куда введено, невозможно, а при ошибке валидации непонятно, о каком поле речь. Плюс низкий контраст и непредсказуемое озвучивание скринридерами. Починка: видимый <label>, связанный с полем; placeholder — только пример формата.
2. Два поля в строке. При заполнении глаз движется вертикально; колонки заставляют каждый раз решать, куда двигаться, и повышают шанс пропустить поле. Люк Вроблевски разобрал это в «Web Form Design» (Rosenfeld Media, 2008): одна колонка почти всегда быстрее. Починка: один столбец; исключение — короткие связанные пары вроде «город + индекс».
3. Список из 195 стран. Стоимость выбора растёт с числом вариантов — это закон Хика, но честно: он описывает выбор из равновероятных незнакомых альтернатив, и его регулярно натягивают на ситуации, где он не работает (лозунг «сократим меню до пяти пунктов» из него не следует). Починка: подставить страну из данных аккаунта, поднять частые наверх, дать поиск по вводу.
4. «Номер карты без пробелов» и месяц с годом отдельными селектами. Работа, которую тривиально делает машина, переложена на человека: группы по четыре цифры — единственный формат, в котором люди читают карту, а на самой карте написано 09/28, а не два списка. Починка: принимать любой ввод и форматировать по мере набора, одно поле ММ/ГГ с маской.
5. Чекбокс «Я согласен со всем». Юридически слаб, непрозрачен и тормозит на последнем шаге. Починка: явный короткий текст со ссылками.
6. Валидация только по кнопке. Заполнил восемь полей, нажал — получил пять красных сообщений разом, вдали от места ввода. Починка: проверка на blur для дорогих полей, сообщение рядом с полем, фокус на первое проблемное поле после отправки.
7. Кнопка «Отправить». Не говорит, что произойдёт: спишут ли деньги прямо сейчас? Починка: «Оплатить 4 900 ₽» — действие плюс результат.

<!-- Стало: каждое решение объясняется задачей, а не вкусом -->
<label for="card">Номер карты</label>
<!-- пробелы расставляет интерфейс, а не человек -->
<input id="card" name="card" inputmode="numeric" autocomplete="cc-number" aria-describedby="card-hint">
<p id="card-hint">Принимаем Visa, Mastercard, МИР</p>
<label for="exp">Срок действия</label>
<input id="exp" name="exp" inputmode="numeric" autocomplete="cc-exp" placeholder="ММ/ГГ">
<button type="submit">Оплатить 4 900 ₽</button>

Три вывода. Ни одно исправление не про «красиво» — каждое снимает работу с человека. Половина исправлений — атрибуты, то есть решения, которые невозможно принять в макете без разговора с разработкой: autocomplete, inputmode, порядок табуляции. И форма — место, где UX, фронтенд и доступность пересекаются плотнее всего: техника валидации разобрана в формах и валидации, доступность форм — в отдельной статье трека accessibility, а отраслевые измерения по чекаутам десятилетиями ведёт Baymard Institute (baymard.com/checkout-usability).

6. Разбор: почему пользователь не нашёл кнопку

Классика теста: участник десять секунд елозит взглядом по экрану и спрашивает «а тут вообще можно это сделать?» — при том, что кнопка на экране. Причин конечное число, и каждая чинится по-своему.

1. Она вне зоны сканирования. Люди не читают экран, а сканируют его в поисках зацепок: на текстовых страницах типична F-образная траектория (исследование NN/g), в приложениях — движение по якорям (заголовок, первая строка данных, привычное место действий). Кнопка внизу справа за сгибом длинного экрана не попадает никуда. Починка: поставить действие туда, где взгляд уже находится в момент возникновения намерения, — рядом с объектом, к которому оно применяется.
2. Не выглядит кликабельной. Плоский текст без границы, серый на сером, иконка без подписи (без подписи уверенно опознаются единицы иконок — лупа, корзина, дом). Починка: подпись у иконки, форма, отличающая элемент от текста, :hover и :focus.
3. Баннерная слепота. Элемент выглядит как реклама — яркий, в рамочке, с картинкой, справа сверху — и отфильтровывается до осознания (NN/g). Обиднее всего, когда команда «усиливает» кнопку, делая её ярче и рекламнее, и её начинают видеть хуже. Починка: встраивать действие в поток контента.
4. Ложное дно. Экран визуально заканчивается там, где есть продолжение: широкая пустая полоса, линия во всю ширину, крупный разделитель — и человек не скроллит, будучи уверен, что всё увидел. Починка: подрезать следующий блок, чтобы он выглядывал; убрать «завершающие» линии в середине страницы; проверять на реальной высоте окна, а не в макете во весь монитор.
5. Конкуренция действий. Пять одинаково выделенных кнопок — ноль выделенных: человек не находит нужную не потому, что она невидима, а потому что не может выбрать. Починка: один primary на экран, остальное — вторичный и текстовый стиль.
6. Подпись не про задачу. Кнопка называется «Синхронизация реестра», человек ищет «Обновить данные». Внутренний язык — самая частая причина «не нашёл», и она не лечится увеличением кегля. Починка: брать слова из интервью (исследования), следить за именованием (ИА).

Как отличить одну причину от другой, не гадая. Тест первого клика: статичный экран, задача, фиксируем первый клик — куда пошли люди, то и выглядит входом в сценарий. Тест на 5 секунд: показать экран на пять секунд, убрать, спросить, что это и что тут можно сделать; проверяет иерархию и заметность, а не удобство. Squint test: расфокусировать взгляд или размыть скриншот — если первым проступает не главное действие, иерархия неверна. Все три занимают минуты и не требуют интерактива — это и есть «быстрая проверка идей до кода» в самом буквальном смысле.

7. Состояния: прототип без пустого экрана — не прототип

Самый частый разрыв между макетом и продуктом: нарисован счастливый экран со списком из пяти строк, а в жизни экран бывает пустым, медленным, сломанным, переполненным и закрытым по правам. Всё это разработчику придётся придумать самому — и он придумает, но не то.

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

// Состояния экрана списка как размеченное объединение: у каждого варианта обязан быть свой кадр в прототипе
type ListState =
  | { kind: "loading" }
  | { kind: "empty-new" }                               // ещё ничего не создано
  | { kind: "empty-filtered"; activeFilters: string[] } // есть чем помочь: сбросить фильтр
  | { kind: "ready"; items: Order[]; total: number }
  | { kind: "error"; retry: () => void }                // ошибка обязана быть повторяемой
  | { kind: "forbidden"; contact: string };             // кому писать за доступом
// Нет кадра под ветку — её придумает разработчик. Обычно это будет пустой белый экран.

Правило для команды: у каждого экрана, который ходит в сеть, в прототипе минимум четыре кадра — загрузка, пусто, ошибка, данные; плюс «много данных», если список растёт. Разбор обратной связи, скелетонов и ошибок — в статье про взаимодействие и состояния.

8. Интерактивный прототип: что проверяет и о чём врёт

Кликабельный прототип даёт то, чего не даёт статика: человек сам принимает решения, и видно, где он ошибается.

Wizard of Oz стоит пояснить: интерфейс выглядит автоматическим, но работу за ним выполняет человек руками. Так проверяют идеи, где дорога именно реализация (классификация обращений, «умные» подсказки, распознавание документов) — вы узнаёте, нужна ли функция, до того как строить модель. О чём прототип систематически врёт — держите список перед тестом, иначе выводы будут ложными. О скорости: в прототипе всё мгновенно, в проде — запрос на 800 мс, поэтому задержки и состояния загрузки закладывают осознанно. О данных: три аккуратные строки против 4 000 записей с дублями и опечатками. О вводе: клик по кадру — не то же, что заполнение поля одной рукой в метро; всё про ввод проверяется в коде или хотя бы на устройстве. О памяти: участник теста впервые видит экран и сосредоточен, а реальный человек вернётся через две недели, забыв всё. О контексте: в тесте человек хочет помочь и терпит то, чего не терпел бы, имея альтернативу, — отсюда осторожность с выводами вида «людям понравилось».

Когда переходить в код: если вопрос про ощущение, реальные данные или производительность, прототип в редакторе бесполезен — собирайте черновую реализацию. Часто дешевле, чем кажется, если есть дизайн-система и готовые компоненты; техника — в треке frontend. Инструменты вторичны: бумага, Figma, Penpot, Storybook, ветка с фича-флагом — важно лишь, какая ось точности поднимается и какой ценой.

9. Доступность на этапе прототипа

Тема целиком раскрыта в треке accessibility и в статье доступность на этапе дизайна. Здесь — только то, что решается на вайрфрейме и потом дёшево уже не чинится.

• Порядок содержимого и структура заголовков. Логический порядок блоков — это и порядок чтения скринридером, и порядок табуляции; блок «слева, но читается вторым» превращается в конфликт визуального и логического порядка и исправляется перестановкой сейчас, а не CSS-трюками потом (клавиатура и фокус). Один h1 и вложенность без пропусков — тоже часть проектирования экрана (семантика).
• Размер целей. Минимум 24×24 CSS-пикселя по WCAG 2.2 (Target Size Minimum), комфортный для пальца — около 44×44; проверяется линейкой по макету.
• Не только цвет. Если статус различается лишь цветом бейджа, часть людей его не различит. На сером вайрфрейме это видно сразу: неразличимо — значит, вы полагаетесь на цвет (визуальная доступность).
• Куда уходит фокус после сохранения, закрытия модалки, удаления строки — решение уровня прототипа, место ему в аннотации.
• Место для текста. Интерфейс переживает увеличение шрифта на 200% и перевод длиннее оригинала на 30%: кнопка, куда подпись влезает впритык, — будущий баг. Ничего из этого не требует знания ARIA — только внимания на этапе, где переделка стоит десять минут.

10. Где закономерность, а где вкусовщина

Честность здесь — признак зрелости и главный способ прекратить бесконечные споры. Утверждения об интерфейсах бывают трёх сортов.

Измеримые закономерности — есть модель, воспроизводимые эксперименты и предсказание. Закон Фиттса: время попадания в цель растёт с расстоянием и падает с размером; отсюда крупные важные кнопки, края экрана как «бесконечно большие» цели, «Удалить» подальше от «Сохранить» (работа Пола Фиттса 1954 года, многократно воспроизведена, используется при проектировании операционных систем). Контраст текста: пороги измеряются численно, WCAG задаёт 4.5:1 для основного текста — это не вкус, а арифметика; то же про размеры целей. Стоимость поиска в длинных списках растёт с числом элементов без структуры и поиска.

Контекстные эффекты — наблюдались в исследованиях, но зависят от задачи и аудитории; годятся как гипотеза, не годятся как аргумент «потому что закон». F-паттерн — про беглое чтение текстовых страниц, на дашборде траектория другая. Закон Хика — про выбор из равновероятных незнакомых альтернатив, поиск знакомого пункта меню устроен иначе. «Семь плюс-минус два» — работа Миллера 1956 года про объём кратковременной памяти в экспериментах на запоминание, а не про число пунктов навигации; ссылка на неё в споре о меню почти всегда натяжка. Пороги 100 мс / 1 с / 10 с для отклика — хорошая ориентировка, но приемлемость задержки зависит от того, чего человек ждёт.

Вкус и стиль — правильного ответа нет, спор решается не аргументом, а дизайн-системой и последовательностью: радиус скруглений, глубина теней, «плоско или объёмно», количество воздуха, иллюстрации, шрифт из набора приличных, порядок «Отмена / Сохранить» (платформенная конвенция, а не истина).

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

11. Передача в разработку: как это выглядит нормально

Самое дорогое непонимание между дизайном и разработкой звучит так: «макет — это картинка, которую надо повторить». На самом деле макет — набор решений, часть которых выражена координатами, а часть не выражена вовсе. Задача передачи — донести решения, а не координаты.

Что входит в нормальную передачу. Не «файл с макетами», а комплект: экраны всех состояний (раздел 7); поведение при изменении размера — что тянется, что фиксировано, где ломается на 320 px и на 1920 px; финальные тексты, включая ошибки; отсылка к компонентам системы («это стандартный Button/primary, а не новая кнопка» — важнее знать, что элемент существующий, чем его отступы); токены вместо значений (color-surface-2, space-4, а не #F4F5F7 и 16px; почему так — см. дизайн-системы); поведение фокуса и клавиатуры; происхождение данных — откуда каждое поле, что если его нет, как форматируются числа и даты; и что менять можно, а что нельзя («расстояния — на усмотрение системы, порядок полей менять нельзя, он проверен на тесте»). Формат любой — комментарии в редакторе, страница в вики, YAML рядом с компонентом; важно, что это читаемый контракт, а не устная договорённость:

# Контракт компонента, который одинаково читают дизайн, фронтенд и QA
component: OrderStatusBadge
tokens: { radius: radius-pill, padding: space-1 space-2 }
states:
  # tone — семантический токен, а не хекс; цвет не единственный признак состояния
  - { value: awaiting_partner, label: "Ожидает контрагента", tone: warning }  # самая длинная подпись
  - { value: failed, label: "Не прошёл", tone: danger }                       # рядом нужен доступ к причине
behavior:
  truncation: "обрезка по ширине контейнера, полный текст в title и aria-label"
  min_target: "24x24 CSS px, если бейдж кликабельный; ниже 360 px переносится на вторую строку"
acceptance:
  - "все шесть значений видны без обрезки на 360 px; неизвестный статус рендерится как neutral с исходной строкой"

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

Почему «пиксель в пиксель» — плохая цель. Требование точного совпадения реализации с макетом выглядит как забота о качестве, а вредит:

1. Макет — снимок одного состояния в одном размере. Реальный интерфейс живёт в непрерывном диапазоне ширин, при разных системных шрифтах, с зумом, в тёмной теме, с длинными переводами. Совпасть во всём этом множестве нельзя даже теоретически.
2. Часть параметров принадлежит пользователю. Человек, поставивший шрифт 20 px, получит другую вёрстку — это правильное поведение, а не дефект.
3. Точное совпадение конфликтует с системой. Отступ 14 px в макете при шкале 12/16 — правильный ответ «взять системный», а не «добавить магическое число в код». Каждое «как в макете» разрушает систему по кусочку.
4. Внимание уходит не туда, а доверие ломается. Час ревью на два пикселя отступа — это час, не потраченный на то, что экран не работает при пустом списке; а дизайнер, заводящий баги на 1 px, перестаёт быть источником решений.

Что вместо: цель — соответствие решениям (иерархия сохранена, порядок не изменён, состояния реализованы, тексты те, компоненты системные, поведение при ресайзе описанное); допуски по договорённости («отступы и типографика — из шкалы системы; расхождение внутри шкалы не дефект»); ревью реализации, а не сравнение картинок — дизайнер открывает собранную ветку, проверяет на трёх ширинах, с клавиатуры и на длинных данных; визуальные регрессионные тесты вместо ручного сличения (E2E и UI-тесты); общий словарь — если дизайн и код называют одно и то же одинаково (space-4, Button/secondary), спор о пикселях просто не возникает.

Самый дешёвый способ улучшить передачу — позвать разработчика на этап скетча. Двадцать минут у доски снимают «этих данных у нас нет», «поиск будет только по префиксу», «этот список нельзя загрузить целиком»: дизайн, сделанный без знания ограничений системы, — это дизайн, который переделают. Продолжение — в статье про передачу и карьеру и в разборе требований в треке продакт-менеджмента. Ритм для функции среднего размера: понедельник — вопрос и 6–8 скетчей на бумаге плюс 20 минут с разработчиком про ограничения; вторник — вайрфрейм на реальных данных со всеми состояниями; среда — кликабельная сборка и прогон внутри команды; четверг — тест с пятью людьми; пятница — правки, спецификация, передача. Если цикл занимает месяц, где-то поднята лишняя ось точности.

12. Типичные ошибки

• Прототип без вопроса — делается «потому что положено», проверяется «нравится/не нравится». Рядом — hi-fi раньше времени: обратная связь смещается на цвета, структура остаётся непроверенной.
• Lorem ipsum и идеальные данные — прячут ровно те проблемы, ради которых артефакт создавался. Сюда же — только счастливый путь: ни пустого экрана, ни ошибки, ни длинного текста.
• Прототип показывают, а не дают — демонстрация с рассказом «а тут будет…» это презентация, а не тест: человек должен пытаться делать задачу сам. Сюда же — подсказки «попробуйте вот эту кнопку» и вывод по одному участнику.
• Прототип как вечный источник правды — после релиза правда в коде; устаревший файл с макетами хуже, чем его отсутствие.
• Спор о вкусовщине как о факте и «пиксель в пиксель» как критерий приёмки — уводят внимание от настоящих дефектов.

Мини-итог и чеклист

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

Перед передачей проверьте: сформулирован вопрос, на который прототип ответил; нарисованы все состояния, включая два вида «пусто»; данные реальные — самое длинное, самое пустое, самое странное значение; тексты финальные, включая ошибки; компоненты из системы, а новые обоснованы; значения переданы токенами; описано поведение на 320 px и на широком экране; указан порядок фокуса и цели не меньше 24×24; записано, что менять нельзя и почему.

Источники

• S. Houde, C. Hill. What do Prototypes Prototype? // Handbook of HCI, Elsevier, 1997 — разделение прототипов по тому, что они моделируют.
• L. Wroblewski. Web Form Design — rosenfeldmedia.com/books/web-form-design.
• S. Krug. Don’t Make Me Think, Rocket Surgery Made Easy — sensible.com: простые тесты своими силами.
• Nielsen Norman Group: эвристики юзабилити, про пятерых участников, F-паттерн, баннерная слепота, бумажное прототипирование.
• Baymard Institute. Checkout usability — baymard.com/checkout-usability; W3C. Understanding WCAG 2.2: Target Size (Minimum).
• Laws of UX — словарь «законов», читать с оговорками из раздела 10; Refactoring UI — переход от структуры к визуальному решению.

Что дальше

Структура проверена, сценарий проходится, состояния описаны. Теперь серые прямоугольники нужно превратить в интерфейс, который читается: расставить иерархию типографикой, цветом и пространством — так, чтобы решения объяснялись задачей, а не насмотренностью.

Основы визуального дизайна: сетка, типографика, цвет, иерархия