«Jesse James Garrett книга дж. гарретта ОРИЕНТИРОВАННЫЙ НА ПОЛЬЗОВАТЕЛЯ ЭЛЕМЕНТЫ ОПЫТА ВЗАИМОДЕЙСТВИЯ Серия Библиотека дизайнера Джесс Гарретт Вебдизайн: книга Джесса Гарретта Элементы опыта взаимодействия Перевод С. ...»

По договору между издательством «Символ Плюс» и Интернет магази

ном «Books.Ru – Книги России» единственный легальный способ полу

чения данного файла с книгой ISBN 5 93286 108 8, название «Веб ди

зайн: книга Джесса Гарретта. Элементы опыта взаимодействия» – покуп

ка в Интернет магазине «Books.Ru – Книги России». Если Вы получили

данный файл каким либо другим образом, Вы нарушили международное

законодательство и законодательство Российской Федерации об охране

авторского права. Вам необходимо удалить данный файл, а также сооб щить издательству «Символ Плюс» ([email protected]), где именно Вы получили данный файл.

The Elements of User Experience User-Centered Design for the Web Jesse James Garrett книга дж. гарретта

ОРИЕНТИРОВАННЫЙ НА ПОЛЬЗОВАТЕЛЯ

ЭЛЕМЕНТЫ

ОПЫТА

ВЗАИМОДЕЙСТВИЯ

Серия «Библиотека дизайнера»

Джесс Гарретт Вебдизайн: книга Джесса Гарретта Элементы опыта взаимодействия Перевод С. Иноземцева А. Галунов Главный редактор Н. Макарова Зав. редакцией А. Копылов Научный редактор В. Подобед Редактор О. Макарова Корректор Д. Орлова Верстка Гарретт Дж.

Вебдизайн: книга Джесса Гарретта. Элементы опыта взаимодействия». – Пер. с англ. – СПб.: СимволПлюс, 2008. – 192 с.: ил.

ISBN-10: ISBN-13: 978- По-настоящему эффективный сайт должен служить вашим стратегическим целям, одновременно удовлетворяя потребности ваших пользователей. Даже самый интересный контент и самые передовые технологии не помогут вам сбалансировать эти две задачи без поддержки последовательного и непротиворечивого опыта взаимодействия. Однако создание опыта взаимодействия кажется невообразимо сложным делом, ведь приходится учитывать массу вопросов – юзабилити, идентичность бренда, информационную архитектуру, дизайн взаимодействия.

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

ISBN-10: ISBN-13: 978- ISBN 0-7357-1202-6 (англ) © Издательство СимволПлюс, Authorized translation of the English edition, Copyright © 2003 Pearson Education, Inc. This translation is published and sold by permission of Pearson Education, Inc., the owner of all rights to publish and sell the same.

Все права на данное издание защищены Законодательством РФ, включая право на полное или частичное воспроизведение в любой форме. Все товарные знаки или зарегистрированные товарные знаки, упоминаемые в настоящем издании, являются собственностью соответствующих фирм.

Издательство «Символ-Плюс». 199034, Санкт-Петербург, 16 линия, 7, тел. (812) 324-5353, www.symbol.ru. Лицензия ЛП N 000054 от 25.12.98.

Подписано в печать 17.03.2008. Формат 70х90 1/16. Печать офсетная.

Объем 12 печ. л. Тираж 3000 экз. Заказ № Отпечатано с готовых диапозитивов в ГУП «Типография «Наука»

199034, СанктПетербург, 9 линия, 12.

American Institute of Graphic Arts 164 Fifth Avenue New York, NY Tel 212 Fax 212 www.aiga.org Книга «The Elements of User Experience» в простой и систе матической форме разъясняет одну из самых значитель ных идей, возникших на стыке дизайна, технологии и биз неса: границы возможного определяются не технологичес кими достижениями, а тем, как мы ставим эти достиже ния на службу людям.

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

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

AIGA (American Institute of Graphic Arts – Американский институт графического искусства) принимает активное участие в издании лучших работ признанных лидеров в об ласти дизайна – авторов, которым удается раздвинуть го ризонты дизайна и помочь практикующим дизайнерам держаться на переднем крае и находить новые пути к вер шинам мастерства. AIGA – крупнейшая и старейшая про фессиональная ассоциация дизайнеров в Соединенных Штатах. Среди ее членов есть представители всех дисцип лин, так или иначе касающихся вопросов дизайна.

