Процесс и продукт проектирования. Жизненный цикл интерфейса, часть 1. Четыре слоя проектирования

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

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

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

Недавно мы как раз закончили “нулевой” этап работ для одного рекрутингового веб-сервиса и выбрали второй вариант — несколько этапов. Первый из них — базовая информация об учетной записи. Второй — основная информация о пользователе в виде мастера (wizard) из нескольких шагов. Третий — дополнительная информация, которую оставлять необязательно, но она может здорово повысить шансы соискателя на успех. При этом на начальном этапе не так важно, сколько именно шагов включает в себя визард. Имеет значение общий подход к сбору информации от пользователя, его концепция. Ведь перегруппировать поля в формах визарда, сделав из трех шагов четыре — задача простейшая и ни на суть интерфейса, ни на архитектуру системы особого влияния не имеет. Поэтому и глубоко заниматься этим вопросом стоит именно в тот момент, когда он будет стоять острее всего — то есть при первой работе пользователей с ним в режиме юзабилити-тестирования.

Я разделяю четыре “слоя” проектирования. Не хочется терминологических споров, поэтому сразу оговорюсь что мои обозначения понятий могут привирать. Но выглядят они так:

Модель продукта, которая описывает концепцию системы. Как должен быть построен интерфейс, чтобы решать задачи именно так, как это наиболее привычно и удобно целевой аудитории? Как при этом акцентировать внимание пользователей на тех вещах, которые важны для соответствия продукта бизнес-задачам? Этот слой определяет, какие функции и процессы системы являются ключевыми. Те, на которые “нанизывается” все остальное.
Информационная архитектура, которая определяет структуру системы. Какова карта функциональности продукта, как выглядит дерево его возможностей? На какие страницы (экраны) нужно разбить всю функциональность и как эти страницы должны соотноситься друг с другом? Какая основная информация и элементы управления должны быть на каждой странице? Этот слой определяет архитектуру системы на общем и частном уровнях.
Эргономика “малых форм”, которая определяет качество исполнения конкретных элементов интерфейса. Какие способы подачи информации лучше всего подходят в каждой конкретной ситуации? Какие элементы управления наиболее удобны в каждом конкретном случае? Что лучше поставить — кнопку или ссылку? Нужны ли разные цвета для разных типов ссылок? Этот слой определяет внешний вид конкретных элементов и страниц в целом.
Проектирование взаимодействия, которое определяет реакцию системы на действия пользователя. Нужно ли информировать пользователя о том, что система реагирует на его запросы? Нужны ли разные способы реакции и как выбрать оптимальные? Должен ли всплывающий слой появляться с красивым эффектом или просто без задержек показываться пользователю? Этот слой определяет сценарии выполнения пользователем конкретных задач.

Каждый из этих слоев добавляет свою грань к общему experience работы пользователя с системой. И лучше накладывать эти слои последовательно, ведь только так можно продумать каждый из них достаточно основательно. Забегать далеко вперед особого смысла нет — предположения о следующем этапе достаточно размытые и общие. Гадать бессмысленно, поэтому лучше выбрать тот вариант, который видится наиболее оптимальным исходя из предыдущего опыта. Когда придет тот самый следующий этап, выбранное решение успеет провериться временем. И если покажется неоптимальным — его можно легко заменить, ведь на этапе проектирования такие изменения почти ничего не стоят. Хотя практика показывает, что процентах в 80 случаев ничего менять не приходится.

Все части материала: