Интерактивные прототипы. Действующая модель пользовательского интерфейса, часть 1. Классификация

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

Классификация прототипов

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

Структурные схемы страниц (wireframes) или бумажные прототипы

Сперва это наброски ключевых страниц системы на бумаге, затем — отрисованные в MS Visio детальные схемы практически всех страниц и AJAX-взаимодействий. Их часто называют бумажными прототипами, но слово “бумажные” чаще всего теряется. Тут и начинаются терминологические споры — люди называют одним и тем же словом разные вещи, бесполезно спорят и вводят клиентов в заблуждение. Да и если посмотреть, к примеру, на аналогии в том же строительстве — тем есть и макеты (те самые модели из картона), и проекты — архитектурный, строительный, градостроительный и т.п.. Поэтому я стараюсь говорить о них как о схемах страниц. Они дают первое наглядное представление о будущей системе, позволяют поставить задачи дизайнеру, верстальщику интерактивного прототипа, разработчикам.

Интерактивный или кликабельный прототип

Материал как раз о них. У нас это набор связанных между собой HTML-страниц, включающий имитацию AJAX-взаимодействий с помощью статичного JavaScript. Данных он обычно не сохраняет, но можно использовать те же cookies для имитации серверного взаимодействия. Есть и более простые варианты прототипирования — например, “оживление картинки” через Adobe Flash или просто макеты страниц с кликабельными зонами (imagemaps). Пользы от интерактивного прототипа много для всех участников процесса работы над системой, но об этом ниже.

Функциональный прототип

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

Сразу оговорюсь — я работаю над веб-системами, поэтому вся специфика и терминология в статье — как раз о них. Хотя в целом переносима и на другие среды.

Аудитория

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

Заказчик

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

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

Пользователи системы

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

• Продукт понятен пользователям и удобен в работе. На основе схем страниц или визуального дизайна можно проводить только достаточно ограниченное юзабилити-тестирование. А вот интерактивный прототип дает возможность увидеть, как пользователи выполняют в системе основные задачи, уже максимально приближенно к реальности. Особенно здорово то, что прототип можно быстро доработать и провести юзабилити-тестирование снова. А при наличии альтернативных вариантов — сделать модели всех из них и показывать пользователю по очереди. Конечно, все равно остаются оговорки — данные в прототипах сохраняются редко, нет особенностей взаимодействия с сервером и других рабочих моментов. Но чаще всего это касается нефункциональных требований — если костяк системы составляют независящие от пользователя функции, то и интерактивный прототип ей редко нужен. В любом случае, в итоге — проверены и доработаны основные сценарии работы пользователей с системой.
• Все необходимые функции реализованы и работают эффективно. Это скорее продолжение предыдущего пункта — но удобнее выделить его в отдельный. Разница в том, что проверяется эффективность выполнения не отдельных задач, а целых процессов. Все ли в продукте есть для того, чтобы каждая группа пользователей выполняла свои задачи полноценно и эффективно? Можно ли достичь состояния потока, когда работа с системой идет “на одном дыхании” — она явно или неявно предлагает и подсказывает следующий шаг? В итоге дается ответ на то, работает ли система как полноценный продукт и помогает ли достижению бизнес-целей.
• Систему можно обеспечить необходимым контентом, а ее функции — поддержкой. Успех веб-приложения или сервиса обычно строится на основе качественного контента или функциональности — в сумме или по отдельности. Важно знать, насколько возможна и затратна поддержка этих составляющих. Прототип показывает финальный результат работ, так что можно просчитать заранее, с какой периодичностью, в каких объемах, из каких источников, какими ресурсами, с какой доработкой брать информацию. Не забывая и про функции — на каких участках, кто, как и какими силами должен поддерживать успешную работу сервисов. Начиная от модерации user-generated content, заканчивая справочными службами и т.п. В итоге — проработка процесса поддержки системы и поиск путей облегчения работы в этом процессе.

Команда разработки

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

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

Осталось поставить у этого чеклиста галочки. И начать работу над самим прототипом.

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

1. Интерактивные прототипы. Действующая модель пользовательского интерфейса, часть 1. Классификация
2. Интерактивные прототипы. Действующая модель пользовательского интерфейса, часть 2. Подходы к процессу
3. Интерактивные прототипы. Действующая модель пользовательского интерфейса, часть 3. Особенности процесса