Кевин Брукс - Сторителлинг в проектировании интерфейсов. Как создавать истории, улучшающие дизайн

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

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

ТАБЛ. 12.1

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

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

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

• История доктора: 6:45 вечера. Доктор В. предпочитает приезжать после обхода медсестры, когда во всех картах пациентов уже есть свежая информация. Он зашел в отделение неотложной помощи и просмотрел записи за день. Это помогло ему войти в курс дела. Удалось ли снизить температуру господина Д.? Добавила ли медсестра какие-то комментарии в описание состояния пациента?

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

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

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

Не сработало. Врачи завалили меня вопросами, как будто я была студентом-медиком на телешоу. «А что уже пробовали? Метастазы есть?» Ответа на них у меня не было. Беседа ушла в нежелательное русло.

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

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

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

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

Хороший пример – проект фирмы Adaptive Path [63], который был создан после открытого письма главы компании Apple Стива Джобса. В нем был вопрос: почему компания, которая изобрела iPod, не может создать портативное устройство для людей с диабетом?

История проекта была рассказана в блоге www.adaptivepath.com/blog. Дэн Саффер [64]пишет: «Я прочел этот призыв и подумал: постойте, не только Стив [Джобс] и Джонни [65]могут это сделать. Разве я не работаю в дизайнерской компании? Разве у нас нет инструментов для проектирования, чтобы решить эту задачу? Есть. Да, у нас все есть».

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

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

Большинство больных диабетом I типа должны делать себе уколы до 10–14 раз в день (для проверки уровня глюкозы в крови и введения инсулина).

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

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

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