Проектирование пользовательских интерфейсов. Краткий обзор процесса

Ключевая деятельность моего отдела в компании Artics — проектирование пользовательских интерфейсов. В основном это веб-технологии — веб-приложения, порталы, интранет-сайты, веб2.0-сервисы и т.п. Сам по себе процесс проектирования достаточно обширный — и по количеству этапов, и по тем факторам, что учитываются в его ходе, и по используемым инструментам. Многое из этого я описывал в своем блоге. А для IdeaBlog составил обзор всего процесса и его особенностей.

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

1. Для кого и для чего эта система. Кто ее основная аудитория и какие задачи этой аудитории она решает? С какими целями создается продукт и какие задачи стоят перед ним? Что является важным для успеха продукта, а что — второстепенным?
2. Что должно быть в системе и что она должна уметь. Какие возможности она дает пользователю и какие функции нужны для этого? Какие эксплуатационные, потребительские и другие качества важны для успешной работы системы?
3. Как выглядит и работает система. Как распределить функции системы по конкретным страницам и какова последовательность этих страниц? Как пользователь будет работать с этими функциями? Каковы технические особенности работы этих функций?

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

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

После этого можно уже достаточно точно оценить и спланировать работы. Часто оценку дают без предварительного анализа. А потом нервы и заказчика, и разработчика сжигаются быстрее чем калории на велотренажере. Если проект долгосрочный, запускать его стоит в несколько этапов. Это нужно предусмотреть и при проектировании интерфейса — будет ли целостным продукт, если работает только половина его возможностей?

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

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

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

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

Материал написан специально для блога о венчурных инвестициях и стартапах IdeaBlog.ru.