Передача в макет

Что это такое

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

Почему это важно

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

Ключевые идеи

Один контракт страницы на каждый тип страницы

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

Страница-коллекция (например, «Ваши заказы»)
1. Заголовок страницы, совпадающий с меткой навигации
2. Поиск или фильтр, если коллекция может превысить 20 позиций
3. Список позиций, каждая ссылается на страницу детали
4. Пустое состояние: что здесь появится и как получить первую позицию
5. Вторичная ссылка на родительскую категорию

Задавайте состояния, а не только счастливый путь

Для каждой коллекции: пусто, одна позиция, много позиций, ошибка, загрузка; для каждой детали: полная, частичная, удалённая. Именно эти случаи формируют макет, и именно их никто не рисует случайно.

Состояния: пусто -> 1 позиция -> 20 позиций -> 400 позиций (постранично, не прокрутка)
           загрузка -> ошибка (предложена повторная попытка) -> доступ запрещён

Проводите метки через всё без изменений

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

Скажите, что куда ссылается, включая путь назад

Каждой странице нужен путь вверх и путь вбок, а деталь, открытая из поиска, не должна заставлять пользователя пробираться через иерархию, чтобы её покинуть.

Держите это в одном артефакте

Единый документ, по одному контракту страницы на каждый тип, с приложенной диаграммой-деревом: разделённая между схемой и несколькими письмами структура проигрывает тому, кто построит первым.

Практика

Напишите контракты страниц для одного раздела

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

Готово, когда: инженер может описать страницы, не спрашивая, какой контент куда идёт, и у каждого состояния в списке есть описанный макет.

Сверьте заголовки с метками

Выпишите каждый заголовок страницы и соответствующую ему метку навигации рядом.

Готово, когда: два столбца совпадают, или вы записали, почему они различаются.

Частые ошибки

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

Что читать дальше