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

Возможно, вы уверены, что отличная идея или продукт продадутся сами. Говорят, что одна картинка стоит тысячи слов. Но в случае продукта эти слова нужны, чтобы объяснить смысл картинки (или прототипа). Истории показывают связь между исследованиями пользователей, изначальной идеей и проектом (рис. 5.6) и благодаря этому наглядно демонстрируют работоспособность нового продукта.

РИС. 5.6.В рамках истории можно описать идею проекта

Erickson T. Notes on Design Practice: Stories and Prototypes as Catalysts for Communication // Carroll J. (ed.) Scenario-Based Design: Envisioning Work and Technology in System Development. John Wiley & Sons, 1995.

Rosson M., Carroll J., Cerra D., Hill N. Usability Engineering: Scenario-Based Development of Human Computer Interaction. Morgan Kaufmann, 2001.

Константин Л., Локвуд Л. Разработка программного обеспечения. СПб.: Питер, 2004.

Hackos J., Redish J. User and Task Analysis for Interface Design.

AIGA, «Введение в этнографию» (AIGA, An Ethnography Primer): http://www.aiga.org/ethnography-primer/.

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

• Идея применения сторителлинга не нова. Во многих методиках истории применяются для передачи информации о взаимодействии пользователей с продуктом.

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

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

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

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

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

Недавно меня попросили написать тексты для нового сайта компании. Я задала вопрос о целевой аудитории. Они хотели раскрутить нового разработчика PAAS [41]– решений для малого бизнеса. Директор представлял себе это так: «Приложение настолько просто в использовании, что даже моя бабушка с ним бы справилась». Ставилась задача создать приложение с функцией перетаскивания для разработки модулей программного обеспечения.

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

Для начала я опросила потенциальных клиентов. Результат удивил всех. Считалось, что новый продукт предназначен для малых компаний, в которых работает не более 100 сотрудников и чей доход не превышает 5 млн долл. На втором собеседовании выяснилось, что целевой рынок – не малый бизнес, а микробизнес: число сотрудников не превышает 10, а доход – 1 млн долл.

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

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