Посвящаю моей жене, с которой становится возможным все.

Оглавление Опыт взаимодействия: почему он так важен.......... ГЛАВА Конкурентная борьба и возврат инвестиций............ ГЛАВА ГЛАВА ГЛАВА Функциональные спецификации и требования ГЛАВА Проектирование взаимодействия и информационная Дизайн интерфейса, дизайн навигации Элементы опыта взаимодействия на практике....... Об авторе Джесс Джеймс Гарретт (Jesse James Garrett) – один из ос нователей Adaptive Path, консалтинговой фирмы в Сан Франциско. С 1995 года Джесс Гарретт работал над веб проектами для таких компаний, как AT&T, Intel, Boeing, Motorola, Hewlett Packard и National Public Radio. Его вклад в развитие области опыта взаимодействия состоит, среди прочего, в разработке Visual Vocabulary (буквально – «визуальный словарь») – открытой нотационной системы, предназначенной для документирования информацион ной архитектуры и принятой в настоящее время во многих организациях по всему миру. Его личный сайт www.jjg.net представляет собой один из самых посещаемых веб ресур сов по информационной архитектуре, а сам Джесс являет ся автором множества статей и выступлений на темы ин формационной архитектуры и опыта взаимодействия.

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

Дэвид Хоффер (David Hoffer) имеет обширный опыт в об ласти информационной архитектуры и дизайна интерфей са. Сейчас он является ведущим проектировщиком поль зовательского интерфейса в отделе маркетинга и связей с клиентами CTB/McGraw Hill, где курирует вопросы архи тектуры, интерфейса и юзабилити. До перехода в McGraw Hill Дэвид работал ведущим информационным архитекто ром в Hill and Knowlton Public Relations – одной из круп нейших в США PR компаний, входящей в состав второго в мире по величине глобального рекламного конгломерата WPP Group. Два года Дэвид проработал ведущим проекти ровщиком в отделении Alexa Internet Division компании Amazon.com, где создал клиентские интерфейсы для броу зерных продуктов Amazon Alexa. Дэвид оказывал консуль тации многим фирмам, работающим в области высоких тех нологий, – от мелких предприятий, таких как NERDS и ActiveBuddy, до крупнейших и известнейших компаний Motorola и DEC. Он получил степень бакалавра гуманитар ных наук в области промышленного дизайна в Рочестер ском институте технологии. Дэвид обожает собак.

Молли Райт Стинсон (Molly Wright Steenson) начала свою деятельность в Интернете в 1994 году. С тех пор она руко водила разработкой архитектуры для более чем 60 сайтов таких компаний, как Netscape, Reuters, Wrigley, Nike, Genentech и др. Она часто публикует статьи на темы, свя занные с дизайном в Интернете, и выступает на междуна родных конференциях. В вопросах дизайна и разработки Молли – сторонник подхода, ориентированного на пользо вателя. Она работает редактором сайта AIGA Experience Design, а также является менеджером проекта Razorfish в Сан Франциско и владельцем сайта Girlwonder.com. Сво бодно говорит на трех языках: немецком, французском и голландском.

Благодарности Пусть количество имен на обложке не вводит вас в за блуждение: своим успехом книга обязана широкому кругу людей.

Во первых, я хочу поблагодарить своих партнеров по Adap tive Path. Это Лэйн Беккер (Lane Becker), Дженис Фрейзер (Janice Fraser), Майк Кунявски (Mike Kuniavsky), Питер Мерхольц (Peter Merholz), Джеффри Вин (Jeffrey Veen) и Инди Янг (Indi Young). Только с их разрешения я смог взяться за этот проект.

Я благодарен всем сотрудникам издательства New Riders, а особенно мне помогли Майкл Нолан (Michael Nolan), Кэйрин Уайтхаус (Karen Whitehouse), Виктория Элзи (Victoria Elzey), Дебора Хиттель Шауф (Deborah Hittel Shoaf), Джон Рам (John Rahm) и Джейк Мак Фарленд (Jake McFarland). Их советы были исключительно важны для моей работы.

Ким Скотт (Kim Scott) и Эйрин Хауэлл (Aren Howell) уде лили большое внимание дизайну этой книги. Терпение, с которым они принимали мои идеи, было выше всяких похвал.

