« Эрик Синк: Как ликвидировать разрыв | | Простой и понятный дизайн приложений с помощью вариантов использования (use cases) по Роберту Хукману »

Дональд Норман. Почему неправильно заниматься исследованием пользователей в начале проекта

(Перевод авторской версии. Финальная версия статьи была опубликована в 2006 году в журнале Interactions)

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

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

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

Большинство проектов представляют собой продолжение или расширение уже существующих продуктов. И что же, разве надо опять и опять начинать с изучения пользователей? Разве у нас мало информации о них, уже накопленной в течение адаптационного периода продукта? Как только проект вступил в фазу разработки, заниматься исследованиями уже поздно. Подумайте об этом.

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

Но постойте-ка, ведь наше постоянное желание начать проект с полевых исследований и вычисления истинных нужд пользователей, это шаг назад. Это линейный, негибкий процесс, который стоит непосредственно перед стадиями дизайна и написания программного кода. Мы требуем для себя "водопадного" метода разработки, хотя и отрицаем его полезность для других.

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

Программисты уже давно борются с теми же проблемами. Они тоже пытаются избавиться от длительных, фиксированных и линейных процессов разработки, которые замедляют работу. Они экспериментируют с новыми гибкими методологиями, например, ХР (экстремальное программирование), и другими быстрыми итеративными методиками. И молодцы.

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

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

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

Один из участников дискуссии на эту тему заметил в списке рассылки CHI: "Я ни разу не видел и не слышал, чтобы программисты, работающие согласно "гибким" методологиям, согласились замедлить темп своих "скрамов", чтобы дождаться результатов юзабилити-тестирования. В так называемых "гибких" юзабилити-практиках нет места для исследования. Это просто игра в угадывание - что же все-таки нужно пользователям?"

Этот человек немного запутался. Юзабилити-тестирование похоже на бета-тестирование продукта. С его помощью никогда не определяют "что нужно пользователям". Оно предназначено для обнаружения проблем и ошибок, поэтому прекрасно подходит для новых итеративных методологий, точно так же как подходит для них и бета-тестирование, в процессе которого программисты отлавливают и исправляют ошибки в приложении. Я уже давно говорю, что компанию, которая гордится тем, что проводит юзабилити-тестирование, ждут серьезные проблемы. Точно такие же как и ту, которая гордится, что проводит бета-тестирование. Тестирование пользовательского интерфейса и бета-тестирование предназначены только для исправления ошибок, но не для редизайна системы.

Так давайте же отделим полевые исследования и наблюдения, концептуальную фазу работы над дизайном и анализ требований пользователя от непосредственной работы над продуктом. Мы должны понять, что нужно пользователям еще до начала проекта, потому что к началу работы направление уже должно быть выбрано. Нам необходимо освоить быстрые итеративные методы работы. Мы должны найти свое место в новых процессах разработки, которыми пользуются программисты, и стать полноправными членами команды. Эти новые методологии особенно хороши тем, что явно подчеркивают важность хорошего HCI-дизайна продукта. Все хотят, чтобы мы включались в работу, но только при условии, что мы не станем ее тормозить. Да будет так.

Дон Норман является со-основателем компании Nielsen-Norman Group, профессором Northwestern University и писателем. Живет он по адресу http://www.jnd.org

Эта статья написана для журнала Interactions (© CACM, 2006). Это авторская версия статьи. Она публикуется с разрешения ACM только для персонального и некоммерческого использования.

kirsa January 14, 2008 6:25 PM

Комментарии

конечно не правильно....нужно клиентов изучать постоянно, на протяжении всего процесса сотрудничества...

Опубликовано: Bolton в January 16, 2008 8:45 AM

это и есть поведенческий таргетинг во времени? :)

Опубликовано: CCatch в January 18, 2008 10:42 AM

to CCatch: что вы имеете в виду?

Опубликовано: sashka в January 18, 2008 10:52 AM

Сделать комментарий




Запомнить меня?