Управление рисками с помощью применения бумажных прототипов
Раздел: Разработка сайта 04-12-2004 FAQ оптимизатору на форуме ZenBroker
Как правило, делать первые шаги в каком-либо новом деле – неблагодарная миссия, особенно, если эти шаги - ошибочны. Представьте себе ситуацию: потрачены годы на создание продукта, и все это только для того, чтобы в конечном итоге обнаружилось полное несоответствие новинки потребностям целевого сегмента рынка. Да, разработка программных продуктов – поистине рискованный бизнес. Успешные продукты возникают на обломках многочисленных провальных товаров и компаний, их создавших.
Основная цель данной статьи – помочь компаниям-разработчикам снизить риск создания продукта-неудачника.
Мы консультируем фирмы, специализирующиеся на дизайне пользовательского интерфейса и вопросах usability; наш первоначальный контакт с новыми клиентами обычно происходит, когда обнаруживаются сбои в работе их продукта. Обычно все начинается со звонка менеджера по маркетингу, который описывает нам проблемную ситуацию: новый продукт был впервые выпущен около года назад, однако, продажи весьма посредственные. И хотя клиенты компании довольны функциональностью, они жалуются на то, что программное обеспечение сложно в использовании (менеджер признался, что даже профессионалы компании испытывают трудности при работе с этим продуктом!). Менеджер также выразил озабоченность относительно того, что возникающие проблемы во-первых, подорвут продажи следующего выпуска, во-вторых, серьезно увеличат затраты на поддержку.
Что же делать? Для эффективного управления этими рисками, компании, скорее всего, необходимо изменить стратегию работы с новыми продуктами.
Мы видим, что затрачены значительные временные и финансовые ресурсы на подготовку к выпуску первой партии, и, как выяснилось, всего лишь, чтобы понять, что поставленные цели не достигнуты. В известном смысле, первая партия товара была на самом деле «прототипом» следующего выпуска, причем, прототипом, отнявшим многие годы разработок. За это время рынок стал более жестким, конкурентным и компания не может позволить себе еще один неудачный выпуск. Кроме того, они не могут годами (или даже в течение месяцев) ждать решающего вердикта клиентов – нужно получить обратную связь до проведения beta-тестирования (которое планировалось через несколько недель) .
Именно это мы помогли им сделать: используя методы создания бумажных прототипов и usability-тестирования, мы показали разработчикам, как получить быструю обратную связь и понять возможную реакцию рынка на новый товар перед тем, как будут сделаны серьезные инвестиции и усилия по созданию. Общее затраченное время на реализацию этой методики: около шести дней.
День первый
Состоялась встреча с командой разработчиков. Этот коллектив был похож на все другие команды, с которыми мы когда-либо работали, со сложившейся системой взглядов на вопросы разработки интерфейса, а также методов поиска и исправления ошибок. Проблема была в том, что они не располагали достаточным количеством достоверных данных о наиболее важных для потенциальных клиентов качествах будущего продукта, то есть какие задачи клиенты планируют решить с помощью этого продукта. Конечно, работа в условиях отсутствия подобной информации сопряжена с риском реализации ошибочных решений. Поэтому первым делом мы договорились с «подшефной» командой о наиболее существенных потребительских свойствах, с которыми в первую очередь связаны ожидания целевого сегмента потребителей. Так как не было времени на тестирование всех аспектов продукта, мы должны были сконцентрироваться на наиболее рискованных моментах - то есть на всем, что могло бы сделать следующую партию товара успешной или наоборот - провальной. В этом вопросе все члены команды разработчиков были едины во мнении: наибольший риск состоит в том, что продукт проблематичен в использовании и это может произвести негативное впечатление на клиентов-профессионалов.
Важно понять: если разработчики не знают, где находится область риска – это уже само по себе самый большой риск!
Второй и третий дни
Мы приступили к поиску людей, соответствующих профилю целевых потребителей, для проведения сессий usability-тестов. Тем временем, мы продемонстрировали сотрудникам команды разработчиков, как построить бумажный прототип интерфейса продукта, учитывая области повышенного риска . Используя обычные канцелярские принадлежности (маркеры, карточки, ножницы, прозрачную пленку) разработчики быстро набросали все элементы интерфейса (экран, меню, error message) на отдельных клочках бумаги.
Мы завершили работу по созданию интерфейса к концу третьего дня. Конечно, все это не было аккуратно оформлено – написанный от руки текст, кривые линии и сделанные в последнюю минуту пометки – но этого было достаточно, чтобы показать, как будут выглядеть экраны.
Четвертый и пятый дни
Мы попросили одного разработчика сыграть роль «компьютера», он должен был изображать поведение программного обеспечения, оперируя листами бумаги. Например, если клиенты хотели открыть документы в Windows , им нужно было коснуться слова «Файл» в меню. «Компьютер» реагировал, вытаскивая листок бумаги, содержащий опцию меню «Файл». Клиент далее вызывает опцию «Открыть», компьютер при этом показывает открытый диалоговый ящик.
Два дня ушло на тестирование бумажного прототипа. В каждой сессии тестов участвовали два человека, представляющих целевой сегмент. Мы демонстрировали им работу программного обеспечения, не объясняя при этом, как работает интерфейс – вместо этого их попросили проделать реальные операции с помощью прототипа. «Компьютеру» не разрешалось что-либо подсказывать пользователям, он мог только совершать операции в соответствии с назначением интерфейса.
Участников тестов не спрашивали об их мнении относительно интерфейса; наблюдались только их фактические действия с программным обеспечением (бывали ситуации, когда люди выражали позитивное отношение к продукту, хотя испытывали при этом трудности в использовании, или наоборот). Все разработчики наблюдали за ходом тестов, делая пометки в тех случаях, когда обнаруживались проблемы в использовании интерфейса.
Разработчики были удивлены огромным количеством выявленных проблем. В некоторых случаях, возникали споры по поводу слабых мест, не обнаруженных пользователями. К тому же обнаружились серьезные недоработки интерфейса, о которых никто даже не подозревал. Благодаря Usability-тестированию каждый специалист увидел все узкие места продукта, которые могли бы повлиять на успех следующей партии.
После каждого двухчасового тестирования, разработчики обсуждали свои наблюдения и сразу же вносили коррективы в бумажные прототипы. С бумажными прототипами вся команда могла участвовать в разработке дизайна, вместо того, чтобы взвалить весь объем работы на одного или двух программистов. Специалисты команды разработчиков (инженеры, маркетологи, управленцы, специалисты по обучению), используя фломастеры и ножницы, отражали свое экспертное мнение в бумажных прототипах.
Изменения в бумажных моделях менее болезненны, чем уже выпущенном программном продукте. С готовым продуктом – сложнее: из-за существенного объема весьма трудоемкой работы, затраченной на создание, сотрудники команды разработчиков склонны защищать свое изделие, прикладывая максимум эмоций, даже когда для всех очевидна необходимость изменений – ведь, на самом деле, очень сложно выбросить на ветер потраченные усилия. В противоположность этому, из-за простоты создания и возможности безболезненно вносить изменения в1 бумажные прототипы, соответственно, сотрудникам незачем тратить энергию на их «защиту». В результате разработчики становятся более гибкими, мобильными и охотнее экспериментируют с новыми идеями. В рассматриваемом нами случае команда затратила около двух часов на внесение изменений.
После ланча были приглашены еще два пользователя, для выполнения тех же самых заданий, чтобы посмотреть, сделали мы в итоге продукт лучше или хуже исходного. Выяснилось, что большинство изменений оказались усовершенствованиями. Некоторые изменения были так просты, как, например, использование различных слов, перемещение значка с верха экрана вниз или предоставление примера в справочном файле. Другие изменения были более существенными – мы были свидетелями того, как разработчики практически полностью переработали свои продукты, буквально за ночь, после того, как поняли, что первоначальный дизайн был просто обречен на провал.
День 6
После двух дней тестирования были определены самые существенные проблемы в интерфейсе. На 6-й день мы снова встретились с командой специалистов, чтобы проранжировать по уровню важности оставшиеся недоработки продукта, используя при этом уже не субъективные мнения и оценки, а научно обоснованные данные, полученные в ходе usability-тестов. Учитывая жесткий график, (оставался месяц до beta-тестирования) члены команды знали, что должны сосредоточиться на наиболее рискованных моментах для, того, чтобы следующий выпуск был успешным. И только на седьмой день ребята смогли отдохнуть.
Используя бумажные прототипы и usability-тестирование, разработчики имеют возможность контролировать риски, сосредоточившись на них в самом начале работы над проектом, пока еще есть время для внесения изменений. При этом начать необходимо с определения узких мест, могущих серьезно повлиять на успех последующих серий выпуска продукта – мест наибольшего риска. Наш основной вопрос специалистам был такой: «Что является следующим наибольшим риском?» В итоге они поняли, как использовать бумажные прототипы и usability-тестирование для информационного обеспечения принятия ключевых решений, ведущих к разработке качественного продукта, отвечающего потребностям целевого рынка.
Эта статья впервые появилась в «Software Design and Publisher Magazine», в октябре 1996
При поддержке дизайн-студии Netsah – web site design and development studio, web site promotion services, graphic design
А так же студии Promodo – Раскрутка сайта. Продвижение оптимизация сайтов. Реклама маркетинг в Интернет. Советы специалистов.