Молли Райт Стинсон (Molly Wright Steenson) и Дэвид Хоф фер (David Hoffer) оказали мне неоценимую помощь, ре дактируя рукопись. Не каждому автору так везет.

Джесс Мак Маллин (Jess McMullin) оказался моим самым строгим критиком во всех отношениях, и под влиянием его замечаний книга стала намного лучше.

Приношу благодарность многим более опытным авторам, чьи советы помогли мне справиться с этим проектом и не сойти с ума. Это вновь Джеффри Вин (Jeffrey Veen) и Майк Кунявски (Mike Kuniavsky), Стив Круг (Steve Krug), Джун Коэн (June Cohen), Натан Шедрофф (Nathan Shedroff), Лу ис Розенфельд (Louis Rosenfeld), Питер Морвиль (Peter Morville) и (особенно) Стив Шемпьен (Steve Champeon).

Назову тех, кто вносил ценные предложения или просто оказывал мне моральную поддержку: Лайза Чен (Lisa Chan), Джордж Олсен (George Olsen), Кристина Уодтке (Christina Wodtke), Джессамин Уэст (Jessamyn West), Са манта Бейли (Samantha Bailey), Эрик Шайд (Eric Scheid), Майкл Энжелес (Michael Angeles), Хавьер Веласко (Javier Velasco), Антонио Вольпон (Antonio Volpon), Вук Косич (Vuk Cosic), Терри Гуле (Thiеrry Goulet) и Деннис Вудт (Dennis Woudt). Их взгляд на некоторые вещи отличается от моего, а это бесценно для настоящего сотрудничества.

Музыкальное сопровождение моей работы над рукописью обеспечили Man or Astro man?, Pell Mell, Mermen, Dirty Three, Trans Am, Tortoise, Turing Machine, Don Caballero, Mogwai, Ui, Shadowy Men on a Shadowy Planet, Do Make Say Think и (особенно) Godspeed You Black Emperor!

Наконец, есть три человека, без поддержки которых эта книга никогда бы не была написана: Дина Сэндерс (Dinah Sanders), которая однажды теплым техасским вечером на стояла на том, чтобы я кое с кем познакомился; моя жена Ребекка Блад (Rebecca Blood), благодаря которой я станов люсь сильнее и мудрее день ото дня; и Дэниел Грэссем (Daniel Grassam), без чьей дружбы, одобрения и поддерж ки я, возможно, никогда бы не оказался в этом бизнесе.

Спасибо!

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

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

Адрес нашей электронной почты: [email protected] Введение Эта книга не содержит готовых рецептов. В мире есть ве ликое множество книг, в которых объясняется, как созда вать веб сайты, – эта книга не из их числа.

Эта книга не описывает технологию. От первой до послед ней страницы здесь нет ни строчки кода.

Эта книга не предлагает готовых ответов – она о том, как задавать правильные вопросы.

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

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

Предыстория Поскольку меня часто об этом спрашивают, я расскажу, как появились на свет «The Elements of User Experience»

(Элементы опыта взаимодействия).

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

Одновременно с этим у меня копилась подборка связанных с новой работой материалов. (Впоследствии из этой под борки сформировалась страничка с ресурсами по информа ционной архитектуре на моем сайте www.jjg.net/ia/.) Изу чая собранные материалы, я постоянно испытывал досаду на произвольное и случайное употребление терминов, обо значающих базовые понятия в этой области. То, что в од ном источнике именовалось «информационным дизай ном», в другом называлось «информационной архитекту рой». А третий источник сваливал все в одну кучу под на званием «дизайн интерфейса».

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

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

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

По возвращении в Сан Франциско я почти сразу слег с из нурительной простудой и провел в горячке около недели.

Пойдя на поправку, я превратил набросок в законченную схему, которая целиком умещалась на листе бумаги. Я на звал ее «Элементы опыта взаимодействия». Позже я уз нал, что у многих людей это название вызывает ассоциа ции с периодической системой Д. И. Менделеева и книгой Странка и Уайта «Элементы стиля».1 К сожалению, эти ас социации не возникли у меня, когда я подбирал название.

