Создание пользовательских сценариев

⇐ ПредыдущаяСтр 2 из 3Следующая ⇒

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

Предположим, что необходимо разработать сценарии для будущей почтовой программы. Судя по всему для этой задачи необходимо три сценария:

А) запустить почтовую программу, скачать новую почты. Получив почту, прочитать все сообщения, затем часть их удалить, а на одно сообщение ответить. После чего выключить почтовую программу.

Б) Сделать активным окно уже открытой почтовой программы и включить процесс скачивания новой почты. Получив почту, прочитать ее. Одно сообщение переслать другому адресату, после чего удалить его, а еще одно печатать. После чего переключиться на другую задачу.

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

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

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

Проектирование общей структуры

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

Рис. 1. Типичная структура сайта (слева) и типичная структура программы. Если сайты обычно разветвлены, в том смысле, что функции обычно размещаются в отдельных экранах, то программы обычно имеют только один изменяющийся экран, в котором и вызываются почти все функции.

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

Выделение независимых блоков

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

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

⇐ Предыдущая 123 Следующая ⇒