Все мы любим технологии. Именно поэтому мы и работаем в этой отрасли. У нас есть скрытая уверенность, что технологии избавят мир от всех проблем. Мы преуспели в создании технологий и напичканных ими устройств или веб-сайтов. Однако зачастую нам не удаётся соединить технологии таким образом, чтобы наши пользователи могли ими с лёгкостью пользоваться и оценить по достоинству. Часто мы с благоговением смотрим на вещи, которые трудно было спроектировать и построить, не принимая во внимание конечную цель, которой они должны служить. За многие годы работы я заметил, что наша любовь к технологиям не всегда ведёт нас в правильном направлении. В этой статье я постараюсь объяснить, чего недостаёт нашему мышлению.
Правило получения удовольствия от работы
Возможно, ваш менеджер искренне хочет, чтобы вы весело проводили время и занимались только самыми интересными проектами. Но этого ещё не достаточно. Правда жизни сформулирована в так называемом правиле получения удовольствия от работы: вас наняли, чтобы вы получали удовольствие только в том случае, если пользователь полностью удовлетворён взаимодействием с созданным вами продуктом. Ведь зарплату вам – как и всем нам – платит конечный пользователь. Поэтому всё, что вы делаете, должно в конце концов идти на пользу потребителю, а значит и вашей компании. Надо стараться, чтобы как можно больше целей вашей компании совпадало с целями пользователя.
Каждая строка кода, каждая вовремя обнаруженная ошибка, любое маркетинговое исследование должны идти на пользу потребителю. Неважно, в чём заключается ваша работа, это правило касается и вас. Например, исправление драйвера, повышение надёжности или оптимизация работы сервера – всё это делает продукт лучше в понимании любого пользователя. Проведение маркетингового исследования помогает правильно определить группу людей, чьи потребности вы можете удовлетворить. Если вы не видите, как именно ваша деятельность помогает пользователю, лучше потратьте своё время на что-нибудь другое. Чем больше вы думаете о своей работе и о работе вашей команды с точки зрения конечного пользователя, тем выше вероятность, что вы создадите хороший продукт.
Наши клиенты – это не мы
У людей, работающих в нашей отрасли, складывается особый тип мышления. Мы проводим бoльшую часть времени в окружении людей, набравших огромное количество баллов в тестах по математике, мы знаем людей, которые занимаются опционами и первичным размещением акций на фондовом рынке, мы работаем с людьми, которые разбирают и собирают компьютеры ради удовольствия. Мы забываем, что люди из нашего окружения сильно отличаются от остального мира. Вот почему порой присутствие на юзабилити тестировании продукта или участие в фокус-группе напоминает экскурсию в сумрак. Кажется, что все эти пользователи составляют меньшинство, что они гости из другой галактики, искажённой и заторможенной. Но в реальности это мы – доминирующее меньшинство. А большинство – это все те посетители юзабилити лабораторий, и именно эти люди используют наши продукты и платят нам зарплату.
Ничто не может быть полезнее наблюдений за тем, как кто-то использует созданный тобою продукт. Это единственный способ проверить, как намеченные цели соотносятся с реальностью. Хотели бы вы, чтобы хирург оперировал вас без проведения первичного осмотра? Или чтобы нанятые вами специалисты по отделке делали ремонт на вашей кухне, не поинтересовавшись вашими пожеланиями? Хороший мастер старается понять мир, в котором будет использоваться его продукт, до того, как он этот продукт создаст. Мы обладаем удивительными способностями творить, но очень часто совершаем ошибку, производя вещи, которые нравятся их создателям, а не потребителям. Нельзя осознать свою предубеждённость, если не учитывать удобство использования продукта и другие формы обратной связи с потребителем. Общение с пользователем необходимо на протяжении всего цикла создания продукта.
Что важнее – потребитель или технологии?
Существует фундаментальное различие в подходах к созданию продукта у сторонников «технологического» подхода и истинных проектировщиков. Технари склонны начинать с технологий. Набирается команда разработчиков, создаётся технология, а пользовательский интерфейс и взаимодействие продукта с пользователем проектируются лишь на поздних этапах в рамках, которые диктует технология. При таком подходе потребитель будет гарантированно недоволен. Продукт в таком случае создаётся не для использования, а для демонстрации технологии. Как вы считаете, дожидается ли искусный повар последнего момента, чтобы понять, каким должен быть вкус блюда? Снимает ли портной мерки после того, как костюм уже раскроен?
Хороший мастер своего дела всегда знает, как люди будут использовать его изделие. Любое решение принимается исходя из предназначения продукта. Разработка программного обеспечения или создание веб-сайтов не исключение. Те же люди, что посещают рестораны и кинотеатры, являются потребителями наших продуктов. Мы должны проявлять интерес к тому, как создаются продукты в других областях промышленности, как они решают поставленные перед ними задачи. Производители автомобилей, CD-плееров, электрооборудования – все думают над тем, как уравновесить технические аспекты, бизнес интересы и юзабилити, только они занимаются этим гораздо дольше нас. Мы можем научиться очень многому, анализируя их успехи и неудачи, а также используемые ими подходы.
Почему простой продукт – хороший продукт?
Лучшие продукты – это те, которых мы не замечаем. Реальная сила инженеров и разработчиков заключается в превращении чего-либо невероятно сложного во что-то невероятно простое. Разработать автоматическую трансмиссию для автомобиля гораздо сложнее, чем ручную. Лучшие достижения автомобильной промышленности, градостроительства, бытовой электроники показывают, что отличное проектирование сосредоточено на сокрытии сложности, а не на её демонстрации.
Лучший способ повысить ценность продукта – добавить новые возможности, не усложняя при этом эксплуатацию. Если есть желание добавить в продукт новую функциональность, надо выяснить, можно ли при этом обойтись без пользовательского интерфейса, и можно ли автоматизировать эту функцию без ущерба для надёжности. Есть ли возможность модифицировать или убрать какую-то иную функцию, чтобы заменить старое новым и улучшенным? Хорошим примером такого подхода служат автомобили, новые возможности в которых требуют минимальных действий со стороны потребителя. Антиблокировочная система управляется все той же обычной педалью тормоза, а усилитель руля – всего лишь дополнение рулевого колеса. Не требуется никакого обучения или специальной подготовки со стороны водителя, чтобы воспользоваться новыми преимуществами. Вот такие достижения в проектировании – когда сложные черты кажутся потребителю простыми – и делают продукт замечательным.
Программный продукт как услуга
Заходя в магазин спортивных товаров за консультацией о приобретённом там ранее рюкзаке, вы рассчитываете на должное уважение и соответствующее обслуживание. Вы ожидаете, что продавцы будут общаться на вашем уровне, выслушают вас и сделают всё возможное для решения вашей проблемы. Пользователи программного обеспечения и посетители веб-сайтов ничем не отличаются в этом плане от покупателей в магазине спорттоваров. Они желают видеть уважительное к себе отношения и получить хорошее обслуживание. Покупатель – в нашем случае пользователь – всегда прав.
Мы допускаем серьёзный промах, обвиняя в появлении сообщения об ошибке программы пользователей, а не разработчиков. Если из-за проблемы с базой данных на сервере пользователю не удаётся совершить покупку на веб-сайте, кто виноват? Мы. Нам не хватило ума, чтобы предотвратить подобную ситуацию. Менеджер проекта и проектировщики не смогли разработать правильный интерфейс, либо команда разработчиков и тестеры не обнаружили серьёзный дефект в работе системы. Сообщения об ошибках на веб-сайтах в этом плане ничем не лучше – а возможно, даже хуже – чем ошибки в программах. Когда выявляется ошибка в нашем продукте, ведём ли мы себя как продавец за прилавком? Оказываем вежливо помощь? Считаем, что клиент всегда прав? Практически никогда. Обычно мы ограничиваемся ответом вроде: «Server error 152432. Scripting service failure».
Каждое сообщение об ошибке – это пользователь в беде. Представьте, как он сидит в своём кабинете, опаздывает на важную встречу и нервничает, потому что не может сделать то, что ему требуется. И о чём же он думает в этот момент? Каждое сообщение об ошибке, которое вы закладываете в продукт – это возможность предоставить хорошее обслуживание. Если вы хотите предложить великолепный продукт или сервис на вашем веб-сайте, необходимо включить в своё расписание время на разработку системы обработки ошибок и создание сообщений об ошибках. Менеджер проекта должен предусмотреть в официальном расписании команды разработчиков и тестировщиков время на систему обработки ошибок. Однако помните: не бывает хороших сообщений об ошибке. Хороша та ошибка, которая была устранена на этапе разработке и проектирования.
Обслуживание значит больше, чем просто сделать сообщения об ошибках, которые будут помогать пользователей вместо того, чтобы их обвинять. Существует огромное количество возможностей предоставить отличный сервис. Полезно понаблюдать, как кто-нибудь знакомится с основными функциями вашего веб-сайта, и задать себе вопрос, можно ли сравнить ваше предложение с уровнем сервиса, который вы ожидаете от ресторана или магазина. Чем сильнее продукт приближается к качеству обслуживания, которое люди рассчитывают получить в повседневной жизни, тем ближе вы к созданию хорошего продукта.
Как найти время, чтобы создать замечательный продукт
Сделать что-либо хорошо довольно сложно. Написание хорошего кода занимает больше времени, чем написание плохого. Если менеджер проекта сосредоточен на создании хорошего продукта, то потребуется приложить усилия, чтобы правильно поставить задачи перед командой и согласовать их реализацию с графиком работ. Это его работа. И если он не справляется с этой задачей, вы должны обратить на это его внимание. Если проблема заключается в том, чтобы найти время на создание пользовательского интерфейса, проектирование взаимодействий и обеспечение юзабилити в процессе разработки продукта, необходимо проконсультироваться со специалистами по проектированию и юзабилити инженерами. Хороший продукт является результатом хорошей организации процесса, но многие до сих пор этого так и не поняли. Зачастую инвестирование в юзабилити экономит деньги и время, так как продукт должен быть хорошо спроектирован изначально, а не исправляться «заплатками» от релиза к релизу.
В хорошо организованной команде каждый участник ориентирован на понимание того, как его индивидуальный вклад влияет на потребителя. До начала разработки общими усилиями менеджера проекта, группы планирования продукта и группы юзабилити должна быть обрисована схема того, с какими проблемами сталкивается потребитель, и каким образом функции и технологии, разрабатываемые командой, способны их решить. Без этих рамок гарантированно будет создана технология, которая не решает никаких проблем. Каждый день надо задавать себе вопрос, какую проблему вы решаете на данном этапе, чья она, и имеет ли смысл тратить на это время. Если вы стремитесь создать что-либо полезное, и знаете, как это сделать, остаётся спланировать свой проект таким образом, чтобы достичь этой цели. Ссылки на нехватку времени при разработке важных аспектов продукта – не более чем трусливый компромисс. На самом деле они означают, что в вашей команде планирование организовано не должным образом, что намеченные цели не совпадают с графиком. Если забота о потребителе не входит в число ваших приоритетов, настало время переосмыслить ваши ценности. Для чего-то важного время всегда найдется.
Откуда берётся качество?
Чтобы произвести на свет хороший продукт, следует стать на место потребителя. Я уверен, что преданность интересам пользователя имеет первостепенное значение. Разошлите эту статью участникам вашей команды. Проведите юзабилити тестирование вашего продукта или узнайте, как оно проводится. Выясните у проектировщиков, что было сделано не так. Спросите у вашего инженера по юзабилити, как и что он делает, и чем вы можете ему помочь. Занимаемая вами должность не имеет значения, в любом случае зарплату платит вам пользователь. Если вы трудитесь над созданием пользовательских интерфейсов, помогите другим участникам команды расширить кругозор, приветствуйте их участие. Прочитав хорошую статью или книгу по проектированию, передайте её тому, кому она может потребоваться. Если вы – один из тех немногих в вашей команде, кто страстно переживает за хорошее проектирование, вам предстоит преодолеть много трудностей. Я же помогу в меру своих возможностей советами.
Впервые опубликовано в «Юзабилити Бюллетень, выпуск 5, апрель 2007».