Отправляет email-рассылки с помощью сервиса Sendsay

Usability. Разработка интерфейсов

Рассылка закрыта

При закрытии подписчики были переданы в рассылку "БЛОГика: жизнь и заработок в Сети" на которую и рекомендуем вам подписаться.

Вы можете найти рассылки сходной тематики в Каталоге рассылок.

  Октябрь 2009   →
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
Автор
ASPa

Статистика

178 подписчиков
+2 за неделю
←   Все выпуски   →

Usability. Разработка интерфейсов Использование прототипа в процессе разработки ПО


Использование прототипа в процессе разработки ПО

При составлении прототипа следует обратить внимание, что потенциально он состоит из двух частей: графической части и спецификации.

В первое время работы я уделяла особое внимание графической части (особенно, когда стала активно использовать программы, позволяющие создавать динамические прототипы).

Я пребывала в заблуждении, что в любой ситуации динамики будет достаточно (а в некоторых даже избыточно). К некоторым страницам прототипов делала комментарии – к тому функционалу, который было не реализовать с помощью прототипирования, но который предполагался данным интерфейсом. К тому функционалу, который позволял сделать прототип (например, события, происходящие при нажатии на кнопку, ссылку, пункт меню), на мой взгляд, не было необходимости делать подробных комментариев – и так всё очевидно.

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

 При этом сам процесс прототипирования был итеративным:

  1.  На основе задач, решаемых данным продуктом, и списка требований составлялся прототип.
  2. Прототип «тестировался» заинтересованными сторонами (командой разработчиков, менеджером продукта). На этом этапе возникал детальный список дополнений к первоначальным требованиям, что позволяло перед началом разработки уточнить более детально каким именно будет итоговый продукт.
  3. Вносились изменения в прототип (иногда это мог быть абсолютно другой интерфейс, но более отвечающий поставленным задачам).
  4. Далее повторялся п.2   – и так до тех пор, пока заинтересованные стороны не были согласны с конечным видением продукта.

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

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

 Не так давно в моей практике произошла совершенно иная ситуация.

Была поставлена задача разработки интерфейсов не целого продукта “с нуля”, а новой страницы уже существующего, активно используемого заказчиком ПО. Объем работ предстоял небольшой. Был выбран динамический способ прототипирования. Функциональность, возложенная на данный интерфейс, была довольно запутанной и требования, которые были описаны в технической документации, так же не отличались понятностью. Времени на разработку прототипа было выделено достаточно, он как и все предыдущие прошел несколько этапов согласований и доработок. Как итог всех предварительных работ – прототип интерфейса, отвечавший техническим требованиям, функциональные возможности которого согласованы с заинтересованными лицами и не вызывали никаких сложностей в разработке по уверениям программиста.

Далее пошел этап реализации интерфейса. В процессе реализации я как обычно осуществляла контроль за тем, чтобы ПО соответствовало запланированному прототипу.

И тут началось самая захватывающая часть.

Раз в неделю программист говорил, что у него практически готов интерфейс, что остались совсем мелочи. Но в реальности то, что я видела, кардинальным образом отличалось от прототипа – я говорю не только о расположении полей, выравнивании текста, содержания текста. На мои замечания, ответ был один: «я думал, что это не важно. Я всё исправлю, это пока тестовый вариант. Мне казалось, что должно быть так, что эта кнопка делает это». Чем дальше шел процесс реализации, тем больше возникало новых несоответствий, вплоть до того, что я услышала фразу: «Этот функционал я технически реализовать не могу, поэтому сделал другой и, как мне кажется, правильным».

Всё это происходило с учетом того, что прототип мы обсуждали не один раз, проговаривали каждую кнопку, ссылку, картинку – всё, что было отражено на прототипе. Те вещи, которые казались мне очевидными и вследствие этого не были никак описаны в спецификации, корректировались программистом по ходу его работы.

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

Итогом был интерфейс, за который стыдно.

Основные причины сложившейся ситуации и выводы, которые были сделаны можно найти в статье  "Использование прототипа в процессе разработки ПО".

Цикл статей и подборки по данной теме ведутся на сайте blog.mobilelive.ru
В избранное