Кейс: программа Drumbeat от компании Elemental

Среди интересных проектов, в которых нам довелось поучаствовать, был проект от небольшого стартапа из Сан-Диего – компании Elemental Software. В качестве одного из своих программных продуктов они предлагали инструмент под названием Drumbeat, с помощью которого можно было создавать динамические веб-сайты с базой данных в основе.

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

 

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

В существующем продукте было несколько довольно хороших функций, но его разработчики при создании руководствовались смутным представлением о пользователях. В результате пользоваться этими функциями было весьма затруднительно, а потому в целом продукт представлялся недостаточно мощным. Новый вице-президент, ответственный за разработку, – Эд Форман – возлагал на нашу компанию Cooper Interaction Design очень большие надежды. Так как он и сам недавно занял этот пост и еще не заручился доверием команды программистов, он рассчитывал, что с нашей помощью удастся радикально изменить взгляды на продукт. Как бы то ни было, Эд был превосходным лидером, предоставив нам время для общения с его командой, чтобы узнать друг друга получше и дать команде возможность познакомиться с нашими методами работы.

Исследование

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

Спустя всего несколько дней после старта мы уже могли грубо накидать портреты двух наших веб-разработчиков и дать им имена – Бетси и Эрни.

Бетси – дизайнер. Одевается во все черное и пьет эспрессо. До этого была художником, но после случайного «укуса» паука из Всемирной паутины стала создавать эскизы экранов вместо бумажных эскизов. Прочитала немалое количество книг и самостоятельно научилась создавать симпатичные, но простые, статические веб-страницы. Изучила основы HTML, однако совершенно не разбирается – и не желает разбираться – в науке программирования. Собственный сайт Бетси представляет собой сочетание модного дизайна, сглаженных шрифтов, асимметричных вставок пастельного цвета и цитат из Патти Смит и Эстер Дайсон.

Каждый раз, когда Бетси требуется обработка данных на более продвинутом уровне, она обращается к Эрни. Эрни – помешанный на компьютерах программист, представитель нового поколения. Без ума от компьютеров, компьютерных игр, языков программирования и компьютерного оборудования. Пока еще не достиг весовой категории программистов старой закалки: не владеет такими языками, как С, C++ и ассемблер, но с невероятной легкостью использует инструменты наподобие CGI, Perl, JavaScript и Visual Basic. Знаком с сотней компонентов ActiveX и JavaBeans. Способен сотворить многофункциональный программный модуль из сложных компонентов всего лишь за несколько дней, в то время как программисту на C в далеких 1980-х на ту же задачу потребовалось бы около четырех лет. Собственный сайт Эрни представляет собой хаотичную подборку цитат из космической саги «Звездный путь» и «Симпсонов». Восемь разных шрифтов, кричащие красные буквы на черном фоне, мигающий текст, потоковое аудио, дергающиеся иконки, кнопки Submit и ссылки на самые лучшие сайты, посвященные игре Quake.

Мы очень быстро поняли, что у команды разработки Elemental, ввиду отсутствия ясного представления о потребностях Бетси и Эрни, было намерение осчастливить обе персоны. В результате у них получилась размытая мешанина мощных и сложных функций в графическом воплощении. «Только гляньте, какую невероятную вещь может теперь делать пользователь!» – восторгались они. Их «пользователь» был эластичным, и они совершенно не имели представления о его целях. Образ Бетси в целом вызывал симпатию у всех программистов в Elemental, однако по натуре им был ближе Эрни, вследствие чего продукт самым естественным образом подстраивался именно под его потребности.

После того как мы представили персоны Бетси и Эрни, вся компания моментально увидела в них чрезвычайно знакомые архетипы и смогла полагаться на них как на полезные описания характеров пользователей.

Кто от кого зависит

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

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

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

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

Старт был взят довольно бодро, однако чуть дальше в ходе проектирования мы изучили цели Бетси более пристально и выявили одну интересную вещь.

В старые времена первого поколения веб-сайтов, когда они были простыми и статическими, Бетси выполняла свою работу независимо. У нее было все, чтобы отрисовать дизайн сайта и создать собственно сайт для клиента без необходимости обращаться за помощью к Эрни. Так как Бетси делала то, в чем сама была экспертом, она могла сориентировать потенциального клиента по объемам работ, срокам и стоимости проекта. И она могла с уверенностью полагаться на собственные обещания. Именно такое самоопределение и возможность быть независимой и привлекли внимание Бетси к Всемирной паутине в первую очередь. Именно это побудило ее оставить основную работу и начать работать на себя.

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

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

Несмотря на то что Бетси все еще хотела заниматься созданием прекрасных, мощных, динамических веб-сайтов, ее основная цель изменилась. С исчезновением независимости Бетси, что ранее воспринималось как данность и как цель «гигиеническая», эта потребность вышла на первый план. Все внимание Бетси теперь было направлено на желание освободиться от необходимости взаимодействовать с Эрни. Она хотела выстраивать доверительные отношения с клиентом и проектировать, а затем создавать красивые, мощные, динамические веб-сайты с базой данных в основе, без необходимости ждать, пока Эрни раскусит очередную техническую загадку.

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

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

Проектирование

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

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

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

 

