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