Проектирование интерфейса через связь с заказчиком

 

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

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

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

3. Как выглядит и работает система. Как распределить функции системы по конкретным страницам и какова последовательность этих страниц? Как пользователь будет работать с этими функциями? Каковы технические особенности работы этих функций?

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

Термины, которые потребуются дальше.

Пользовательские истории (User Story)— способ описания требований к разрабатываемой системе, сформулированных как одно или более предложений на повседневном или деловом языке пользователя. Пользовательские истории используются гибкими методологиями разработки программного обеспечения для спецификации требований. Каждая пользовательская история ограничена в размере и сложности. Часто история пишется на маленькой бумажной карточке, что гарантирует её малый размер. Разработчик может использовать серию вопросов, чтобы подтолкнуть клиента и выяснить необходимость некоторых специфических функциональных возможностей. Пользовательская история остается неофициальным определением требований.

Ограничения

· Без приемочных испытаний, являются открытыми для различных интерпретаций

· Они требуют постоянного контакта с клиентом на протяжении всего проекта

· Они могут плохо масштабироваться

· Они полагаются на компетентность разработчиков

· Они используются для начала дискуссии.

Текст самой истории должен объяснять роль/действия пользователя в системе, его потребность и выгоду, которую пользователь получит после того как история случится. К примеру: Как, <роль/персона юзера>, я <что-то хочу получить>, <с такой-то целью>.

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

Хорошая UserStoryдолжна соответствовать модели «INVEST»:

Independent. Reduced dependencies = easier to plan (Независимость. Снижениезависимости = легчепланировать);

Negotiable. Details added via collaboration (Договорённость. Добавлены подробности через сотрудничество);

Valuable. Providesvaluetothecustomer (Ценность. Обеспечивает ценность для клиента);

Estimable. Toobigortoovague = notestimable (Полезность. Слишком большой или слишком расплывчатым = не полезный);

Small. Can be done in less than a week by the team (Размерность. Может быть сделана менее чем за неделю командой);

Testable. Goodacceptancecriteria (Тестируемость. Хорошие критерии приемлемости);

Примеры: «Как администратор сайта я хочу управлять рекламными объявлениями, чтобы удалять устаревшие или ошибочные объявления»; «Как рекламодатель, я хочу, чтобы у меня была возможность фильтровать объявления для поиска лучших предложений рынка».

Практические советы по написанию пользовательских историй:

· Лучше написать много историй поменьше, чем несколько громоздких.

· Каждая история в идеале должна быть написана избегая технического жаргона.

· Истории должны быть написаны так, чтобы их можно было протестировать.

· Тесты должны быть написаны до кода.

· Как можно дольше стоит избегать UI. История должна выполняться без привязки к конкретным элементам.

· История должна иметь концовку – т.е. приводить к конкретному результату.

· История должна вмещаться в итерацию.

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

 

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

Назначение

· Постановка задания дизайнеру. При отрисовке макетов страниц дизайнер должен не забыть все указанные в wireframes элементы и учитывать расставленные акценты.

· Постановка задания разработчикам. Команда разработки должна руководствоваться wireframes при создании функционального прототипа системы (уже работающая система, к которой еще не «прикручен» дизайн).

· Демонстрация инвесторам и потенциальным пользователям. Система может быть показана заинтересованным лицам уже через несколько недель после начала работ.

 

 

 

Этапы проектирования