В соответствии с такой постановкой задачи Эрни выступает уже не в роли программиста, пишущего код на заказ, а в роли автора новых инструментов. Теперь он может создавать совместимые подключаемые модули, которые Бетси при необходимости может удобно подключать к своим инструментам. Применение его модулей значительно расширяется, так как ими могут воспользоваться и другие «Бетси», чтобы применять их в собственных сайтах.

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

Внезапное препятствие

Поначалу разработчики компании Elemental неохотно приняли предложенное нами решение. Они пытались убедить нас, что оно не сработает, так как им в голову сразу пришло несколько исключительных ситуаций, когда Бетси все же мог понадобиться особый талант Эрни. «Мы не можем вовсе исключить Эрни из процесса, – заявили они, – ведь у Бетси может возникнуть необходимость сделать нечто специфическое или особо сложное».

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

По причине того, что Бетси ценит собственную независимость крайне высоко, она согласится на разумные жертвы ради ее достижения. Благодаря тому что с помощью Drumbeat она сможет создавать веб-сайты самостоятельно от начала и до конца, не прибегая к общению с Эрни, она готова терпеть небольшие компромиссы в дизайне, извлекая выгоду из готовых модулей Эрни^[30]. Жертва оказывается несущественной, ведь весьма небольшой процент клиентов просит создать что-то, что не реализуется типичными шаблонами. Разумеется, если ей когда-нибудь доведется получить запрос от сети универмагов WalMart на создание внутрикорпоративного портала или от отелей Hilton на разработку системы быстрого бронирования номеров, ей придется обратиться к специалисту, разбирающемуся в сложном программировании, чтобы решить эти трудоемкие задачи, однако в большинстве случаев в этом нет необходимости.

Прочие вопросы

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

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

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

Мы знали, что хорошим решением этой проблемы будет оставить под рукой только те инструменты, которые используются наиболее часто, и кроме того, объединить их в одну категорию. Если они будут разбросаны по экрану, Бетси запутается.

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

* * *

Наш вариант проектирования, равно как и продукт, возымел успех. Когда реализация продукта, основанная на нашем проекте, почти близилась к завершению, компании Elemental удалось привлечь значительные венчурные инвестиции, отчасти благодаря инновациям в его пользовательском взаимодействии. С момента выхода программа Drumbeat удостоилась многочисленных хвалебных отзывов в отраслевых изданиях. Цитата из PC Magazine дает представление об этой ситуации:

«Продукт Drumbeat поистине впечатляет своей уникальностью. Он автоматизирует процессы создания сложных веб-сайтов и превосходит по своим возможностям все прочие решения на рынке. С помощью него любой человек, не знакомый с программированием, может с легкостью создавать сайты посредством drag-and-drop. Вы сможете создать серьезный веб-сайт на уровне профессионала, при желании используя технологию Active Server Pages, и при этом не напишете ни единой строки кода».

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

* * *

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

Проектируем для людей

В предыдущих главах мы обсудили концепцию персон и убедились в важности преобладания целей над задачами. Только после того, как мы определили пользовательских персон и выяснили их цели, мы можем переходить к изучению задач, будучи уверенными, что они не нарушат процесс проектирования. Наш метод для объединения задач в единое целое мы называем «сценариями». Сценарий – это краткое описание действий пользователя, которые он предпринимает при взаимодействии с программным продуктом, пытаясь достигнуть своих целей. Далее в этой главе я остановлюсь на сценариях более подробно, а также расскажу о некоторых других инструментах, полезных при проектировании. Я также опишу кейс, из которого можно будет понять, как эти инструменты, в частности сценарии, работают на реальных проектах.

Сценарии

По мере того как в ходе процесса проектирования внимание смещается от общих концепций к проработке деталей, эффективность сценариев также повышается. Мы разыгрываем эти сценарии с нашими персонами, будто с актерами, изучающими свою роль, и через это проверяем правомерность наших предположений в отношении проектирования. Ничего удивительного, что такой процесс работы с нашими сценариями напоминает подход актера к постижению характера своего героя, когда актер вживается в образ персонажа, чтобы увидеть мир его глазами и ощутить его эмоции. Мы тоже пытаемся думать так, как это сделала бы наша персона. Мы на время забываем о собственном уровне образования, способностях, степени подготовки и методах, которыми владеем, воображая себя человеком, обладающим опытом и восприятием, присущим персоне. Учитывая, что мы являемся проектировщиками, а не актерами, воплотить подобное без понимания контекста и знания нюансов бывает нелегко, потому сценарии оказываются мощным подспорьем. К примеру, если мы обладаем информацией о том, что Бетси создает веб-сайт для страховой компании, нам становится гораздо проще проникнуть в самую ее суть. Это может показаться странным, однако на самом деле это вполне нормальная ситуация. Это так же, как программисты проникают в самую суть компьютеров. Для программистов становится привычным даже описывать действия компьютеров от первого лица, например, от них можно услышать: «Я получил доступ к базе данных и теперь сохраняю записи в своем кэше». Хотя они употребляют местоимение «я», не они выполняют все действия, а компьютер. Однако, ставя себя на место компьютера, им легче понять, что происходит у него внутри и что ему требуется, а затем реализовать это в коде.

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

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

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