Проектирование без бюрократии. Система управления рекламными объявлениями

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

Постановка задачи

Была поставлена задача разработать сайт мобильного приложения и систему управления рекламными объявлениями в этом приложении. Собственно, кроме этой информации никакой другой и не было… но был менеджер проекта, с которым мы и приступили к работе. Сайт не представлял из себя ничего сложного, поэтому я опишу как я вел работу над интерфейсом системы управления.

Определение ролей

Начали мы с того, что определили роли пользователей, их оказалось четыре: Менеджер, Юридическое лицо, Физическое лицо, Автор. Также, для описания поведения админки, была введена роль Система.

Выявление сценариев

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

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

Важно описать все действия детально, что бы не оставалось белых пятен и не возникало вопросов на этапе прототипирования.

Для остальных ролей было проще описать функционал потому, что это были, по сути, просто урезанные версии Менеджера, и нужно было просто скопировать отдельные сценарии.

Поведение систмы также было описано в виде сценариев, это поможет нам не забыть важные детали во время общения с разработчиками.

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

Прототипирование

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

Для статистики я брал скриншоты из Google Analytics и просто вставлял их в прототип. Это существенно сокращает время потому, что не нужно изобретать велосипед если есть уже проверенные решения.

Всего у меня получилось 20 экранов в разных состояниях.

В заключение

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


Хочешь прокачаться? Записывайся на тренинг по дизайну цифровых продуктов DIGITAL PRODUCT JEDI. За 6-ть недель интенсивной практики ты научишься создавать цифровой продукт с нуля, или улучшать уже существующий. Подробности на http://ux-clan.org/training/

Show your support

Clapping shows how much you appreciated Alex Voloshyn’s story.