Pull to refresh

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

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

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


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

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


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

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


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

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


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

Аудитория


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

Заказчик


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

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


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

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


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

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

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

Оригинал: Интерактивные прототипы. Действующая модель пользовательского интерфейса, часть 1. Классификация
Tags:
Hubs:
Total votes 50: ↑38 and ↓12 +26
Views 9.5K
Comments 44
Comments Comments 44

Posts