Итеративное проектирование

Итеративное проектирование (Iterative design) — подход к проектированию, при котором проектное решение улучшается в повторяющихся циклах: создается версия решения (часто — прототип), ее оценивают, обычно с участием пользователей, анализируют найденные проблемы и выпускают исправленную версию, которую снова оценивают¹.

Подход сложился в проектировании пользовательских интерфейсов, где считается, что интерфейс без проблем удобства с первой попытки спроектировать практически невозможно¹. В стандарте ГОСТ Р ИСО 9241-210 итеративное совершенствование проекта — один из принципов человеко-ориентированного проектирования (human-centred design) интерактивных систем².

Назначение

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

Якоб Нильсен (Jakob Nielsen) формулирует ту же мысль применительно к интерфейсам: даже лучшие специалисты не проектируют интерфейс без недостатков за один раз, поэтому жизненный цикл инженерии удобства использования (usability engineering) должен строиться вокруг итераций¹.

Цикл итеративного проектирования

Типичная итерация состоит из четырех шагов:

Создание версии. Проектное решение воплощается в форме, которую можно показать пользователям: сценарий, модель, макет, прототип. Стандарт рекомендует на ранних этапах простые образцы для сравнения альтернатив; уровень проработки образца должен соответствовать вопросам, которые с его помощью проверяют².
Оценка. Версию проверяют пользователи (и другие методы оценки) — по Нильсену, отмечаются проблемы, с которыми столкнулись тестовые пользователи¹. О назначении проверки см. Тестирование.
Анализ. Найденные проблемы разбирают и решают, что и как менять. Результат оценки в практических проектах — прежде всего список проблем и предложений по улучшению, а не количественные показатели¹.
Доработка. Проблемы исправляют в новой версии. Новую версию снова проверяют, чтобы убедиться, что исправления действительно сработали, и найти проблемы, которые они могли внести¹.

Изменения между итерациями обычно локальны — затрагивают те элементы интерфейса, которые вызвали затруднения. Итеративное проектирование не сводится к замене элементов на новые идеи наугад; сравнение двух альтернативных интерфейсов Нильсен относит к другому методу — сравнительному тестированию¹.

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

В человеко-ориентированном проектировании

ГОСТ Р ИСО 9241-210-2016 (идентичен ISO 9241-210:2010) задает шесть принципов человеко-ориентированного подхода²:

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

Итерация в стандарте определена как повторение последовательности действий до достижения желаемого результата. Итерируются четыре вида деятельности: понимание и определение условий использования, определение требований пользователей, разработка проектных решений и их оценка². Стандарт не предписывает конкретного процесса разработки: эти действия можно встроить в каскадный, гибкий, объектно-ориентированный и другие подходы. В методах с короткими циклами разработки итерации сначала проводят на отдельных частях системы, а затем — на уровне продукта в целом². В плане проекта должно быть предусмотрено время на итерации и сбор отзывов пользователей².

Итеративный подход применяется не только к интерфейсу: стандарт упоминает, что он может понадобиться и для других аспектов проекта — технологичности изготовления, влияния на рабочую среду, изменений рынка². Подробнее об учете человеческого фактора — в статье Эргономика.

Эффективность

Нильсен в статье 1993 года разобрал четыре проекта, в которых интерфейс дорабатывался по результатам пользовательского тестирования. Медианное улучшение общего показателя удобства от первой до последней версии составило 165 %, в среднем на одну итерацию — 38 %; от первой версии ко второй медиана улучшения была 45 %, от второй к третьей — 34 %¹. Нильсен подчеркивает, что это грубая оценка по четырем случаям с большим разбросом¹.

Там же приведен пример экономического эффекта по данным К.-М. Карат (C.-M. Karat): интерфейс приложения компьютерной безопасности улучшали в трех версиях; по оценке, сэкономленное время пользователей соответствовало 41 700 долларов затрат на персонал при дополнительных расходах на итеративное проектирование 20 700 долларов¹.

Ограничения

Убывающая отдача. Первые итерации дают наибольший выигрыш — устраняются грубые ошибки, дальше возможности улучшения сокращаются. Нильсен предполагает, что удобство одного и того же решения нельзя повышать итерациями бесконечно, а предел иногда удается преодолеть только переосмыслением всего решения. Нильсен приводит пример системы поиска телефонных номеров, которую после 14 версий с командной строкой переделали на меню, после чего оценки пользователей заметно выросли¹.
Новые проблемы при исправлениях. Доработка, направленная на одни показатели, может ухудшить другие, поэтому Нильсен рекомендует делать не менее трех версий интерфейса¹.
Стоимость прототипов. Если на проработанный образец потрачено много времени и средств, это может вызвать нежелание менять проект².
Ресурсы на итерации. Итерации требуют времени и людей для повторных оценок, их нужно заранее заложить в план проекта².

Связь с итеративной разработкой

В программной инженерии близкая идея известна как итеративная и инкрементная разработка (iterative and incremental development, IID). По обзору Крейга Лармана (Craig Larman) и Виктора Базили (Victor Basili), ее корни восходят к циклам «планируй — делай — изучай — действуй» (PDSA) Уолтера Шухарта 1930-х годов, которые продвигал Эдвардс Деминг; среди ранних применений — проект гиперзвукового самолета X-15 в 1950-х и программное обеспечение проекта Mercury в начале 1960-х³. В 1975 году Базили и Тернер описали итеративное улучшение (iterative enhancement), а в 1985 году Барри Боэм предложил спиральную модель, в которой итерации упорядочиваются по риску³. Эти идеи развиты в гибких методах; противопоставляемая им однопроходная последовательная модель — водопад³.

Литература

ГОСТ Р ИСО 9241-210-2016. Эргономика взаимодействия человек-система. Часть 210. Человеко-ориентированное проектирование интерактивных систем.
Nielsen J. Iterative User-Interface Design // IEEE Computer. — 1993. — Vol. 26, № 11. — P. 32–41.
Larman C., Basili V. R. Iterative and Incremental Development: A Brief History // IEEE Computer. — 2003. — Vol. 36, № 6. — P. 47–56.

См. также

Nielsen J. Iterative User-Interface Design // IEEE Computer. — 1993. — Vol. 26, № 11. — P. 32–41. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹² ↩¹³
ГОСТ Р ИСО 9241-210-2016. Эргономика взаимодействия человек-система. Часть 210. Человеко-ориентированное проектирование интерактивных систем. Разделы 4–6. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹
Larman C., Basili V. R. Iterative and Incremental Development: A Brief History // IEEE Computer. — 2003. — Vol. 36, № 6. — P. 47–56. ↩ ↩² ↩³