В завершение мы обсудим роль специалиста по инженерной психологии и рассмотрим роль этой ключевой фигуры в руководстве работой по созданию пользовательского интерфейса.
Прототип пользовательского интерфейса
Прототип — это наглядная модель пользовательского интерфейса. В сущности это функционирующий «черновик» интерфейса, созданный на основе ваших представлений о потребностях пользователей. Прототип может принимать множество различных форм, от бумажных макетов до реальных программ, имитирующих работу пользовательского интерфейса (способы создания прототипов мы обсудим ниже). Однако независимо от формы прототип должен давать команде чёткое представление о способе взаимодействия пользователя с программой.
Почему прототип необходим?
Как сказано в главе 8, требования к продукту определяют основные задачи, которые приходится выполнять пользователям. Однако в описании требований не сказано, как пользователи будут это делать. Ответ даёт прототип пользовательского интерфейса. Им занимается команда разработчиков программы и в большей степени — специалист по инженерной психологии. После создания прототипа появляется возможность привлечь пользователей для проверки деталей выбранного вами решения. Результаты тестирования позволяют убедиться, что пользовательские потребности были поняты правильно. Важнее всего при этом возможность легко вносить изменения и пробовать новые идеи, руководствуясь результатами тестов.
Прототип даёт команде разработчиков множество преимуществ.
• Возможность сосредоточиться на решении ключевых задач.
Необходимо сосредоточить усилия команды на самых важных частях продукта. Важнейшие части продукта — это ключевые задачи, наиболее ценные, нужные и важные для пользователя. Все участники команды (разработчики, тестировщики, технические писатели и др.) должны чётко представлять себе суть ключевых задач и не жалеть усилий для их правильного понимания. Отчасти верно, что остальная функциональность просто не имеет значения, если трудно решать основные задачи или не ясно, как это делать.
Из собственного опыта
Когда в NuMega решили создать TrueTime, новую программу-профайлер, было ясно, что интерфейс для неё придётся создавать «с нуля». Но на что должен быть похож новый интерфейс? Какие действия наиболее важны для пользователя? Ознакомившись с положением в отрасли, мы обнаружили массу хороших продуктов, в целом составляющих весьма развитый набор ПО. Однако все существующие программы перегружали пользователя информацией, что, с нашей точки зрения, является недостатком, так как это очень затрудняет выполнение самой важной задачи продукта — поиск проблем с производительностью программ. Теперь мы знали, к чему стремиться: нужно сделать так, чтобы поиск проблем с производительностью с помощью нашей программы требовал не больше трёх щелчков. Вся команда сообща работала над созданием интерфейса, чтобы решить эту просто сформулированную, но такую трудную задачу. Мы решили не усложнять интерфейс и разработали новый подход к навигации по сложной иерархии функций, в которой зачастую таятся проблемы с производительностью. В результате первый выпуск TrueTime принёс нам премию «Best of Show», присуждаемую журналом Comdex/Byte Magazine. Основным фактором успеха была концентрация усилий команды на решении определённых задач.
• Точность
Одна из самых серьёзных проблем при разработке программы — переделки по причине многократных изменений конструкции и реализации пользовательского интерфейса. Чтобы уложиться в сроки, нужно исключить крупные переделки. Хотя получить совершенный продукт с первого раза практически невозможно, надо как можно раньше скомпоновать основные элементы пользовательского интерфейса. Мелкие изменения вполне допустимы, но большие изменения могут привести к катастрофическим последствиям, негативно отражаясь на времени разработки, качестве продукта и документации.
• Планирование
Нельзя составить точный план, не зная структуры пользовательского интерфейса. Если интерфейс будет изменяться по ходу цикла разработки, то в план проекта также придётся вносить соответствующие изменения. Кроме того, необходимо предохранять план от перенапряжения , которое возникает, когда работа тестировщиков и технических писателей сдерживается изменениями пользовательского интерфейса. Таким образом, перенапряжение плана ведёт к задержке работы над проектом в целом. Помните: следует вести работу над всеми частями проекта в параллели с разработкой программы. Планирование требует чёткого понимания структуры пользовательского интерфейса уже в начале работы над проектом.
• Документация
Вам обязательно понадобится документация, описывающая работу с программой. Очевидно, что документация тесно связана с интерфейсом программы. Команда технических писателей должна быть в курсе проблем, с которыми предстоит столкнуться пользователям, а также знать, как их решить с помощью программы. Если интерфейс не довести до ума в начале работы над проектом, техническим писателям придётся постоянно нагонять разработчиков, что сделает их параллельную работу невозможной.
• Тестирование
Тестирование программы также сильно зависит от её интерфейса. Традиционно тестировщики просят разработчиков предоставить им подробные спецификации функций программы, точно описывающие все особенности её работы. К сожалению, полностью описать пользовательский интерфейс, особенно современный, практически невозможно. Лучшая замена описанию — прототип.
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 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88