В предыдущей статье "Процесс проектирования приложений для Windows Phone" мы обсуждали важность определения темы вашего приложения для Windows Phone. Этап идей поможет вам усовершенствовать вашу тему и генерировать идеи, которые помогут улучшить пользовательское взаимодействие для этой темы. Мы говорили о выборе в качестве темы пользовательского опыта, такого как обед, бег или плавание, вместо мыслей о приложениях с точки зрения API или RSS-каналов, доступных извне.
Формирование идей и концепции — это весёлый этап и в него лучше всего играть с другими людьми! — Есть три основных этапа в фазе формирования идей и концепции: 1) мозговой штурм 2) исследование и 3) закрепление. В двух словах, на этапе мозгового штурма вы создаете тонны идей, на этапе исследования вы препарируете и изучаете многие из этих идей (но не все), а на этапе закрепления вы решаете, какие идеи пойдут вперед, чтобы стать частью вашего приложения. Только некоторые из них делают его живым.
![image](https://habrastorage.org/r/w1560/storage2/6af/801/3f3/6af8013f3b3ebf303918e1d6494a4159.png)
Мозговой штурм, как правило, является первым этапом при проектировании приложения для Windows Phone (или проектирования чего-либо из этой области). Этот этап — полная свобода мысли. Речь идёт о придумывании тонны идей, даже если некоторые из них более сумасшедшие, чем другие. Речь идёт о нестандартном мышлении, чтобы придумать инновационные решения.
Лучший инструмент для мозгового штурма — это рассказывание историй и огромное количество разноцветных стикеров для заметок, хотя эскизы и moodboards тоже помогут. Начнём с того, что эта статья имеет 10 действительно хороших советов для эффективного мозгового штурма.
В основном вы будете использовать мозговой штурм, чтобы определить две вещи: 1) общую идею для вашего приложения, а затем 2) возможности для вашего приложения.
Мозговой штурм может помочь вам придумать интересные идеи приложений для Windows Phone, которые обеспечивают уникальную ценность для пользователя и выделяются среди других приложений в Marketplace. После того как вы определили общую цель вашего приложения, мозговой штурм может помочь вам создавать и исследовать конкретные идеи (возможности) для вашего приложения.
Во-первых, вам понадобится тема или основной (общий) пользовательский сценарий(и) для решения. Один из типичных, который мы здесь видим — это почти инстинктивный подход «создания приложения только потому, что есть API и веб-сервис, доступный извне». Таким образом, в итоге мы имеем десятки клиентов Yelp!, Twitter или Foursquare. Хотя нет ничего плохого в попытке создать лучший клиент для любого из этих сервисов, реальная возможность вводить новшества находится путем мышления с точки зрения пользовательского опыта, а не API, или веб-сервисов. Таким образом, вместо того, чтобы сказать "Я создам приложение основанное на API Yelp!", говорите:"Я создам приложение, чтобы помочь пользователю получить обеденный опыт". Решите, что пользовательский опыт, который вы хотите получить в вашем приложении, будет частью и на основе вашей деятельности, ваших личных предпочтений, хобби, или того, что вы слышите, что люди действительно хотят. Вы увидите, что самыми успешными клиентами Twitter (Seesmic) или Foursquare (4th and Mayor) являются те, которые думают вне рамок API.
Другой распространенный подход, который мы видим на данном этапе у некоторых людей — поддержка себя самого с самого начала. Например, они начинают этап идей, зная что они будут создавать приложение "для проверки цен акций". Таким образом, мы в конечном итоге имеем ещё одно приложение биржевых котировок или другое приложение для чтения RSS-потока. Ключом к придумыванию хороших и оригинальных идей для приложений является мысль о пользовательском опыте. Таким образом, вместо того чтобы думать "Я создам приложение для торговли на рынке ценных бумаг", думайте "Я исследую, как помочь пользователю в опыте торговли на рынке ценных бумаг" — ах! Это гораздо шире, дает вам больше возможностей, чтобы придумать способы внести свой вклад в опыт.
Мощной техникой мозгового штурма для выполнения такого рода подхода к генерации идей для приложений Windows Phone является техника «субъекты + глаголы + объекты». Я помню, мы занимались этим ещё в школе архитектуры и это было весело! В прошлом году мы начали использовать его также для разработки пользовательского интерфейса.
Мы применяли эту групповую технику мозгового штурма во время тура Windows Phone Design Day. Она состоит в наличии группы людей, которые пишут кучу слов — субъектов, глаголов и объектов, связанных с пользовательским интерфейсом, затем выбираются некоторые из этих слов для создания нового сценария. Это упражнение воспламеняет творчество, потому что оно заставляет вас найти решение сценариев, основанных на словах, которые вы не писали сами себе — сценариях, которые бы вы никогда не придумали себе, если бы не было коллективного сознания группы.
— Возьмите несколько разноцветных стикеров и маркеры. Предпочтительно все маркеры должны иметь одинаковую толщину линии и одинаковый цвет (чёрный).
— Возьмите 3 разноцветных стикера и напишите слово субъекты на первом, объекты на втором и глаголы на третьем.
— Прилепите 3 этих стикера на большой стене.
— К этому моменту вы должны иметь определенные темы вашего приложения для Windows Phone — не забудьте подумать о пользовательском опыте, например таком как обед, парусный спорт или разработка (без конкретного решения на этот раз). Мы будем использовать опыт обеда (еда в ресторане) в этом примере.
— Попросите участников написать один субъект, один глагол и один объект, связанные с процессом и опытом «обеда». Одно слово для каждого, на отдельном стикере и прилепите их под стикерами с заголовками, первоначально созданные вами.
— Это позволит заполнить стену кучей субъектов, глаголов и объектов, связанных с опытом обеда (или любой другой темой, которую вы и ваша команда выбрали, например такую как бег, плавание…)
![](https://habrastorage.org/r/w780q1/storage2/5e9/e84/efa/5e9e84efa070253c31e17d03edf88a2a.jpg)
— Следующий шаг заключается в разделении группы на более мелкие команды по 2 или 3 человека (или 1, если членов команды мало) и попросить их выбрать 3 слова, которые нравятся команде: один субъект, один глагол, один объект. Попросите их выбрать слова, которые рождают идеи и включают воображение для пользовательских сценариев. Некоторые команды будут спорить, согласовывая какие слова выбрать. Выход здесь — дать каждому члену команды выбрать одно слово, чтобы они в конечном итоге имели один субъект, глагол и один объект. На самом деле можно назначить случайный набор слов каждой команде — это заставит их мыслить нестандартно и придумать уникальный пользовательский сценарий приложения для решения.
— Как только команды выбрали свои 3 слова, они готовы приступить к генерации идей о том, как решить или исполнить сценарий, который волшебным образом появляется, выбрав случайный субъект, глагол и объект. Например:
— подруга вегетарианка + кричать + двойной чизбургер
— дети + играть + еда
— повар + готовить (еду) + помидоры
— дедушка (бабушка) + предлагать + квитанция
— Леди Гага + встречаться + посуда
— Затем участники должны придумать сценарии, которые вдохновляют на эти 3 слова, например, Леди Гага + встречаться + посуда… Мы знаем, что не будем разрабатывать приложения Windows Phone специально для Леди Гага, верно? Просто если мы не большие поклонники, мы не будем создавать приложения сосредоточеные конкретно на Леди Гага, но что, если мы трансформируем Леди Гага в более широкое понятие, такое как «Известные личности». Итак, знаменитые личности встречаются с посудой. Что если мы создадим приложение для отслеживания личностей, которые посещают различные места для обеда или ужина? Там могут быть карты и личности и, когда пользователи обнаружат кого-то известного, то отметят этого человека. Я не говорю о приложении для папарацци, но о приложении которое даёт пользователю возможность представить, что он столкнётся с его любимой актрисой или хип-хоп рэппером, если он идёт на ужин или обед в место X или Y. Задействуйте возможности Foursquare и Yelp, и у вас есть некоторые хорошие API для поддержки вашего пользовательского опыта. Это просто идея. Важно поощрять участников не стесняться воспринимать слова буквально, но экстраполировать на все смыслы, как в случае с Леди Гага, которую мы расширили до известной личности или глагол «кричать», который может быть расширен до «быть расстроенным вцелом» или «наличие проблемы». Эта идея появления личности в ресторанах такова, что я никогда бы не придумал ее сам, если бы не эти слова, которые некоторые люди в моей группе записали на этих стикерах.
Вот еще один пример из трех слов, который на самом деле привлек мое внимание: дети + играть + еда. Я никогда бы не придумал этот сценарий сам — у меня нет детей, но благодаря 3-м различным людям, которые написали эти слова, теперь у меня есть сценарий, чтобы над ним работать. Дети играют с едой в ресторане — это может быть реальной проблемой. Как мы можем помочь в решении этого сценария?
Некоторые методы описаны в книге Игровой штурм, которые могут быть полезными. Вот один пример с использованием техники мозгового штурма, называющейся невозможный сценарий. Помните, что это игры, так что если вы отнесетесь к этому слишком серьезно, то вы далеко не уйдете, просто не нужно думать о том как вы будете создавать приложение или какая внутренняя архитектура сервера необходима. Просто получайте удовольствие. На последующих этапах вы будете иметь достаточно времени, чтобы выставить приоритеты, изучить технические возможности и разобраться с идеями. А сейчас играйте в эту игру с вашей командой.
Мать и отец, возможно, 2 или 3 детей, которые играют с едой, и это проблема, но невозможным сценарием будет такая же пара, имеющая 100 детей! Невозможно, не так ли? (Я думаю...) что бы вы сделали, как родитель ста детей, которые играют с едой, беря их в ресторан? Звучит как ночной кошмар — вы должны знать все их имена, их предпочтения, которым они следуют, кто из них вегетарианец, их возрастные группы? Кто из них ведёт себя наилучшим образом, кто наихудшим? И т.д. Как заботливый родитель 100 детей вы бы знали эти вещи, просто это невозможный сценарий. Теперь верните его в реальность: в то время как это не представляется возможным для родителя, чтобы взять её/его 100 детей в ресторан, это действительно возможно иметь 100 детей (у различных родителей) в простом ресторане или другом публичном месте, таком как музей — узнайте в McDonalds или Chucky Cheese (сеть детских ресторанов в США — прим. перев.)! Теперь переведите весь ваш «опыт изучения» как родитель ста детей и используйте его для менеджера ресторана или для самого ресторана. Как бы ресторан мог помочь этим ста детям (или их родителям) не играть с едой и не вносить беспорядок в это место? Что, если приложение является спонсором социальной активности в ресторанах, своего рода мини социальным средством массовой информации для родителей, дает возможность встретиться и дать детям поиграть вместе на мероприятии или просто дать детям узнать о других детских субкультурах, основанных на других детях, которые участвуют в этом мероприятии?
![](https://habrastorage.org/r/w1560/storage2/a8d/4ab/d7c/a8d4abd7cc9df25e2b026d3895c64d50.png)
Другой способ проверить ваши субъект + глагол + объект — это альтернативный мир, где бы вы сказали что-то вроде «а что если в ресторане на Луне?». Что будет с фрикаделькой, брошеной ребёнком? Я представляю фрикадельку, летящую через весь ресторан, попадающую в сварливого старика на другой стороне! Это дало мне идею… Что, если ваше приложение становится реальной игрой, где дети могут устраивать беспорядок, который они хотят? С фактической едой из данного ресторана? Как насчёт бросать маленькие Биг Маки или Макнаггетсы. Если уже существует Fruit Ninja, то почему бы не сделать Messy Food (беспорядок с едой, бедлам в ресторане). Это заставляет меня думать, что будет если Angry Birds встретятся с Fruit Ninja и Cooking Mama.
Ещё один метод — это чужие образы. Здесь вы должны представить, что вы кто-то или что-то в столовом опыте. Конечно, вы можете выступать в качестве официанта и открыть для себя незабываемый опыт с его/ее точки зрения. Это поможет вам открыть своему уму сценарии, о которых вы бы иначе не подумали. Разрешите вам и вашей команде думать с совершенно иной точки зрения. Теперь вместо того, чтобы считать что вы человек, думайте, что вы тарелка макарон. Думайте как вы добрались до ресторана, из каких ингридиентов вы сделаны, как вы были приготовлены, сервированы, съедены. Это также предоставит вам незабываемый опыт с точки зрения, с которой вы не могли подумать раньше. Означает ли это, что мы будем создавать приложения для тарелок макарон? Не обязательно… Но изучение жизненного цикла макарон научит вас больше тому, что происходит за прилавком, на кухне, с запасами или хранилищем (складом) в ресторане, и я уверен, что будут открыты новые идеи для приложений.
![](https://habrastorage.org/r/w1560/storage2/4d7/d86/0e6/4d7d860e62004ee9167a1315f2f8091d.png)
Очень отличительный подход думать сначала о наличии API, не так ли? :) API, веб-сервисы и все эти вкусности должны быть просто инструментами, которые помогут вашему приложению способствовать тому, чтобы сделать пользовательский опыт лучше.
Есть некоторые основные книги по мозговому штурму, такие как Игровой штурм и Тинкертой. Они имеют свойство быть более нацеленными на метод мозгового штурма для маркетинговых/бизнес-групп (на мой взгляд), но вы можете адаптировать некоторые из этих методов также для группы проектирования.
Поиграйте в эти действа (игра — это лишь условное название) с вашими напарниками по команде или с друзьями и семьей, если вы являетесь независимым разработчиком. Это игры для придумывания идей. Вы не должны быть слишком серьезными на этом этапе. Всё будет серьезно на ближайших нескольких этапах.
В конце вы можете представить свои идеи вашей команде (или друзьям), используя Печа Куча (или Чит Чат на японском языке) – модель презентации, в которой у вас есть 20 слайдов и 20 секунд на слайд, чтобы представить краткий обзор ваших идей. Это замечательная модель, так как она заставляет удалить мусор и шум и оставить только лучшие идеи. Это также заставит вас начать «спускать» эти сумасшедшие идеи на землю.
![](https://habrastorage.org/r/w780q1/storage2/20e/05b/983/20e05b9834211a5346bb6733ea77502b.jpg)
На этом этапе вы и ваша команда изучаете практическую целесообразность (бизнес), привлекательность (опыт) и жизнеспособность (технология) этих идей, которые вы придумали во время стадии мозгового штурма. Я остановлюсь на опыте в этой статье, так как я уверен, что если вы являетесь разработчиком или продукт/маркетинг-менеджером, читая этот пост вы будете знать гораздо больше о том, как изучить техническую жизнеспособность идей.
Когда дело доходит до исследования, целью является взять некоторые идеи, возникшие во время мозгового штурма и разделить, растянуть и проверить их. Вы можете сделать это с помощью некоторых из следующих инструментов:
Эскизы
Раскадровки
Прототипы
Рассказывание историй
Как упоминалось ранее, проектирование не одномоментный вид деятельности — не вид деятельности «в одну попытку». Проектирование представляет собой процесс, в котором мы берем бесформенные куски концепции и идеи, и начинаем работать с ними, изучать их и обращаться с ними как с глиной. Постепенно мы узнаем эти идеи лучше, приходя к тому, что всё это начинает принимать определенную форму. Эскизы, раскадровки, прототипы (фокусируясь на бумажных прототипах на этом этапе формирования идей) и рассказывание историй являются инструментами любого творческого человека, которые позволяют исследовать идею.
«Скульптуры просто заключены внутри мраморного блока, и задача художника освободить их, удалив избыток камня» — Микеланджело
![](https://habrastorage.org/r/w780q1/storage2/1bb/872/7b0/1bb8727b0b7ca5d7796bb1f7d312a079.jpg)
Техника боксерской перчатки показывает именно то, что эскиз это всё, в частности во время этой стадии исследования. Вам не нужно становиться художником, передавая свои идеи в эскизах. На самом деле в начале фазы эскизов он работает даже лучше, являясь более абстрактным и общим с вашими ударами. Это то, что боксерская перчатка (или еще лучше, толстый карандаш или маркер) помогут вам сделать. Попробуйте следующее упражнение: возьмите черный маркер и стикер (один из самых маленьких) и попробуйте нарисовать полную панораму Windows Phone в нём. Размер бумаги и толщина линий сразу ограничивают вас от добавления деталей и это то, для чего нужны эскизы общего, не детализированного описания ваших идей.
![](https://habrastorage.org/r/w780q1/storage2/e30/ee9/4c4/e30ee94c45d5bb9f2c6bbc66b1dbef9d.jpg)
Эскиз: Мощный инструмент визуального мышления, автор Майк Род /Mike Rohde/ — это потрясающее статья об эскизах со многими отличными ссылками и ресурсами. Грязное искусство создания эскизов пользовательских интерфейсов, автор Пейтер Бьюик /Peiter Buick/ — это обязательная к прочтению статья о создании эскизов пользовательских интерфейсов с большим количеством практических методов.
Это отличная серия статей с советами по созданию эскизов от Андерса Токсбо /Anders Toxboe/:
Создание эскизов пользовательского интерфейса, совет №1: Рисование прямоугольников и углов
Создание эскизов пользовательского интерфейса, совет №2: Нанесение тени
Создание эскизов пользовательского интерфейса, совет №3: Использование толстой ручки
Создание эскизов пользовательского интерфейса, совет №4: Уберите руки от бумаги
Создание эскизов пользовательского интерфейса, совет №5: Ограничьте себя
Наконец, это 50 ресурсов об эскизах для дизайнеров пользовательских интерфейсов – там есть некоторе интересные статьи, видео и презентации для тех, кто хочет углубиться в эскизы.
Бумажное прототипирование буквально означает использование бумаги для построения «интерактивного» (я бы даже сказал «управляемого») опыта взаимодействия. Вы можете подготовить бумажный прототип, делая эскизы на бумаге. Для приложений Windows Phone можно набросать все это на прямоугольных листках бумаги. Лично я использовал для эскизов панорам, сводных страниц и страниц стикеры 3''x5'' (7,5х22,5 см). Это здорово, потому что вы можете приклеить некоторые стикеры рядом друг с другом и расположить панорамы с 4 — 6 панелями, или сводные страницы с 3 — 6 разделами. Если вы выполняете пользовательское тестирование ваших прототипов, то вы можете оформить презентацию немного крупнее и сделать эскиз в размер страницы письма (Letter). Как сделать объекты интерактивными? Ну, буквально сделать эскиз, из различных экранов и модулей пользовательского интерфейса, которые будут отображаться или изменяться, когда пользователь «взаимодействует» с ними. В этом управляемом прототипе вы должны помочь пользователю, делая вставки, удаления, изменения части бумажного прототипа в зависимости от того, что пользователь хочет сделать. Это отличный способ начать тестирование концепции достаточно рано, и это дешево, не потому что это бумага, а потому, что за 15-60 минут вы можете создать хороший бумажный прототип, а затем инвестировать часы, дни или недели, создавая интерактивность. Помните, в этот момент мы все еще находимся в технике формирования идей, и мы по-прежнему придаём форму «бесформенным кускам идей».
Еще одним способом создания бумажных прототипов является то, что я узнал от Джареда Поттера /Jared Potter/ — Sr. Design Integrator в дизайн-студии. Он делает эскизы панорам, сводных страниц, страниц, а затем делает их фотоснимки со своего телефона. Потом он отправляет эти фотографии себе по электронной почте и импортирует их в Expression Blend (вы также можете использовать Powerpoint...). В Expression Blend он создает кнопки поверх эскизов, по областям, где он рисовал интерактивные элементы, такие как кнопки, кнопки панели приложения (AppBar), элементы списка. Затем он создает взаимодействие (Behaviors) для того, чтобы кнопки приводили его на другие экраны (другие эскизы). Через 15 минут он имеет полный бумажный прототип (интерактивный), работающий в Blend и он готов для начала тестирования некоторых из его идей. Это своего рода гибрид бумажной и цифровой техник прототипирования, но так же дешёвый (учитывая, что вы можете использовать Blend, PowerPoint или аналоги).
Бумажное прототипирование – автор Шон Медеро/ Shawn Medero / — это отличный материал для прочтения с теоретическими и практическими советами. Создание бумажных схем экранов еще один хороший материал для прочтения. Обратите внимание, в данном случае автор объясняет технику, которая использует предварительно созданные элементы пользовательского интерфейса каркасного исполнения. Они печатаются, а потом из них составляется пользовательский интерфейс. Это всё ещё бумажные прототипы, хотя эскизы не создают с помощью ручки/карандаша — вместо этого используют предварительно созданные элементы управления пользовательского интерфейса и шаблоны. Должен ли я создать некоторые из этих шаблонов элементов управления пользовательского интерфейса для Windows Phone? Хорошо, сделаем.
Это 3 больших статьи о теории бумажного прототипирования – не так много практических советов, но приятно читать, чтобы понять значение создания грубых прототипов:
Бумажные прототипы: всё ещё наши любимые
Оглядываясь назад на 16 лет бумажного прототипирования
Использование бумажных прототипов для управления рисками
Некоторые люди (включая меня) утверждают, что это самый важный из инструментов для формирования идей. Рассказывание историй действительно имеет фундаментальное значение для всего процесса проектирования пользовательского интерфейса. Рассказывание историй позволяет вам передать сценарии и описать пользователей, проблемы и решения таким образом, который имеет смысл, что привлекает людей и позволяет им погрузиться в мир будущего, где существует ваше приложение. Это не только поможет вам и вашим товарищам по команде и клиентам понять ваше видение приложения, но это помогает углубиться в приложение и сделать его более интересным. Хороший рассказ истории — это также то, что делает ваше приложение готовым к продажам… продажам инвесторам, товарищам по команде, клиентам и пользователям. Плоско рассказанная история даст плоское приложение. Структурированное и увлекательное повествование обычно отражает приложения, которые являются уникальными.
Хороший способ объяснить значение рассказывания историй в дизайне пользовательского опыта словами:
«Рассказывание историй обычно начинается со вступления „Однажды…“, затем рассказчик делает небольшую паузу, чтобы собраться с мыслями. Традиционные вступления, из которых множество (часто с ответами из зала), были „ритуалами“, что служило сигналом о том, что рассказчик приостановил „время и пространство“, как мы это знаем, и перемещало зрителей в мир воображения и игры. „- Барри Мак-Вильямс /Barry McWilliams/
“Как показывает опыт, теперь охватывая несколько средств массовой информации, каналов и форматов, мы должны смотреть на повествование, взаимодействие, эмоциональные элементы для поддержания переходов через каналы и форматы» — Джо Ламантиa /Joe Lamantia/, семинар Beyond Findability на IA Summit 09
«Чтобы создать по-настоящему запоминающийся и удовлетворительный результат, дизайнеру пользовательского опыта необходимо понять, как создать логическую и жизнеспособную структуру для опыта и потребностей, чтобы понять те элементы, которые имеют важное значение для создания эмоциональной связи с пользователями продукта.» — Синди Честейн /Cindy Chastain/
«Если эмоции и смысл могут выйти из согласованности элементов, которые составляют историю, то для разработки оптимального опыта мы должны иметь рассказ, который согласует элементы продукта, сервисы или систему.» — Синди Честейн /Cindy Chastain/
Рассказывание историй является основой для любого другого способа коммуникации идей пользовательского опыта и пользовательского интерфейса. Истории можно рассказать с помощью голоса, в набросках, раскадровки, досках настроения (moodboards) и/или видео.
Рассказывание истории о пользовательском опыте не слишком отличается от написания сценариев фильмов или романов. Подобные элементы повествования существуют для разработчиков и дизайнеров для создания привлекательности и раскрытия подробностей о пользовательском опыте. Общими элементами повествования являются: тема, мир, персонаж(и), реквизиты (объекты), история (и) (место действия).
Тема является одной фразой, описывающей всё. Ваш фундамент. Ваша мантра. Фразой вы и ваша команда будете жить. Каждый сценарий, особенность, решение, которые вы берёте для нужд приложения должно проходить через фильтр темы — тематическую проверку. Мир это параметр, ландшафт, помещение, улица или в ключе цифрового опыта — это также экраны (разных размеров), или платформы, такие как телефоны, планшеты или даже Facebook, где происходит этот цифровой опыт. Персонажи являются субъектами или (персонами) или другими существами, участвующими в опыте.
Реквизиты (объекты) являются физическими или цифровыми активами, которые дополняют пользователя(ей) в их опыте. Истории определяют действия и отношения между субъектами и объектами.
В дополнение к элементам рассказа, структура также важна. Вы найдете различные форматы рассказа, имеющие несколько различных структур. Базовая структура рассказа состоит из: завязки, кульминации и развязки. Таким образом, при определении и рассказывании истории пользовательского опыта, следует начать с описания пользователей и их контекста. Вы можете установить их проблемы или цели, и, наконец, объяснить, как этот сценарий будет решен с помощью вашего приложения. Самый большой риск для историй в том, что они могут оказаться плоскими — вместо этого рассказывайте истории, которые имеют острые моменты откровения и моменты, в которые возможно всё кажется потеряным, и тогда придуманная вами особенность решает всё.
![](https://habrastorage.org/r/w1560/storage2/1b9/ecc/eb8/1b9ecceb8ef27ca0d3aed67ac9a7bf5f.png)
Вы можете высказать истории пользовательского опыта, записав их и с помощью своего рода визуальных средств таких, как эскизы в раскадровках и/или доски настроения (moodboards). Также отметим, что повествование в дизайне пользовательского опыта является многомерным смыслом, имеющим различные уровни опыта, для которых можно написать рассказ. Сначала вы можете написать полную историю верхнего уровня приложения. Наконец, вы можете написать истории для специфических особенностей.
Очень ценная техника, которую я узнал занимаясь маркетингом, это писать мини-истории, называемые «речь в лифте», основа которой состоит в том, чтобы быть в состоянии передать историю в 30 секунд или меньше. Если вы не можете описать ваше приложение, ваши основные области особенностей или специфическую особенность менее чем за 30 секунд, то скорее всего вы еще не овладели сценарием или особенностью, и вам нужно больше времени, чтобы изучить ее.
«Если вы не можете рассказать историю вашего приложения или специфической особенности в 140 символах, возможно вы нуждаетесь в более глубоком изучении, прежде чем продолжить процесс».
Ещё более эффективным методом, который я использую в последнее время, является описание вашего приложения, ваших основных областей или специфических особенностей в современных стандартах «речи в лифте»: статус в Facebook или твит в Twitter. Поэтому постарайтесь написать мини-рассказ (на самом деле нано-рассказ) в 420 символов для статуса в Facebook, а затем в 140 символов для Twitter. Если вы не можете описать своё приложение или особенность в этом ограниченном количестве символов, то как уже упоминалось, скорее всего, вы не можете до сих пор закрепить пользовательский опыт таким образом, чтобы больше не требовалось исследования. Если в команде возникает конфликт согласования для твита длинной истории, описывающей их приложение или особенности их приложения, то хорошо бы вернуться назад и поговорить больше о приложении или особенности, в поиске ключевых элементов способствуеющих пользовательскому опыту.
Вот несколько хороших описаний, которые я нашёл в Marketplace для Windows Phone:
CocktailFlow
Twitter: Обзор, поиск и открытие коктейлей с непрерывно растущей коллекцией напитков.
Facebook: Обзор, поиск и открытие коктейлей с непрерывно растущей коллекцией напитков. Приложение имеет красиво оформленные рецепты коктейлей и определяет, что может быть приготовлено из ингредиентов в баре. Он также дает советы о том, какие ингредиенты купить ещё, чтобы сделать дополнительные вкусные коктейли.
Seesmic
Twitter: Seesmic позволяет вам обновлять и просматривать одновременно несколько социальных сетей в эффективном и мощном приложении.
Facebook: Seesmic позволяет вам обновлять и просматривать одновременно несколько социальных сетей в эффективном и мощном приложении. Управление несколькими учетными записями Twitter, Facebook, Salesforce Chatter и систематизировать все ваши учётные записи, поисковые запросы, актуальные темы, и списки в вашем настраиваемом «пространстве» панели управления.
Темы опыта: элемент рассказа применительно к дизайну – это была потрясающая сессия, представленная Синди Честейн на IA Summit 2009 в Мемфисе. Она говорила о рассказывании историй для дизайнеров пользовательского опыта и разработчиков. Лучше писать через дизайн, написанная Браунвин Джонс /Brownwyn Jones/, это хорошая статья, которая даёт практические советы, чтобы лучше писать истории пользовательского опыта. Статья Использование историй для лучшего пользовательского опыта, написанная Уитни Квесенбери /Whitney Quesenbery/, объясняет использование личностей для написания историй, а также идей для сбора историй непосредственно от пользователей во время сессий тестирования. Вот презентация Уитни с заметками и слайдами. Не напрямую связано с дизайном пользовательского опыта, но я думаю, что эта статья О конфликтах и персонажах в структуре истории, которая была очень полезна для меня, чтобы понять основную структуру историй – структуру, которая может быть легко переведена на рассказывание историй о пользовательском опыте.
Во время этапа исследования вы неизбежно будете сталкиваться с конфликтом интересов, и люди будут влюбляться в свои идеи. Идеи, как дети и младенцы могут быть такими милыми, что вы не захотите отпустить их даже тогда, когда они представляют собой зло. Таким образом, научитесь обрубать канат и отпускать идеи, если они доказывают (и это ключевое слово здесь… доказывают), что они не оправданы. В то же время, охватывать некоторые идеи и отстаивать их любой ценой не менее важно. Без сильного вдохновителя в команде хорошая идея может слететь с трассы и затеряться навсегда. То, что мы хотим найти на протяжении всего нашего исследования является «свидетельством, которое доказывает» что это стоящая идея, или что это не так. В ходе этого процесса, идея будет развиваться и в конце вы многое узнаете о ней. Заметьте, это не время, чтобы сделать эту идею зрелой на 100%, но чтобы почувствовать насколько она осуществима. Я только что прочитал твит с цитатой Эда Кэтмала /Ed Catmull/ — президента Pixar: "Культура Pixar заключается в защите неоформленной идеи".
Если мозговой штурм — это всё о свободе, то закрепление — это всё о принятии решений, о получении ясности и о достижении консенсуса между различными точками зрения в команде. На данный момент командой будут изучены и узнаны куча идей в деталях. В этот момент будет легче для команды принимать решение какие из идей получат дальнейшее развитие и перейдут на следующие этапы. Хорошей техникой для этого момента является использование красных и зеленых точек или любой другой метод принудительного ранжирования. То, чего мы хотим добиться здесь — это устранение неоднозначности и наличие чёткого приоритетного списка сценариев, чтобы мы могли удалить те идеи, которые просто не имеют технического, делового потенциала и потенциала опыта.
Метод принудительного ранжирования заключается в том, чтобы дать людям $100 (условных) и попросить их положить столько долларов, сколько они пожелают, рядом с идеей/сценарием, который они считают, что следует продвигать и разрабатывать как часть приложения для Windows Phone. В руках у людей будет бюджет и на практике это заставит людей хорошо думать во что вкладывать свои «деньги». Некоторые люди могут сделать выбор, разделив свои инвестиции (голоса) на 5 частей – по $20 каждая. Другие будут тяготеть конкретной идеи и поставят $45 на неё, а остальные разделят на другие идеи. Некоторые могут разделить свои инвестиции на 100 частей! Но конечно же их «решение и сила влияния» будет сильно уменьшена.
В конце, в зависимости от результатов, определяется порог и убираются все идеи имеющие рейтинг ниже этого порога. Все остальные становятся приоритетным списком сценариев для вашего приложения, которые будут дополнительно изучены, чтобы превратить их в особенности. Готово! :)
![](https://habrastorage.org/r/w1560/storage2/b4c/2a1/dcb/b4c2a1dcb7432b6f5292f2dcc252b747.png)
Предыдущая статья | #2 Процесс проектирования приложений для Windows Phone
P.S. Другие материалы про Metro на русском языке собраны на MSDN в хабе «metro-дизайн»
Формирование идей и концепции — это весёлый этап и в него лучше всего играть с другими людьми! — Есть три основных этапа в фазе формирования идей и концепции: 1) мозговой штурм 2) исследование и 3) закрепление. В двух словах, на этапе мозгового штурма вы создаете тонны идей, на этапе исследования вы препарируете и изучаете многие из этих идей (но не все), а на этапе закрепления вы решаете, какие идеи пойдут вперед, чтобы стать частью вашего приложения. Только некоторые из них делают его живым.
![image](https://habrastorage.org/storage2/6af/801/3f3/6af8013f3b3ebf303918e1d6494a4159.png)
Мозговой штурм
Мозговой штурм, как правило, является первым этапом при проектировании приложения для Windows Phone (или проектирования чего-либо из этой области). Этот этап — полная свобода мысли. Речь идёт о придумывании тонны идей, даже если некоторые из них более сумасшедшие, чем другие. Речь идёт о нестандартном мышлении, чтобы придумать инновационные решения.
Лучший инструмент для мозгового штурма — это рассказывание историй и огромное количество разноцветных стикеров для заметок, хотя эскизы и moodboards тоже помогут. Начнём с того, что эта статья имеет 10 действительно хороших советов для эффективного мозгового штурма.
В основном вы будете использовать мозговой штурм, чтобы определить две вещи: 1) общую идею для вашего приложения, а затем 2) возможности для вашего приложения.
Мозговой штурм может помочь вам придумать интересные идеи приложений для Windows Phone, которые обеспечивают уникальную ценность для пользователя и выделяются среди других приложений в Marketplace. После того как вы определили общую цель вашего приложения, мозговой штурм может помочь вам создавать и исследовать конкретные идеи (возможности) для вашего приложения.
Во-первых, вам понадобится тема или основной (общий) пользовательский сценарий(и) для решения. Один из типичных, который мы здесь видим — это почти инстинктивный подход «создания приложения только потому, что есть API и веб-сервис, доступный извне». Таким образом, в итоге мы имеем десятки клиентов Yelp!, Twitter или Foursquare. Хотя нет ничего плохого в попытке создать лучший клиент для любого из этих сервисов, реальная возможность вводить новшества находится путем мышления с точки зрения пользовательского опыта, а не API, или веб-сервисов. Таким образом, вместо того, чтобы сказать "Я создам приложение основанное на API Yelp!", говорите:"Я создам приложение, чтобы помочь пользователю получить обеденный опыт". Решите, что пользовательский опыт, который вы хотите получить в вашем приложении, будет частью и на основе вашей деятельности, ваших личных предпочтений, хобби, или того, что вы слышите, что люди действительно хотят. Вы увидите, что самыми успешными клиентами Twitter (Seesmic) или Foursquare (4th and Mayor) являются те, которые думают вне рамок API.
Другой распространенный подход, который мы видим на данном этапе у некоторых людей — поддержка себя самого с самого начала. Например, они начинают этап идей, зная что они будут создавать приложение "для проверки цен акций". Таким образом, мы в конечном итоге имеем ещё одно приложение биржевых котировок или другое приложение для чтения RSS-потока. Ключом к придумыванию хороших и оригинальных идей для приложений является мысль о пользовательском опыте. Таким образом, вместо того чтобы думать "Я создам приложение для торговли на рынке ценных бумаг", думайте "Я исследую, как помочь пользователю в опыте торговли на рынке ценных бумаг" — ах! Это гораздо шире, дает вам больше возможностей, чтобы придумать способы внести свой вклад в опыт.
Мощной техникой мозгового штурма для выполнения такого рода подхода к генерации идей для приложений Windows Phone является техника «субъекты + глаголы + объекты». Я помню, мы занимались этим ещё в школе архитектуры и это было весело! В прошлом году мы начали использовать его также для разработки пользовательского интерфейса.
Субъекты + глаголы + объекты
Мы применяли эту групповую технику мозгового штурма во время тура Windows Phone Design Day. Она состоит в наличии группы людей, которые пишут кучу слов — субъектов, глаголов и объектов, связанных с пользовательским интерфейсом, затем выбираются некоторые из этих слов для создания нового сценария. Это упражнение воспламеняет творчество, потому что оно заставляет вас найти решение сценариев, основанных на словах, которые вы не писали сами себе — сценариях, которые бы вы никогда не придумали себе, если бы не было коллективного сознания группы.
— Возьмите несколько разноцветных стикеров и маркеры. Предпочтительно все маркеры должны иметь одинаковую толщину линии и одинаковый цвет (чёрный).
— Возьмите 3 разноцветных стикера и напишите слово субъекты на первом, объекты на втором и глаголы на третьем.
— Прилепите 3 этих стикера на большой стене.
— К этому моменту вы должны иметь определенные темы вашего приложения для Windows Phone — не забудьте подумать о пользовательском опыте, например таком как обед, парусный спорт или разработка (без конкретного решения на этот раз). Мы будем использовать опыт обеда (еда в ресторане) в этом примере.
— Попросите участников написать один субъект, один глагол и один объект, связанные с процессом и опытом «обеда». Одно слово для каждого, на отдельном стикере и прилепите их под стикерами с заголовками, первоначально созданные вами.
— Это позволит заполнить стену кучей субъектов, глаголов и объектов, связанных с опытом обеда (или любой другой темой, которую вы и ваша команда выбрали, например такую как бег, плавание…)
![](https://habrastorage.org/storage2/5e9/e84/efa/5e9e84efa070253c31e17d03edf88a2a.jpg)
— Следующий шаг заключается в разделении группы на более мелкие команды по 2 или 3 человека (или 1, если членов команды мало) и попросить их выбрать 3 слова, которые нравятся команде: один субъект, один глагол, один объект. Попросите их выбрать слова, которые рождают идеи и включают воображение для пользовательских сценариев. Некоторые команды будут спорить, согласовывая какие слова выбрать. Выход здесь — дать каждому члену команды выбрать одно слово, чтобы они в конечном итоге имели один субъект, глагол и один объект. На самом деле можно назначить случайный набор слов каждой команде — это заставит их мыслить нестандартно и придумать уникальный пользовательский сценарий приложения для решения.
— Как только команды выбрали свои 3 слова, они готовы приступить к генерации идей о том, как решить или исполнить сценарий, который волшебным образом появляется, выбрав случайный субъект, глагол и объект. Например:
— подруга вегетарианка + кричать + двойной чизбургер
— дети + играть + еда
— повар + готовить (еду) + помидоры
— дедушка (бабушка) + предлагать + квитанция
— Леди Гага + встречаться + посуда
— Затем участники должны придумать сценарии, которые вдохновляют на эти 3 слова, например, Леди Гага + встречаться + посуда… Мы знаем, что не будем разрабатывать приложения Windows Phone специально для Леди Гага, верно? Просто если мы не большие поклонники, мы не будем создавать приложения сосредоточеные конкретно на Леди Гага, но что, если мы трансформируем Леди Гага в более широкое понятие, такое как «Известные личности». Итак, знаменитые личности встречаются с посудой. Что если мы создадим приложение для отслеживания личностей, которые посещают различные места для обеда или ужина? Там могут быть карты и личности и, когда пользователи обнаружат кого-то известного, то отметят этого человека. Я не говорю о приложении для папарацци, но о приложении которое даёт пользователю возможность представить, что он столкнётся с его любимой актрисой или хип-хоп рэппером, если он идёт на ужин или обед в место X или Y. Задействуйте возможности Foursquare и Yelp, и у вас есть некоторые хорошие API для поддержки вашего пользовательского опыта. Это просто идея. Важно поощрять участников не стесняться воспринимать слова буквально, но экстраполировать на все смыслы, как в случае с Леди Гага, которую мы расширили до известной личности или глагол «кричать», который может быть расширен до «быть расстроенным вцелом» или «наличие проблемы». Эта идея появления личности в ресторанах такова, что я никогда бы не придумал ее сам, если бы не эти слова, которые некоторые люди в моей группе записали на этих стикерах.
Вот еще один пример из трех слов, который на самом деле привлек мое внимание: дети + играть + еда. Я никогда бы не придумал этот сценарий сам — у меня нет детей, но благодаря 3-м различным людям, которые написали эти слова, теперь у меня есть сценарий, чтобы над ним работать. Дети играют с едой в ресторане — это может быть реальной проблемой. Как мы можем помочь в решении этого сценария?
Некоторые методы описаны в книге Игровой штурм, которые могут быть полезными. Вот один пример с использованием техники мозгового штурма, называющейся невозможный сценарий. Помните, что это игры, так что если вы отнесетесь к этому слишком серьезно, то вы далеко не уйдете, просто не нужно думать о том как вы будете создавать приложение или какая внутренняя архитектура сервера необходима. Просто получайте удовольствие. На последующих этапах вы будете иметь достаточно времени, чтобы выставить приоритеты, изучить технические возможности и разобраться с идеями. А сейчас играйте в эту игру с вашей командой.
Невозможный сценарий для «дети + играть + еда»
Мать и отец, возможно, 2 или 3 детей, которые играют с едой, и это проблема, но невозможным сценарием будет такая же пара, имеющая 100 детей! Невозможно, не так ли? (Я думаю...) что бы вы сделали, как родитель ста детей, которые играют с едой, беря их в ресторан? Звучит как ночной кошмар — вы должны знать все их имена, их предпочтения, которым они следуют, кто из них вегетарианец, их возрастные группы? Кто из них ведёт себя наилучшим образом, кто наихудшим? И т.д. Как заботливый родитель 100 детей вы бы знали эти вещи, просто это невозможный сценарий. Теперь верните его в реальность: в то время как это не представляется возможным для родителя, чтобы взять её/его 100 детей в ресторан, это действительно возможно иметь 100 детей (у различных родителей) в простом ресторане или другом публичном месте, таком как музей — узнайте в McDonalds или Chucky Cheese (сеть детских ресторанов в США — прим. перев.)! Теперь переведите весь ваш «опыт изучения» как родитель ста детей и используйте его для менеджера ресторана или для самого ресторана. Как бы ресторан мог помочь этим ста детям (или их родителям) не играть с едой и не вносить беспорядок в это место? Что, если приложение является спонсором социальной активности в ресторанах, своего рода мини социальным средством массовой информации для родителей, дает возможность встретиться и дать детям поиграть вместе на мероприятии или просто дать детям узнать о других детских субкультурах, основанных на других детях, которые участвуют в этом мероприятии?
![](https://habrastorage.org/storage2/a8d/4ab/d7c/a8d4abd7cc9df25e2b026d3895c64d50.png)
Другой способ проверить ваши субъект + глагол + объект — это альтернативный мир, где бы вы сказали что-то вроде «а что если в ресторане на Луне?». Что будет с фрикаделькой, брошеной ребёнком? Я представляю фрикадельку, летящую через весь ресторан, попадающую в сварливого старика на другой стороне! Это дало мне идею… Что, если ваше приложение становится реальной игрой, где дети могут устраивать беспорядок, который они хотят? С фактической едой из данного ресторана? Как насчёт бросать маленькие Биг Маки или Макнаггетсы. Если уже существует Fruit Ninja, то почему бы не сделать Messy Food (беспорядок с едой, бедлам в ресторане). Это заставляет меня думать, что будет если Angry Birds встретятся с Fruit Ninja и Cooking Mama.
Ещё один метод — это чужие образы. Здесь вы должны представить, что вы кто-то или что-то в столовом опыте. Конечно, вы можете выступать в качестве официанта и открыть для себя незабываемый опыт с его/ее точки зрения. Это поможет вам открыть своему уму сценарии, о которых вы бы иначе не подумали. Разрешите вам и вашей команде думать с совершенно иной точки зрения. Теперь вместо того, чтобы считать что вы человек, думайте, что вы тарелка макарон. Думайте как вы добрались до ресторана, из каких ингридиентов вы сделаны, как вы были приготовлены, сервированы, съедены. Это также предоставит вам незабываемый опыт с точки зрения, с которой вы не могли подумать раньше. Означает ли это, что мы будем создавать приложения для тарелок макарон? Не обязательно… Но изучение жизненного цикла макарон научит вас больше тому, что происходит за прилавком, на кухне, с запасами или хранилищем (складом) в ресторане, и я уверен, что будут открыты новые идеи для приложений.
![](https://habrastorage.org/storage2/4d7/d86/0e6/4d7d860e62004ee9167a1315f2f8091d.png)
Очень отличительный подход думать сначала о наличии API, не так ли? :) API, веб-сервисы и все эти вкусности должны быть просто инструментами, которые помогут вашему приложению способствовать тому, чтобы сделать пользовательский опыт лучше.
Есть некоторые основные книги по мозговому штурму, такие как Игровой штурм и Тинкертой. Они имеют свойство быть более нацеленными на метод мозгового штурма для маркетинговых/бизнес-групп (на мой взгляд), но вы можете адаптировать некоторые из этих методов также для группы проектирования.
Поиграйте в эти действа (игра — это лишь условное название) с вашими напарниками по команде или с друзьями и семьей, если вы являетесь независимым разработчиком. Это игры для придумывания идей. Вы не должны быть слишком серьезными на этом этапе. Всё будет серьезно на ближайших нескольких этапах.
Печа Куча
В конце вы можете представить свои идеи вашей команде (или друзьям), используя Печа Куча (или Чит Чат на японском языке) – модель презентации, в которой у вас есть 20 слайдов и 20 секунд на слайд, чтобы представить краткий обзор ваших идей. Это замечательная модель, так как она заставляет удалить мусор и шум и оставить только лучшие идеи. Это также заставит вас начать «спускать» эти сумасшедшие идеи на землю.
![](https://habrastorage.org/storage2/20e/05b/983/20e05b9834211a5346bb6733ea77502b.jpg)
Исследование
На этом этапе вы и ваша команда изучаете практическую целесообразность (бизнес), привлекательность (опыт) и жизнеспособность (технология) этих идей, которые вы придумали во время стадии мозгового штурма. Я остановлюсь на опыте в этой статье, так как я уверен, что если вы являетесь разработчиком или продукт/маркетинг-менеджером, читая этот пост вы будете знать гораздо больше о том, как изучить техническую жизнеспособность идей.
Когда дело доходит до исследования, целью является взять некоторые идеи, возникшие во время мозгового штурма и разделить, растянуть и проверить их. Вы можете сделать это с помощью некоторых из следующих инструментов:
Эскизы
Раскадровки
Прототипы
Рассказывание историй
Как упоминалось ранее, проектирование не одномоментный вид деятельности — не вид деятельности «в одну попытку». Проектирование представляет собой процесс, в котором мы берем бесформенные куски концепции и идеи, и начинаем работать с ними, изучать их и обращаться с ними как с глиной. Постепенно мы узнаем эти идеи лучше, приходя к тому, что всё это начинает принимать определенную форму. Эскизы, раскадровки, прототипы (фокусируясь на бумажных прототипах на этом этапе формирования идей) и рассказывание историй являются инструментами любого творческого человека, которые позволяют исследовать идею.
«Скульптуры просто заключены внутри мраморного блока, и задача художника освободить их, удалив избыток камня» — Микеланджело
![](https://habrastorage.org/storage2/1bb/872/7b0/1bb8727b0b7ca5d7796bb1f7d312a079.jpg)
Эскизы и раскадровки
Техника боксерской перчатки показывает именно то, что эскиз это всё, в частности во время этой стадии исследования. Вам не нужно становиться художником, передавая свои идеи в эскизах. На самом деле в начале фазы эскизов он работает даже лучше, являясь более абстрактным и общим с вашими ударами. Это то, что боксерская перчатка (или еще лучше, толстый карандаш или маркер) помогут вам сделать. Попробуйте следующее упражнение: возьмите черный маркер и стикер (один из самых маленьких) и попробуйте нарисовать полную панораму Windows Phone в нём. Размер бумаги и толщина линий сразу ограничивают вас от добавления деталей и это то, для чего нужны эскизы общего, не детализированного описания ваших идей.
![](https://habrastorage.org/storage2/e30/ee9/4c4/e30ee94c45d5bb9f2c6bbc66b1dbef9d.jpg)
Эскиз: Мощный инструмент визуального мышления, автор Майк Род /Mike Rohde/ — это потрясающее статья об эскизах со многими отличными ссылками и ресурсами. Грязное искусство создания эскизов пользовательских интерфейсов, автор Пейтер Бьюик /Peiter Buick/ — это обязательная к прочтению статья о создании эскизов пользовательских интерфейсов с большим количеством практических методов.
Это отличная серия статей с советами по созданию эскизов от Андерса Токсбо /Anders Toxboe/:
Создание эскизов пользовательского интерфейса, совет №1: Рисование прямоугольников и углов
Создание эскизов пользовательского интерфейса, совет №2: Нанесение тени
Создание эскизов пользовательского интерфейса, совет №3: Использование толстой ручки
Создание эскизов пользовательского интерфейса, совет №4: Уберите руки от бумаги
Создание эскизов пользовательского интерфейса, совет №5: Ограничьте себя
Наконец, это 50 ресурсов об эскизах для дизайнеров пользовательских интерфейсов – там есть некоторе интересные статьи, видео и презентации для тех, кто хочет углубиться в эскизы.
Бумажное прототипирование
Бумажное прототипирование буквально означает использование бумаги для построения «интерактивного» (я бы даже сказал «управляемого») опыта взаимодействия. Вы можете подготовить бумажный прототип, делая эскизы на бумаге. Для приложений Windows Phone можно набросать все это на прямоугольных листках бумаги. Лично я использовал для эскизов панорам, сводных страниц и страниц стикеры 3''x5'' (7,5х22,5 см). Это здорово, потому что вы можете приклеить некоторые стикеры рядом друг с другом и расположить панорамы с 4 — 6 панелями, или сводные страницы с 3 — 6 разделами. Если вы выполняете пользовательское тестирование ваших прототипов, то вы можете оформить презентацию немного крупнее и сделать эскиз в размер страницы письма (Letter). Как сделать объекты интерактивными? Ну, буквально сделать эскиз, из различных экранов и модулей пользовательского интерфейса, которые будут отображаться или изменяться, когда пользователь «взаимодействует» с ними. В этом управляемом прототипе вы должны помочь пользователю, делая вставки, удаления, изменения части бумажного прототипа в зависимости от того, что пользователь хочет сделать. Это отличный способ начать тестирование концепции достаточно рано, и это дешево, не потому что это бумага, а потому, что за 15-60 минут вы можете создать хороший бумажный прототип, а затем инвестировать часы, дни или недели, создавая интерактивность. Помните, в этот момент мы все еще находимся в технике формирования идей, и мы по-прежнему придаём форму «бесформенным кускам идей».
Еще одним способом создания бумажных прототипов является то, что я узнал от Джареда Поттера /Jared Potter/ — Sr. Design Integrator в дизайн-студии. Он делает эскизы панорам, сводных страниц, страниц, а затем делает их фотоснимки со своего телефона. Потом он отправляет эти фотографии себе по электронной почте и импортирует их в Expression Blend (вы также можете использовать Powerpoint...). В Expression Blend он создает кнопки поверх эскизов, по областям, где он рисовал интерактивные элементы, такие как кнопки, кнопки панели приложения (AppBar), элементы списка. Затем он создает взаимодействие (Behaviors) для того, чтобы кнопки приводили его на другие экраны (другие эскизы). Через 15 минут он имеет полный бумажный прототип (интерактивный), работающий в Blend и он готов для начала тестирования некоторых из его идей. Это своего рода гибрид бумажной и цифровой техник прототипирования, но так же дешёвый (учитывая, что вы можете использовать Blend, PowerPoint или аналоги).
Бумажное прототипирование – автор Шон Медеро/ Shawn Medero / — это отличный материал для прочтения с теоретическими и практическими советами. Создание бумажных схем экранов еще один хороший материал для прочтения. Обратите внимание, в данном случае автор объясняет технику, которая использует предварительно созданные элементы пользовательского интерфейса каркасного исполнения. Они печатаются, а потом из них составляется пользовательский интерфейс. Это всё ещё бумажные прототипы, хотя эскизы не создают с помощью ручки/карандаша — вместо этого используют предварительно созданные элементы управления пользовательского интерфейса и шаблоны. Должен ли я создать некоторые из этих шаблонов элементов управления пользовательского интерфейса для Windows Phone? Хорошо, сделаем.
Это 3 больших статьи о теории бумажного прототипирования – не так много практических советов, но приятно читать, чтобы понять значение создания грубых прототипов:
Бумажные прототипы: всё ещё наши любимые
Оглядываясь назад на 16 лет бумажного прототипирования
Использование бумажных прототипов для управления рисками
Рассказывание историй
Некоторые люди (включая меня) утверждают, что это самый важный из инструментов для формирования идей. Рассказывание историй действительно имеет фундаментальное значение для всего процесса проектирования пользовательского интерфейса. Рассказывание историй позволяет вам передать сценарии и описать пользователей, проблемы и решения таким образом, который имеет смысл, что привлекает людей и позволяет им погрузиться в мир будущего, где существует ваше приложение. Это не только поможет вам и вашим товарищам по команде и клиентам понять ваше видение приложения, но это помогает углубиться в приложение и сделать его более интересным. Хороший рассказ истории — это также то, что делает ваше приложение готовым к продажам… продажам инвесторам, товарищам по команде, клиентам и пользователям. Плоско рассказанная история даст плоское приложение. Структурированное и увлекательное повествование обычно отражает приложения, которые являются уникальными.
Хороший способ объяснить значение рассказывания историй в дизайне пользовательского опыта словами:
«Рассказывание историй обычно начинается со вступления „Однажды…“, затем рассказчик делает небольшую паузу, чтобы собраться с мыслями. Традиционные вступления, из которых множество (часто с ответами из зала), были „ритуалами“, что служило сигналом о том, что рассказчик приостановил „время и пространство“, как мы это знаем, и перемещало зрителей в мир воображения и игры. „- Барри Мак-Вильямс /Barry McWilliams/
“Как показывает опыт, теперь охватывая несколько средств массовой информации, каналов и форматов, мы должны смотреть на повествование, взаимодействие, эмоциональные элементы для поддержания переходов через каналы и форматы» — Джо Ламантиa /Joe Lamantia/, семинар Beyond Findability на IA Summit 09
«Чтобы создать по-настоящему запоминающийся и удовлетворительный результат, дизайнеру пользовательского опыта необходимо понять, как создать логическую и жизнеспособную структуру для опыта и потребностей, чтобы понять те элементы, которые имеют важное значение для создания эмоциональной связи с пользователями продукта.» — Синди Честейн /Cindy Chastain/
«Если эмоции и смысл могут выйти из согласованности элементов, которые составляют историю, то для разработки оптимального опыта мы должны иметь рассказ, который согласует элементы продукта, сервисы или систему.» — Синди Честейн /Cindy Chastain/
Рассказывание историй является основой для любого другого способа коммуникации идей пользовательского опыта и пользовательского интерфейса. Истории можно рассказать с помощью голоса, в набросках, раскадровки, досках настроения (moodboards) и/или видео.
Рассказывание истории о пользовательском опыте не слишком отличается от написания сценариев фильмов или романов. Подобные элементы повествования существуют для разработчиков и дизайнеров для создания привлекательности и раскрытия подробностей о пользовательском опыте. Общими элементами повествования являются: тема, мир, персонаж(и), реквизиты (объекты), история (и) (место действия).
Тема является одной фразой, описывающей всё. Ваш фундамент. Ваша мантра. Фразой вы и ваша команда будете жить. Каждый сценарий, особенность, решение, которые вы берёте для нужд приложения должно проходить через фильтр темы — тематическую проверку. Мир это параметр, ландшафт, помещение, улица или в ключе цифрового опыта — это также экраны (разных размеров), или платформы, такие как телефоны, планшеты или даже Facebook, где происходит этот цифровой опыт. Персонажи являются субъектами или (персонами) или другими существами, участвующими в опыте.
Реквизиты (объекты) являются физическими или цифровыми активами, которые дополняют пользователя(ей) в их опыте. Истории определяют действия и отношения между субъектами и объектами.
В дополнение к элементам рассказа, структура также важна. Вы найдете различные форматы рассказа, имеющие несколько различных структур. Базовая структура рассказа состоит из: завязки, кульминации и развязки. Таким образом, при определении и рассказывании истории пользовательского опыта, следует начать с описания пользователей и их контекста. Вы можете установить их проблемы или цели, и, наконец, объяснить, как этот сценарий будет решен с помощью вашего приложения. Самый большой риск для историй в том, что они могут оказаться плоскими — вместо этого рассказывайте истории, которые имеют острые моменты откровения и моменты, в которые возможно всё кажется потеряным, и тогда придуманная вами особенность решает всё.
![](https://habrastorage.org/storage2/1b9/ecc/eb8/1b9ecceb8ef27ca0d3aed67ac9a7bf5f.png)
Вы можете высказать истории пользовательского опыта, записав их и с помощью своего рода визуальных средств таких, как эскизы в раскадровках и/или доски настроения (moodboards). Также отметим, что повествование в дизайне пользовательского опыта является многомерным смыслом, имеющим различные уровни опыта, для которых можно написать рассказ. Сначала вы можете написать полную историю верхнего уровня приложения. Наконец, вы можете написать истории для специфических особенностей.
Очень ценная техника, которую я узнал занимаясь маркетингом, это писать мини-истории, называемые «речь в лифте», основа которой состоит в том, чтобы быть в состоянии передать историю в 30 секунд или меньше. Если вы не можете описать ваше приложение, ваши основные области особенностей или специфическую особенность менее чем за 30 секунд, то скорее всего вы еще не овладели сценарием или особенностью, и вам нужно больше времени, чтобы изучить ее.
«Если вы не можете рассказать историю вашего приложения или специфической особенности в 140 символах, возможно вы нуждаетесь в более глубоком изучении, прежде чем продолжить процесс».
Ещё более эффективным методом, который я использую в последнее время, является описание вашего приложения, ваших основных областей или специфических особенностей в современных стандартах «речи в лифте»: статус в Facebook или твит в Twitter. Поэтому постарайтесь написать мини-рассказ (на самом деле нано-рассказ) в 420 символов для статуса в Facebook, а затем в 140 символов для Twitter. Если вы не можете описать своё приложение или особенность в этом ограниченном количестве символов, то как уже упоминалось, скорее всего, вы не можете до сих пор закрепить пользовательский опыт таким образом, чтобы больше не требовалось исследования. Если в команде возникает конфликт согласования для твита длинной истории, описывающей их приложение или особенности их приложения, то хорошо бы вернуться назад и поговорить больше о приложении или особенности, в поиске ключевых элементов способствуеющих пользовательскому опыту.
Вот несколько хороших описаний, которые я нашёл в Marketplace для Windows Phone:
CocktailFlow
Twitter: Обзор, поиск и открытие коктейлей с непрерывно растущей коллекцией напитков.
Facebook: Обзор, поиск и открытие коктейлей с непрерывно растущей коллекцией напитков. Приложение имеет красиво оформленные рецепты коктейлей и определяет, что может быть приготовлено из ингредиентов в баре. Он также дает советы о том, какие ингредиенты купить ещё, чтобы сделать дополнительные вкусные коктейли.
Seesmic
Twitter: Seesmic позволяет вам обновлять и просматривать одновременно несколько социальных сетей в эффективном и мощном приложении.
Facebook: Seesmic позволяет вам обновлять и просматривать одновременно несколько социальных сетей в эффективном и мощном приложении. Управление несколькими учетными записями Twitter, Facebook, Salesforce Chatter и систематизировать все ваши учётные записи, поисковые запросы, актуальные темы, и списки в вашем настраиваемом «пространстве» панели управления.
Темы опыта: элемент рассказа применительно к дизайну – это была потрясающая сессия, представленная Синди Честейн на IA Summit 2009 в Мемфисе. Она говорила о рассказывании историй для дизайнеров пользовательского опыта и разработчиков. Лучше писать через дизайн, написанная Браунвин Джонс /Brownwyn Jones/, это хорошая статья, которая даёт практические советы, чтобы лучше писать истории пользовательского опыта. Статья Использование историй для лучшего пользовательского опыта, написанная Уитни Квесенбери /Whitney Quesenbery/, объясняет использование личностей для написания историй, а также идей для сбора историй непосредственно от пользователей во время сессий тестирования. Вот презентация Уитни с заметками и слайдами. Не напрямую связано с дизайном пользовательского опыта, но я думаю, что эта статья О конфликтах и персонажах в структуре истории, которая была очень полезна для меня, чтобы понять основную структуру историй – структуру, которая может быть легко переведена на рассказывание историй о пользовательском опыте.
Замечание о том, чтобы быть осторожными с… детьми
Во время этапа исследования вы неизбежно будете сталкиваться с конфликтом интересов, и люди будут влюбляться в свои идеи. Идеи, как дети и младенцы могут быть такими милыми, что вы не захотите отпустить их даже тогда, когда они представляют собой зло. Таким образом, научитесь обрубать канат и отпускать идеи, если они доказывают (и это ключевое слово здесь… доказывают), что они не оправданы. В то же время, охватывать некоторые идеи и отстаивать их любой ценой не менее важно. Без сильного вдохновителя в команде хорошая идея может слететь с трассы и затеряться навсегда. То, что мы хотим найти на протяжении всего нашего исследования является «свидетельством, которое доказывает» что это стоящая идея, или что это не так. В ходе этого процесса, идея будет развиваться и в конце вы многое узнаете о ней. Заметьте, это не время, чтобы сделать эту идею зрелой на 100%, но чтобы почувствовать насколько она осуществима. Я только что прочитал твит с цитатой Эда Кэтмала /Ed Catmull/ — президента Pixar: "Культура Pixar заключается в защите неоформленной идеи".
Закрепление
Если мозговой штурм — это всё о свободе, то закрепление — это всё о принятии решений, о получении ясности и о достижении консенсуса между различными точками зрения в команде. На данный момент командой будут изучены и узнаны куча идей в деталях. В этот момент будет легче для команды принимать решение какие из идей получат дальнейшее развитие и перейдут на следующие этапы. Хорошей техникой для этого момента является использование красных и зеленых точек или любой другой метод принудительного ранжирования. То, чего мы хотим добиться здесь — это устранение неоднозначности и наличие чёткого приоритетного списка сценариев, чтобы мы могли удалить те идеи, которые просто не имеют технического, делового потенциала и потенциала опыта.
Метод принудительного ранжирования заключается в том, чтобы дать людям $100 (условных) и попросить их положить столько долларов, сколько они пожелают, рядом с идеей/сценарием, который они считают, что следует продвигать и разрабатывать как часть приложения для Windows Phone. В руках у людей будет бюджет и на практике это заставит людей хорошо думать во что вкладывать свои «деньги». Некоторые люди могут сделать выбор, разделив свои инвестиции (голоса) на 5 частей – по $20 каждая. Другие будут тяготеть конкретной идеи и поставят $45 на неё, а остальные разделят на другие идеи. Некоторые могут разделить свои инвестиции на 100 частей! Но конечно же их «решение и сила влияния» будет сильно уменьшена.
В конце, в зависимости от результатов, определяется порог и убираются все идеи имеющие рейтинг ниже этого порога. Все остальные становятся приоритетным списком сценариев для вашего приложения, которые будут дополнительно изучены, чтобы превратить их в особенности. Готово! :)
![](https://habrastorage.org/storage2/b4c/2a1/dcb/b4c2a1dcb7432b6f5292f2dcc252b747.png)
Предыдущая статья | #2 Процесс проектирования приложений для Windows Phone
P.S. Другие материалы про Metro на русском языке собраны на MSDN в хабе «metro-дизайн»