пользовательский сценарий для мобильного приложения
Пользовательские сценарии: что это такое, как и для чего их нужно строить
Денис Нарижный, руководитель интернет-агентства «Студия F1» и создатель сервиса юзабилити-тестирования сайтов AskUsers.ru, рассказал Нетологии о том, как составлять и использовать пользовательские сценарии.
Сценарии описывают пользовательские истории и взаимосвязи между ними. Они помогают определить, зачем и почему пользователи приходят на сайт и как достигают своих целей: совершают покупки, заказывают по телефону, сравнивают товары, общаются с консультантами.
Прежде чем разработать сценарий, нужно ответить на три вопроса:
1. Кто те люди, что заходят на ваш сайт?
Нужно выделить чёткий сегмент аудитории и проработать портрет клиента, под которого готовится сценарий.
2. Почему они заходят к вам?
На основе аналитики или опроса можно определить, зачем на самом деле пользователи посещают ваш сайт: просто посмотреть, что-то узнать или купить.
3. Какие цели при этом преследуют и как их достигают?
Вариантов не так много, особенно если мы говорим о коммерческих сайтах. Обычные цели — изучить предложение с целью сравнить его с другими, непосредственно купить или сделать заказ, но возможны и другие варианты.
Пошагово достижение целей обычно расписывается в профилях задач. Здесь такая детализация не нужна, просто нужно понимать, какие шаги делает пользователь для достижения цели.
Для чего нужны пользовательские сценарии
Сценарии помогают лучше понимать предпочтения посетителей сайта и анализировать пользовательский опыт. Это нужно, чтобы в дальнейшем проектировать сайт или интерфейс так, чтобы он вписывался в привычные для клиентов паттерны и приводил к цели посещения за наименьшее количество шагов и с минимальными затратами сил, времени и внимания.
Также сценарии используют для анализа пользовательского опыта при проведении юзабилити-тестов и других маркетинговых исследований.
Сценарий — наглядное схематическое представление того, как пользователь решает свою задачу с помощью сайта, что ему помогает и что мешает в достижении цели.
Разновидности сценариев
Пользовательские сценарии по степени детализации и технической проработки делятся на четыре группы.
1. Пользовательские истории
Это самый насыщенный подробностями вариант: рассказ, схемы, видео, фотографии — все, что помогает описать опыт взаимодействия, иногда даже без привязки к персоне клиента. У каждого пользователя может быть своя история и свой специфический опыт. Это сбор сырой информации.
Если мы говорим о покупке: кто-то берет для себя, а кто-то в подарок, кто-то подарит маме, а другой — жене. У кого-то все хорошо с финансами, кто-то собирал деньги на покупку, кого-то интересует кредит и рассрочка. Опыт в этих пользовательских историях будет отличаться.
Запишите простые человеческие истории: «Через месяц у нас юбилей свадьбы, я отложил деньги и собираюсь выбрать подарок жене. У меня есть предел по стоимости, я знаю, что жена любит серебро и носит серьги…».
Вот пример из серии скринкастов: пользователь пытается сделать покупку в интернет-магазине:
Прототипируем приложение: сценарии, анимация, иконки, юзабилити-тест на примере Моего Мира
В этой статье на примере трехмесячного опыта работы над проектированием мобильного приложения Моего мира я расскажу о том, как мы проходили все этапы создания, зачем рисовать свои идеи на бумаге, как боролись со шрифтами и преодолевали другие сложности, как проводили UX-тестирование и о многом другом.
Все началось с того, что первой трудностью, которая ожидала нас при разработке дизайна приложения, оказалась работа с так называемым legacy-дизайном. У нас на руках был продукт, в котором нужно было разобраться и понять, какие метафоры использовал предыдущий дизайнер.
На примере профиля видно, как было «до» и что стало «после».
Структура проекта
Первым делом была составлена структурная схема проекта. При подготовке использовалась программа Mindjet, позволяющая создавать огромные mind map’ы. Туда складывались все описания, сценарии, страницы. На картинке приведен небольшой фрагмент mind map’а.
На самом деле это здоровенный файл с древовидной иерархией, с описанием практически каждой страницы и пользовательских сценариев.
Сценарии использования приложения
Следующим этапом стала разработка пользовательских сценариев. Об этом я расскажу подробнее на примере уведомлений.
Прежде всего, при составлении сценария выявляется цель, которой будут достигать пользователи на каждом из экранов приложения. В случае уведомлений, цель — быть в курсе событий в своём окружении, то есть всего, что связано с самим пользователем, его друзьями, коллегами и т.д. После получения уведомления пользователь может перейти на соответствующую страницу. В зависимости от типа уведомления (оповещения из игр, приглашения к дружбе, комментирование, отметки «Нравится». ) возможны различные сценарии. Пользователь может переходить в игры или профиль другого пользователя, может написать кому-нибудь сообщение, и так далее. Все эти варианты нужно «прописать» в mind map, отметив возможные пересечения.
Анализ опыта конкурентов
Итак, сценарии прописаны, можно переходить к следующему этапу — анализу опыта конкурентов. Этот этап необходим при прототипировании любых приложений: он позволяет, во-первых, не изобретать велосипед заново, а во-вторых, избежать некоторых возможных ошибок.
В основном рассматриваются, конечно, прямые конкуренты. Мы изучали не только топовые социальные сети, но и менее популярные. Проштудировали огромный пласт приложений: все их нужно было изучить, понять их поведение, как они общаются с пользователем, как они преподносят информацию.
Также мы анализировали опыт косвенных конкурентов. Например, для нашего раздела музыки это iTunes и другие профильные приложения. Если дело касается фотографий, то фотографировали мы абсолютно во всем — в Instagram, Mobli и т.д. Все это дало нам понимание того, как себя ведет аудитория в различных приложениях.
Мы исписали целую стопку бумаги формата А4, детально прорабатывая каждый экран. Почему именно на бумаге? Так психологически проще начать решать какую-то задачу. Всегда понятно, откуда «плясать» — сначала рисуешь квадрат, а от него уже строишь все остальное. Это помогает преодолеть психологический барьер, и уже гораздо проще «вылить» идеи на лист.
Итак, гора бумаги изрисована. Теперь нужно понять, в чем будет создаваться графический макет приложения. Photoshop сразу был отметен из-за своего избыточного функционала: его возможности искушают дизайнера углубиться во все детали. Такая сверхподробная проработка отнимает чересчур много времени, над каждой деталью можно работать чуть ли не бесконечно, а результат труднопрогнозируем.
Следующим кандидатом был InDesign. Я люблю эту программу, потому что в свое время я верстал журналы и вообще много всякой бумажной продукции. Круче, чем InDesign, наверное, для этого не найти. Однако сразу обнаружилась одна из его проблем—: полупиксели. InDesign заточен для печати, где это не столь важно. А вот когда садишься рисовать что-нибудь для цифровой среды, это становится большой проблемой. Еще одна сложность, связанная с ориентированностью на бумагу — идентификационные номера для страниц: при добавлении новой страницы полностью разваливается структура, невозможно понять, куда нужно переходить с каждой из страниц и в итоге все заканчивается крахом, злостью и кучей потраченного впустую времени.
Далее на очереди был Axure. Это идеальная программа для проектирования, у нее самый мощный инструмент прототипирования, есть и тайминги, можно эмулировать действия, которые совершает человек на мобильниках. Но финальные картинки в нем не создать, сначала придется где-то все эти экраны нарисовать, залить в Axure и свести в единый прототип.
В итоге был выбран Fireworks. Это продукт Adobe, достаточно тесно интегрированный с другими адобовскими продуктами — Illustrator, Photoshop — поэтому в нем удобно было проектировать. Итоговые варианты он экспортирует в HTML, что удобно. Кроме того, все можно демонстрировать прямо с телефона своему руководству, коллегам и т.д.
Еще один большой этап — вайрфреймы (wireframes). Обычно он следует за «бумажным» этапом — можно сказать, что это своеобразная фиксация мысли. На данной стадии я все еще не вдаюсь в детали, мне не важно, какого цвета будут кнопки, но я уже композиционно доверстываю блоки, которые у меня родились на бумаге. Уже можно собирать первые кликабельные прототипы и вместе с коллегами смотреть, как что работает, удобно или нет. Это своеобразный конструктор прототипов, благодаря которому наша программа уже начинает материализоваться.
Рассмотрим варианты вайрфреймов, которые создавались для диалогов и левого меню. Практически сразу видно, где расположены доминанты, а где все остальное. После того, как блоки расставлены по своим местам, остается только доработать это графикой.
Примерно так это выглядит в Fireworks:
Бирюзовые блоки кликабельны. Конечно, это только верхушка айсберга. Страниц, которые вели друг на друга и постоянно перекрещивались между собой, было около 100. В этот момент главное — не запутаться; но в целом, уже можно показывать, как будет в финале выглядеть продукт.
Мы подошли к следующему пласту работ. Прототипировать анимацию очень важно — это выводит нас на диалог с разработчиком и помогает убедиться что: а) все переходы реализованы логично и пользователь сможет сориентироваться, и б) вы с разработчиком говорите на одном языке и одинаково представляете, как эти переходы будут реализованы.
Иногда можно многое прорабатывать детально (например, drag-to-refresh, который тоже разрабатывался в виде анимации), чтобы потом передать разработчикам. iOS предоставляет хорошие инструменты для работы с анимацией, и обычно программисты делают все своими руками.
С Android это адски сложно, приходится нарезать каждый кадр. От этого медленно сходишь с ума. Потом еще надо сделать в четырех разных размерах. В конце ты понимаешь, насколько ты не хочешь делать анимацию для Android и хочешь делать ее для iOS.
В итоге мы все же добились того, что Мой Мир сохраняет визуальную идентичность на iOS и Android, а также в мобильном вебе. Наше приложение, в целом, уже близко к своему финальному виду, начинается отделка фасада.
Достижению этой идентичности немало способствовал единый шрифт. Было известно, что в мобильном вебе с реализацией проблем не будет: достаточно было выбрать бесплатный шрифт и подключить его через font face для мобильного веба. В iPhone и в Android тоже есть функция «кастомизация шрифтов». Я был несказанно рад, что мы будем еще более идентичны на всех платформах. Однако тут начались проблемы.
Разработчики каждый день подходили ко мне и говорили, что я негодяй и должен согласиться на дефолтные шрифты. Шрифт, который был выбран, Open Sans, на iOS выдавал предупреждения и требования подключить другой шрифт: iOS казалось, что символы кернятся неправильно (в действительности, визуально ничего не менялось). Еще были проблемы, связанные с тем, что у iOS свое представление о межстрочных интервалах — они были просто огромными. Спасибо программистам, которые смогли хаками обойти систему и сделать так, что выбранный шрифт стал выглядеть приятно глазу.
Android, конечно, доставил не меньше проблем. Почему-то он считает, что Navigation bar должен идти с системными шрифтами. При этом если бы этот шрифт был везде одинаковым, все было бы не так грустно. Но нет! В каждой оболочке шрифт свой, любовно выбранный разработчиком. Например, на Samsung это был шрифт, похожий на Comic Sans. Наконец, все нестыковки со шрифтами преодолены, переходим к следующему этапу.
Единая сетка для проекта
Шрифты и анимация не единственные компоненты, влияющие на унификацию. Третьим «китом» является единая сетка, которая разрабатывалась сразу под три платформы. Что взять за модуль и от чего потом построить все остальные элементы — этот вопрос мучил меня около двух дней, которые я провел в подсчетах.
Изначально нужно было понять, какие константы уже заложены разработчиками операционных систем (например, в iOS это навигационная панель с размером 44 пикселя) и учесть это при построении сетки. В итоге микромодулем был выбран 4х4 пикселя. В основу горизонтального ритма лег шестиколонник с канавкой в 4 пикселя.
Финальный глянец нашей программе был придан с помощью иконок. Я давно приглядывался к контурным иконкам — очень понравились работы iconwerk. Мы сделали модуль, под который строились иконки Моего Мира. Когда же вышла первая бета iOS 7, я подумал: «Неплохо, попали в тренд». Потом нашлось еще много схожестей, которые мы, не видя iOS 7, уже реализовали в приложении. Поэтому мы одни из самых первых вышли на рынок iOS 7-приложений.
Итак, готово все, вплоть до иконок, настало время тестов. Сейчас станет ясно, насколько верными оказались наши расчёты, насколько точно мы смогли предсказать поведение пользователей, смогли ли соблюсти баланс между функционалом и удобством использования каждого экрана приложения. Юзабилити-тестирование — это всегда вызов для разработчика. Для тестирования нужно предусмотреть и прописать все сценарии взаимодействия: как пользователь будет себя вести, куда будет нажимать и попадать, что мы должны получить от пользователей (чтобы понять, соответствует ли результат нашим ожиданиям).
Дальше — сложнее: мы тестировали наше приложение целиком. То, что показано на скриншоте, только часть структуры, а в прототипах для дальнейших тестов количество элементов возрастало в разы.
Что я могу посоветовать: на этом этапе не надо вылизывать абсолютно все детали, до мельчайшего пикселя. Самое главное, чтобы вы проверили, правильно ли пользователь идет по маршруту, который вы заложили. Если он отрабатывает все с нужной вам скоростью, то есть быстро воспринимает информацию, сразу понимает, насколько важно ему в определенное место зайти, где какой раздел находится, как найти того, с кем ему хочется пообщаться, где находятся уведомления и т.д. и т.п., — то дело в шляпе.
Внесение правок и эксперименты
Юзабилити-тесты мы проводили практически в интерактивном режиме. Мы сидели в соседней комнате и наблюдали, как люди, проходящие тестирование, работают с приложением. Скажем, мы заметили, что респонденты реагируют на кнопку «Найти друзей» не так, как задумывалось: тогда мы сразу открывали Fireworks и быстренько меняли «Найти друзей» на «Хорошо». Следующим участникам теста мы предлагали уже новый прототип и смотрели, насколько быстрее они реагируют. Если теория работала — так и оставляли.
Этот этап тестирования позволяет понять, насколько правильно пиктограммы воспринимаются пользователем. Вообще я не большой приверженец пиктограмм и иконок. Считаю, что гораздо лучше написать словами (кстати, судя по всему, при работе над iOS 7 тоже отталкивались от этого, там все, в основном, стало на словах).
Нас особенно интересовала понятность для пользователей двух метафор. Первая — круг. Если вы посмотрите предыдущие слайды, то в Navigation bar у нас 3 кнопки: стандартный bubble (диалоги), плюс (добавление новой записи), и, собственно, кружок, который родился из концепции будущего логотипа. Когда-то у нас была идея концептуального лого: круг как ореол планеты. Эта метафора, в итоге, перетекла внутрь приложения и стала использоваться для обозначения уведомлений. Что самое удивительное, как только уведомление приходило, все пользователи понимали, что скрывается за этой иконкой.
Вторая метафора, которая нас интересовала — бриллиант. За ним скрывалось автоулучшение фотографий. Как выяснилось, эту метафору пользователи не распознавали; мы оставили бриллиант, но добавили подсказку: когда на него нажимаешь, появляется сообщение «Фото улучшено».
Еще один момент, который прояснили юзабилити-тесты — расположение аватаров в записи, которую прокомментировал другой человек. Сначала у нас была идея, согласно которой не стоит располагать два аватара близко друг к другу, потому что это тяжело для восприятия, и мы поместили комментатора прямо под событием.
На бумаге было все хорошо. Но когда мы показали это пользователям, они эту версию не поняли, зато выбрали как раз тот вариант, когда два аватара находятся рядом.
Время собирать камни
И вот релиз, время собирать камни. То есть отзывы из App Store, Google Play и других источников. Когда видишь комментарий «вообще, где ваш экран настроек?», самое время призадуматься. Если это один отзыв (пользователь поставил нашему приложению всего лишь «двойку»), то его, в принципе, можно пропустить мимо ушей. Но если их несколько, то ты где-то явно ошибся.
Наше приложение в целом было хорошо встречено пользователями. В AppStore и Google Play оно получило в среднем по 4 балла. Часть отзывов, которые мы получили сразу после обновления, касались уведомления о предложении дружбы, где пользователь не мог перейти на страничку предлагающего. Это было исправлено. Другим недочётом оказались трудности с удалением и очищением сообщений, за это пользователи поставили нашему приложению 4 балла. В итоге мы просто добавили шестеренку, которая стала метафорой таких настроек в диалоге.
Работа над этим приложением еще раз подтвердила важность целого ряда этапов в проектировании и создании приложений: структурной проработки и пользовательских сценариев, «бумажного» дизайна, анализа ошибок и удачных находок конкурентов. Мы получили богатый опыт решения проблем с анимацией и шрифтами на разных платформах, а также собрали много данных о реальном поведении пользователей при тестировании готового приложения.
Делитесь своим опытом подобных квестов в комментариях!
Сценарии для сайтов и приложений
Как написать пользовательский сценарий?
Во-первых, стоит сказать, что интерфейс – не для заказчика, и не для вас. Интерфейс для человека, который будет им пользоваться и иногда бывает так, что сделанная вами работа нравится только вам и через пару часов или дней и это ощущение проходит. То есть картинки по началу нравились, потому что вы влюблены в проект, но ощущение пропадает, потому что вы спустя какое-то время начинаете уже менее влюбленно на него смотреть и понимаете, что за ним нет никакого смысла, пользы, а проста пустота, картинки и ничего больше.
Сценарий–это сжатое описание способов применения интерфейса для достижения цели. Сценарий нужен, чтобы сформулировать тот стержень, который будет в вашем продукте.
Из чего состоит сценарий:
Не буду рассказывать теорию, я об этом рассказываю в курсе. Сейчас просто на конкретном примере я поясню и расскажу как пишется сценарий.
Во-первых, на примере приложения для РЖД(рис.1)
Цель этого приложения — попасть на поезд без бумажного билета.
Рис.1 Приложение РЖД
Все начинается с того, что человек просто покупает билет на сайте РЖД (рис.2).
Следующим шагом пользователь должен увидеть эту поездку в приложении (рис.3). Он видит активные элементы, с датами, городом и временем.
Дальше на человек на вокзале должен найти свой поезд, путь и вагон (рис.4). Видно поезд, время, путь (определяется непосредственно на вокзале), вагон, место. То есть человеку не нужно распечатывать и доставать бумажные билеты и вся информация, которая ему нужна в данной ситуации видна на экране.
Рис. 5 Альтернативный сценарий
Во-вторых, может быть альтернативный сценарий (рис.5). Человек может захотеть вызвать такси до вокзала и здесь есть ссылка на такси. И может получить push-уведомление, чтобы не пропустить поезд за какое-то время.
Рис.6 Шаг четвертый
Дальше, следующий шаг по основному сценарию. Человек у вагона может показать проводнице штрих-код, чтобы проводница прямо с экрана телефона может считать этот штрих-код, провести идентификацию и пропустить человека дальше в поезд.
Дальше мы уже в поезде. Человек может найти свое место в поезде.На последнем экране, что важно (рис.7).
Есть альтернативный сценарий (рис.8). То есть мы заботимся о человеке больше и думаем не только о том, как ему добраться до дома, т.к. это его конечная цель, в свою квартиру, отель и т.д. И мы даем альтернативный сценарий: сообщить по смс друзьям,родственникам, что все ок и где, во сколько будет встреча. Можно вызвать такси с вокзала. И подключить вайфай. То есть заботимся о человеке чуть больше, делая следующий шаг. И даем ему с комфортном добраться домой (рис.9).
Здесь (рис.9) немного деталей, некоторый вещи можно еще глубже детализировать (каждый альтернативный сценарий,например). Сценарий не должен быть громадным и подробным, необходимо помнить про ключевые точки. Помнить о контексте, откуда человек попадает в приложение, где она находится в данный момент, в какой ситуации. Наше приложение не кончается на поиске места в вагоне, а помнит о следующем шаге.
Сценарий –стратегия. Описывайте ключевые точки процесса глобально, от начала до конца.
Для отправки комментария вам необходимо авторизоваться.
Во-первых, стоит сказать, что интерфейс – не для заказчика, и не для вас. Интерфейс для человека, который будет им пользоваться и иногда бывает так, что сделанная вами работа нравится только вам и через пару часов или дней и это ощущение проходит. То есть картинки по началу нравились, потому что вы влюблены в проект, но ощущение пропадает, потому что вы спустя какое-то время начинаете уже менее влюбленно на него смотреть и понимаете, что за ним нет никакого смысла, пользы, а проста пустота, картинки и ничего больше.
Сценарий–это сжатое описание способов применения интерфейса для достижения цели. Сценарий нужен, чтобы сформулировать тот стержень, который будет в вашем продукте.
Из чего состоит сценарий:
Не буду рассказывать теорию, я об этом рассказываю в курсе. Сейчас просто на конкретном примере я поясню и расскажу как пишется сценарий.
Во-первых, на примере приложения для РЖД(рис.1)
Цель этого приложения — попасть на поезд без бумажного билета.
Рис.1 Приложение РЖД
Все начинается с того, что человек просто покупает билет на сайте РЖД (рис.2).
Следующим шагом пользователь должен увидеть эту поездку в приложении (рис.3). Он видит активные элементы, с датами, городом и временем.
Дальше на человек на вокзале должен найти свой поезд, путь и вагон (рис.4). Видно поезд, время, путь (определяется непосредственно на вокзале), вагон, место. То есть человеку не нужно распечатывать и доставать бумажные билеты и вся информация, которая ему нужна в данной ситуации видна на экране.
Рис. 5 Альтернативный сценарий
Во-вторых, может быть альтернативный сценарий (рис.5). Человек может захотеть вызвать такси до вокзала и здесь есть ссылка на такси. И может получить push-уведомление, чтобы не пропустить поезд за какое-то время.
Рис.6 Шаг четвертый
Дальше, следующий шаг по основному сценарию. Человек у вагона может показать проводнице штрих-код, чтобы проводница прямо с экрана телефона может считать этот штрих-код, провести идентификацию и пропустить человека дальше в поезд.
Дальше мы уже в поезде. Человек может найти свое место в поезде.На последнем экране, что важно (рис.7).
Есть альтернативный сценарий (рис.8). То есть мы заботимся о человеке больше и думаем не только о том, как ему добраться до дома, т.к. это его конечная цель, в свою квартиру, отель и т.д. И мы даем альтернативный сценарий: сообщить по смс друзьям,родственникам, что все ок и где, во сколько будет встреча. Можно вызвать такси с вокзала. И подключить вайфай. То есть заботимся о человеке чуть больше, делая следующий шаг. И даем ему с комфортном добраться домой (рис.9).
Здесь (рис.9) немного деталей, некоторый вещи можно еще глубже детализировать (каждый альтернативный сценарий,например). Сценарий не должен быть громадным и подробным, необходимо помнить про ключевые точки. Помнить о контексте, откуда человек попадает в приложение, где она находится в данный момент, в какой ситуации. Наше приложение не кончается на поиске места в вагоне, а помнит о следующем шаге.
Сценарий –стратегия. Описывайте ключевые точки процесса глобально, от начала до конца.