Я просто выбрал «элементы», чтобы не употреблять неук люжий термин «компоненты», звучащий слишком техни 30 марта я опубликовал в Интернете окончательный вари ант. (Первоначальную диаграмму по прежнему можно най ти по адресу http://www.jjg.net/ia/elements.pdf.) Диаграмма привлекла внимание. Первыми ею заинтересовались Питер Мерхольц (Peter Merholz) и Джеффри Вин (Jeffrey Veen), впоследствии ставшие моими партнерами в Adaptive Path.

Вскоре я доложил о диаграмме широкой аудитории на пер вой конференции Information Architecture Summit. Посте пенно до меня стали доходить известия о том, как люди в самых разных уголках земного шара используют диа грамму для «просвещения» своих коллег и выработки внутри организации общего языка, позволяющего обсуж дать эти вопросы.

Известное практически каждому американскому старше класснику краткое руководство по грамматике, стилистике и композиции текста. – Примеч. ред.

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

Снова наступил март, и я опять оказался в Остине на кон ференции South by Southwest. На ней я познакомился с Майклом Ноланом (Michael Nolan), сотрудником изда тельства New Riders Publishing, и изложил ему свою идею.

Он отреагировал на нее с энтузиазмом – как, к счастью, и руководство издательства.

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

Джесс Джеймс Гарретт (Jesse James Garrett) июль www.jjg.net/elements/ ГЛА ВА Опыт взаимодействия:

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

Повседневные напасти У каждого из нас время от времени бывают такие дни, ко гда ничего не получается.

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

Вы включаете кофеварку и убегаете одеваться. Когда вы возвращаетесь за спасительной дозой кофеина, оказывает ся, что кофе в кофеварке нет. На выяснение причин не ос талось времени – пора мчаться на работу!

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

Наконец вы заливаете в бак бензин, трогаетесь с места, отъезжаете – и слышите, как колпачок бензобака падает с крыши машины и, подпрыгивая, катится по дороге.

Из за ДТП на магистрали вы вынуждены направиться в объезд, так что путь до места работы отнимает больше времени, чем вы ожидали. И вот вы перед фактом: несмот ря на все усилия, вы опоздали. Наконец вы добрались до своего рабочего стола. Вы чувствуете возбуждение, опусто шенность, усталость и раздражение – а день еще толком не начался. И вы все еще не сделали ни единого глотка кофе.

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

Авария на дороге. Она произошла из за того, что водитель на секунду отвлекся, чтобы убавить громкость радиопри емника. Ему пришлось отвести взгляд от дороги, так как на ощупь отличить ручку громкости от других невозможно.

Колпачок бензобака. Вы потеряли колпачок, потому что по ложили его на крышу, когда заправлялись, а потом в спеш ке забыли о нем. Если бы он был просто прикреплен к ма шине и его не нужно было бы куда либо пристраивать, вы бы его не потеряли.

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

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

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

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

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

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

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

Скорее всего, нет. Так из за отсутствия щелчка кнопки те ряется клиент.

Опыт взаимодействия в Сети Эта книга посвящена опыту взаимодействия, связанному с одним конкретным видом продуктов – с веб сайтами. Во Всемирной паутине опыт взаимодействия играет еще более важную роль, чем в случае других продуктов.

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

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

Как это произошло? На заре существования Сети многие усматривали ключ к успеху в том, чтобы быть первыми на рынке. Сайты, подобные Yahoo!, захватили лидерство, ко торое конкуренты впоследствии изо всех сил старались отобрать. Солидные фирмы бросились разрабатывать веб сайты, боясь прослыть отсталыми. Однако в большинстве случаев уже сам по себе запуск веб сайта рассматривался как великое достижение, а вопрос о том, удобен ли сайт для людей, в лучшем случае отступал на задний план.

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

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

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

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

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

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

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

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

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

Преданность клиентов – не единственное, чего вы добье тесь, уделяя внимание опыту взаимодействия на своем сайте. Компании, ориентированные на конечный резуль тат, стремятся понять, какую прибыль приносит инвести рованный капитал. Показатель под названием возврат ин вестиций (ROI – return on investment) обычно измеряется в денежных единицах: сколько долларов вы заработаете в расчете на каждый потраченный доллар? Однако вовсе не обязательно выражать этот коэффициент в монетарных терминах. Все, что вам нужно, – это мера, показывающая, насколько успешно потраченные деньги превращаются в нечто ценное для вашей компании.

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

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

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

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

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

Веб сайты – это сложные технологические продукты, а ко гда у людей возникают проблемы в обращении со сложны ми продуктами, происходит забавная вещь: люди винят в неудаче себя. Они подозревают, что сделали что то не так… Им кажется, что они были недостаточно вниматель ны… Они чувствуют себя дураками… Да, это неразумно.

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

Возможно, никто за пределами вашей компании не видит ваш сайт (как в случае с интранет порталом), однако опыт взаимодействия все равно играет огромную роль. Часто он определяет разницу между проектом, приносящим пользу фирме, и проектом, превратившимся в кошмар, пожираю щий все ресурсы.

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

Чем меньше времени уйдет на выполнение конкретного задания, тем больше вы успеете за день. В соответствии со старой истиной «время – деньги» экономия времени ва ших сотрудников оборачивается прямой экономией денег в вашем бизнесе.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

пользователи хотят купить книги, а мы хотим их продать.

Однако другие цели могут оказаться не столь очевидными.

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

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

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

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

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

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

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

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

Обсуждение этих вопросов постепенно приобретает непро тиворечивые формы. Однако чтобы понять сами термины, мы должны проследить их происхождение.

Когда Всемирная паутина только зарождалась, все своди лось к гипертексту. Люди могли создавать документы и свя зывать их ссылками с другими документами. Тим Бер нерс Ли (Tim Berners Lee) изобрел Всемирную паутину, чтобы исследователи в области физики высоких энергий, живущие в разных странах, могли иметь доступ к работам друг друга и ссылаться на них. Он знал, что потенциал Всемирной паутины этим не исчерпывается, но тогда мало кто действительно понимал, как огромен этот потенциал.

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

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

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

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

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

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

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

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

На «гипертекстовой» половине нас интересует информа ция – какую информацию предлагает сайт и что она зна чит для наших пользователей. Создание гипертекста – это создание информационного пространства, в котором могут перемещаться пользователи.

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

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

Противовесом пользовательским потребностям являются наши собственные цели. Эти цели сайта могут быть бизнес целями («Заработать миллион долларов на интернет прода жах в этом году») или какими либо иными («Информиро вать избирателей о кандидатах, участвующих в ближайших выборах»). В главе 3 мы подробно обсудим эти элементы.

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

У информационных пространств структура определяется информационной архитектурой – организацией элемен тов содержимого в пределах информационного простран ства. Эта тема подробно раскрывается в главе 5.

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

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

Уровень компоновки обсуждается в главе 6.

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

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

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

В этой книге отсутствует подробное освещение двух допол нительных факторов, формирующих опыт взаимодейст вия. Первый – это контент. Старая (по меркам Всемирной паутины) поговорка гласит: «Контент – царь и бог Сети».

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

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

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

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

Применение элементов ГЛА ВА Уровень стратегии

ЦЕЛИ САЙТА И ПОТРЕБНОСТИ ПОЛЬЗОВАТЕЛЕЙ

В основе успешного проектирования опыта взаимо действия лежит четко сформулированная стратегия.

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

Однако ответить на эти простые вопросы труднее, чем кажется на первый взгляд.

Определение стратегии Самая распространенная причина провала веб сайта кро ется не в технологии и не в опыте взаимодействия. Чаще всего веб сайты терпят неудачу потому, что перед написа нием первой строчки кода, рисованием первого пикселя и установкой первого сервера никто из нас не потрудился ответить на два принципиальных вопроса:

Что хотим получить от нашего сайта мы?

Что хотят получить от него наши пользователи?

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

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

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

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

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

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

Идентичность бренда При формулировании целей любого сайта важной темой является идентичность бренда. Когда большинство из нас слышит слово «бренд», мы думаем о логотипах, цветовых решениях и полиграфических изысках. Хотя визуальные аспекты бренда важны (мы вернемся к ним, когда дойдем до уровня поверхности в главе 7), само понятие бренда вы ходит далеко за рамки визуальных образов. Идентичность бренда – комплекс концептуальных ассоциаций или эмо циональных реакций – важна потому, что ее невозможно обойти стороной: взаимодействие пользователей с вашим сайтом неизбежно оставляет след в их сознании, формируя впечатление о вашей организации.

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

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

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

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

Иногда метрики успешности связаны с самим сайтом и его использованием. Сколько времени проводит средний поль зователь на вашем сайте в течение каждого посещения?

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

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

Не всякая метрика успешности связана с сайтом напря мую – вы можете замерять также косвенные последствия.

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

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

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

Потребности пользователей При разработке сайта есть риск попасть в ловушку, ориен тируясь на одного идеализированного пользователя – в точ ности такого, как мы сами. Но ведь мы создаем сайт не для себя, а для других. Чтобы им понравилось наше творение и они захотели им пользоваться, мы должны понять, кто они и что им нужно. Потратив время на исследование пользовательских потребностей, мы сможем вырваться за рамки наших ограниченных представлений и увидеть сайт глазами пользователей.

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

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

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

Эти демографические профили могут быть довольно общи ми («мужчины от 18 до 49 лет») или весьма конкретными («незамужние женщины со средним специальным образо ванием в возрасте от 25 до 34 лет с годовым доходом 50 ты сяч долларов и выше»).

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

Однако документирование психографических профилей ваших пользователей позволит вам узнать то, чего не ска жет демография.

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

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

Приложение для торговли акциями, ориентированное на новичков фондового рынка, должно работать иначе, чем приложение для опытных инвесторов.

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

Проведя некоторые исследования групп ваших пользова телей, вы, возможно, пересмотрите сегменты, с которыми работаете. Например, если вы исследуете сегмент, вклю чающий женщин со средним специальным образованием в возрасте от 25 до 34 лет, вы можете обнаружить отличия в потребностях возрастной группы от 30 до 34 лет от по требностей группы 25–29 лет. Если разница значительна, вы, вероятно, захотите разбить первоначальную группу от 25 до 34 лет на две. С другой стороны, если вдруг ока жется, что группа от 18 до 24 лет во многом схожа с груп пой от 25 до 34, их можно будет объединить. Определение сегментов аудитории – только средство для раскрытия по требностей пользователей. На практике вам нужно столь ко сегментов, сколько имеется различных групп пользова тельских потребностей.

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

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

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

Однако в любом случае речь идет о стремлении сделать продукты простыми в использовании.

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

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

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

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

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

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

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

Пользовательское тестирование – самая распространенная форма исследования пользовательской аудитории. Пользо вательское тестирование – это не тестирование пользовате лей; это тестирование вашего продукта пользователями.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

вычеркивается из бюджета проекта в первую очередь.

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

Одна группа сотрудников при формулировании стратегии часто оказывается не у дел. Речь идет о рядовых членах – людях, ответственных за повседневную работу компании.

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

Цели сайта и потребности пользователей часто определя ются в формальном документе под названием «Стратегия сайта» или «Общее представление о сайте». Иногда по требности пользователей документируются в отдельном отчете об исследовании пользовательской аудитории (хотя имеются определенные преимущества в том, чтобы вся ин формация находилась в одном месте). Этот документ – не просто список целей; в нем анализируется взаимосвязь между различными целями и их место в контексте дея тельности организации. Цели и их анализ часто подкреп ляются буквальными цитатами из бесед с заинтересован ными сторонами, рядовыми сотрудниками и пользовате лями. Эти цитаты наглядно иллюстрируют вопросы стра тегии проекта.

Когда речь идет о документировании стратегии, «больше»

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

Самое худшее, что вы можете сделать с документом о стра тегии сайта, – ограничить доступ к нему членов команды.

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

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

Что читать дальше Cooper, Alan. The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity. Sams, 1999. Krug, Steve. Don’t Make Me Think: A Common Sense Ap proach to Web Usability, Second Edition. New Riders, 2006. Spool, Jared M., et al. Web Site Usability: A Designer’s Guide.

Morgan Kaufmann, 1998.

Веб ресурсы: www.jjg.net/elements/resources/ Алан Купер «Психбольница в руках пациентов, или почему вы сокие технологии сводят нас с ума и как восстановить душев ное равновесие». – Пер. с англ. – СПб.: Символ Плюс, 2004.

Стив Круг «Веб дизайн: книга Стива Круга, или «не застав ляйте меня думать!», 2 е издание. – Пер. с англ. – СПб.: Сим вол Плюс, 2008.

ГЛА ВА Уровень набора возможностей

ФУНКЦИОНАЛЬНЫЕ СПЕЦИФИКАЦИИ

И ТРЕБОВАНИЯ К КОНТЕНТУ

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

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

Определение набора возможностей Есть вещи, которые мы делаем ради самого процесса – на пример, бегаем трусцой по утрам или разучиваем гаммы на фортепиано. Есть дела, которые мы выполняем, чтобы получить результат, – например, печем пирог с сыром или чиним автомобиль. Определение набора возможностей системы относится к обеим категориям сразу: это ценный процесс, который дает ценный результат.

Процесс ценен тем, что заставляет вас выявлять потенци альные противоречия и «шероховатости» конечного про дукта на том этапе, когда сам результат существует лишь в вашей голове. Мы можем определить, за что следует взяться прямо сейчас, а что придется отложить на потом.

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

Однажды я работал над веб приложением, которое, каза лось, навеки застряло в состоянии бета версии: почти (но не совсем) готово к передаче пользователям. Многое в на шей работе было неправильным: технология была нена дежной, мы ничего не знали о наших пользователях, а я был единственным человеком в компании, имевшим хоть какой то опыт разработки для Всемирной паутины.

Однако ни один из этих фактов не объяснял, почему мы не можем закончить работу над продуктом. Главным камнем преткновения было наше нежелание документировать тре бования. В конце концов, какой смысл занудно протоко лировать все и вся, если мы и так работаем в одной комна те? Да и нашему менеджеру необходимо было направить всю свою энергию на отслеживание новых технологиче ских веяний… Результатом был продукт, представлявший собой постоян но меняющуюся мешанину функциональных возможно стей разной степени завершенности. Любая прочитанная кем то из нас статья, любая мысль, пришедшая кому ни будь в голову во время возни с продуктом, вдохновляла нас на обсуждение новой функциональности. Работа кипела, но без графика, без каких либо контрольных точек – и это му не было ни конца ни края. Если никто не знал четкого набора возможностей продукта, как можно было понять, что проект закончен?

Существуют две основных причины для документирова ния требований к продукту.

Причина №1: вы будете знать, что именно вы создаете Эта идея кажется очевидной, но для команды разработчи ков того веб приложения она была полной неожиданно стью. Если вы точно опишете то, что собираетесь постро ить, каждый будет знать цели проекта – и когда они будут достигнуты, то все сразу поймут это. Конечный продукт перестанет быть смутной картиной в голове менеджера проекта и превратится в нечто осязаемое, с чем может иметь дело любой сотрудник компании – от руководителей высшего звена до рядовых инженеров.

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

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

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

Функциональность и контент На уровне набора возможностей мы переходим от абст рактного вопроса «Зачем мы делаем этот сайт?», который задавали себе на уровне стратегии, к новому вопросу: «Что мы собираемся создать?».

На уровне набора возможностей проявляется разделение Всемирной паутины на программные интерфейсы и гипер текстовые информационные пространства. На «программ ной» половине мы занимаемся функциональностью – тем, что составляет «перечень функций» программного продук та. На «гипертекстовой» половине мы имеем дело с контен том – традиционной сферой издательских и маркетинго вых компаний.

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

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

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

Требования к контенту часто имеют функциональный под текст. В наше время для работы с наполнением сайта обыч но применяются системы управления контентом (CMS – content management system). Такие системы бывают самы ми разными – от очень больших и сложных, способных ав томатически генерировать страницы на основе десятков различных источников информации, до предельно облег ченных узкоспециализированных инструментов, предна значенных для максимально эффективного управления контентом какого либо конкретного вида. Вы сами решае те, купить ли вам коммерческую систему, воспользоваться одной из множества систем с открытым исходным кодом или разработать собственную с нуля. В любом случае вам придется подстроить систему под нужды вашей организа ции и под контент вашего будущего сайта.

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

Функциональные требования со своей стороны влияют на контент. Потребуются ли инструкции на экране настроек?

Как насчет сообщений об ошибках? Все это кто то должен написать. Каждый раз, когда я вижу на веб сайте сообще ние типа «Исключение: передана пустая строка», я пони маю, что в готовом продукте остался текст предупрежде ния, вставленный кем то из программистов в качестве за глушки, и произошло это потому, что в требования к кон тенту никто не добавил сообщения об ошибках. Огромное количество якобы высокотехнологичных проектов могло бы стать радикально лучше, если бы кто нибудь из их раз работчиков взял на себя труд пристально посмотреть на контент приложения.

Сбор требований Бывают требования, которые касаются сайта в целом. Од ним из распространенных примеров являются требования, связанные с брендингом. Другой пример – технические требования (например, поддерживаемые броузеры и опе рационные системы).

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

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

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

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

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

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

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

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

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

Как ваш сайт сможет упростить для него процессы выбора и последующего приобретения вашего товара?

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

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

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

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

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