что такое прототип проекта
Прототипирование продукта
Во всем многообразии продуктовых терминов, прототип кажется одним из самых понятных и безобидных. Но как определить его качество? В какой момент нужно задуматься о прототипировании продукта и нужно ли вообще?Какие инструменты для этого использовать? Перейти к реальным действиям часто оказывается сложно. Поэтому мы решили собрать небольшой мануал по использованию прототипов в продуктовой разработке.
Все мы прекрасно понимаем, что строительство нового здания всегда начинается с его уменьшенного макета, чтобы архитектор мог убедиться в целостности ансамбля, а при проектировании космического шаттла сначала создается его прототип, чтобы провести необходимые исследования и расчеты. Однако при разработке технологического продукта стадия прототипа часто либо осознанно опускается, либо просто игнорируется. Такой подход чреват увеличением затрат на разработку или вообще выпуском не того продукта, который необходим пользователю. Поэтому давайте последовательно разберем: что такое прототип в разработке продукта, зачем и в какой момент он необходим, какие принципы нужно соблюдать, чтобы создать качественный прототип и какие инструменты нам могут в этом помочь.
Что такое прототип?
Для начала стоит дать определение. Прототип — это простая экспериментальная модель предполагаемого решения, используемая для тестирования идей, проектирования предположений и способов использования продукта быстро и дешево и позволяющая вносить необходимые уточнения и изменения в направление развития продукта. Иными словами прототип позволяет вам:
Чем прототип НЕ является:
Можно выделить два основных вида прототипов технологических продуктов:
Выбор типа зависит исключительно от гипотезы, которую вы тестируете.
Какую цель преследуют прототипы?
Окей, прототип — это модель, которую мы собираем из подручных средств (в оффлайне или онлайне), чтобы проверить какую-то идею. Какие глобальные цели мы при этом преследуем? Их можно разделить на 4 категории:
Один из лучших способов увидеть сильные и слабые стороны вашего будущего продукта — начать что-то делать, экспериментируя с потенциальным решением. Прототипируя, вы облекаете свои идеи в осязаемую оболочку, которая дает возможность вам и вашей команде увидеть и обсудить все за и против, услышать обратную связь от пользователя и продемонстрировать свою уникальность потенциальным инвесторам.
На какой стадии создания продукта пора думать о прототипе?
Допустим, мы убедили вас, что прототип — это круто и он вам очень нужен. Но в какой момент стоит о нем задуматься? В классической концепции дизайн мышления предполагается следующий порядок действий:
Таким образом, к созданию прототипа необходимо приступать, когда вы уже погружены в контекст пользователя, осознаете его боли и проблемы и у вас есть четкая продуктовая гипотеза для решения этих проблем. Иными словами, это момент, когда вы уже готовы собирать команду продуктовой разработки и пилить самый классный революционный продукт 🙂 Вот ровно в этот момент лучше остановиться, выдохнуть и собрать прототип для проверки своих идей.
Основные принципы прототипирования
Разобрались что, зачем и в какой момент времени мы хотим делать. Остался главный вопрос: как же сделать прототип качественным? Для этого нужно держать в голове ряд основных принципов:
Вы можете пройтись по этому списку как по чек-листу после того, как ваш прототип будет готов, задавая себе вопрос: отражен ли этот принцип? Если галочки стоят во всех пунктах — можно смело переходить к следующей стадии и тестировать прототип на пользователях, инвесторах и стейкхолдерах (этому процессу мы посветим отдельную статью).
Инструменты для создания динамических прототипов
Прекрасно, вроде бы все стало более ли менее понятно. Но теперь вы стоите перед проблемой чистого листа: что делать известно, а вот как начать? Для создания кликабельных прототипов существует много различных инструментов. Вот некоторые их самых популярных:
Прототипы: как создать успешный продукт и сэкономить
Полгода назад в статье о том, как мелкие юзабилити-ошибки создают бизнесу большие проблемы, я упоминал неудачный запуск Делисамоката, сырое приложение которого, вызвало большую волну негатива.
Недавно, прогуливаясь по Москве, вспомнил о стартапе и решил проверить его лично. Но уже через 15 минут понял, что шансов взять самокат в аренду нет, а рейтинг 1.5 в AppStore полностью оправдан и подтверждает, что сложности не только у меня.
На запуск стартапа такого масштаба, вероятно, было потрачено довольно много денег. И рейтинг 1.5 как бы намекает, что тратить придется еще.
Могли ли разработчики Делисамоката избежать такой ситуации и выпустить более удобное приложение сразу? Да, если бы сначала сделали прототип и протестировали его на реальных пользователях.
Из статьи вы узнаете:
Что же такого важного в этих ваших прототипах?
Концепция прототипов в обычном мире довольно стара. Строительству любого здания предшествует проект (проект = прототип), выпуску серийного автомобиля — концепт (концепт-кар = прототип). Несмотря на это, в цифровом мире долгое время даже высокобюджетные проекты фактически разрабатывались методом тыка, а продукты для среднего и малого бизнеса вообще по наитию подрядчиков.
Прототип в цифровом мире – это визуализация будущего продукта, достаточная для проверки гипотез среди пользователей этого продукта, и/или для донесения идей до людей, принимающих решение о его создании. Прототип позволяет быстро и, главное, дешево получить обратную связь: решает ли разработанный вами интерфейс бизнес-задачи, удобен и понятен ли ваш инновационный способ взаимодействия пользователям, правильно ли вообще понята проблематика и задачи. В противном случае решать все это придется уже после запуска продукта, а это не только потраченное время, но и деньги.
Прототип-прототипу — рознь
Прототипы, как средство быстрой визуализации идей, в последние годы получили большое распространение и оказали позитивное влияние на качество цифровых продуктов в целом.
Вместе с тем, взяв на вооружение инструменты прототипирования, рынок все еще не до конца усвоил, что прототип – часть юзабилити-процесса, а не проджект-менеджмента.
За последние несколько лет я общался со многими дизайнерами, у которых в портфолио есть пара десятков прототипов, при этом часто они не только не понимают до конца процесс создания прототипов, но и не всегда уверенно могут объяснить зачем они вообще нужны.
В итоге, все чаще можно встретить прототип, в котором нет и намека на реальный контент, а графическая форма преобладает над содержанием. В быстрорастущем сегменте UI/UX-дизайна доходит до того, что прототипом начинают называть полноценные дизайн-макеты, на создание которых были затрачены десятки человеко-часов.
Влияет на ситуацию и развитие рынка инструментов прототипирования, где все больший акцент получает работа с визуальной частью. Все это подталкивает к соблазну уделить особое внимание композиции и красоте прототипа, забывая о главном — структуре и контенте.
Формирование эффективной структуры и подготовка контента – наиболее длительный и трудозатратный процесс, при этом, как показывает практика, максимально влияющий на конечный продукт.
Прототип – результат комплекса работ
Рассмотрим шаги, выполнение которых позволит создать действительно эффективные интерфейсные решения, основанные на потребностях пользователей и решающие конкретные бизнес-задачи:
Исследования
Исследования – важнейший этап, фундамент успеха всей последующей работы. Несмотря на это, на рынке до сих пор приняты два способа «исследований»: «пришлите нам ТЗ» и «заполните бриф на 150 вопросов».
Ни техническое задание, ни бриф не способны обеспечить необходимый уровень погружения для создания действительно эффективных решений: техническое задание ни что иное, как субъективное восприятие действительности клиентом, которое во многом заимствует существующие решения конкурентов, а любимые многими брифы – не только ставят разные бизнесы в один ряд, но и заставляют клиента потратить значительное время, отвечая на шаблонные вопросы, реальный смысл которых он, зачастую, не понимает до конца.
Поэтому в вопросе исследования бизнеса самым эффективным является путь личного общения с клиентом. Это позволяет максимально погрузится в процессы и особенности каждого конкретного бизнеса, выявить едва заметные нюансы, которые в итоге могут и часто становятся основой всего последующего продукта.
Многие UI/UX-дизайнеры не считают необходимым общаться с пользователями, тем не менее, исследование пользователей позволяет взглянуть на задачу с другой стороны, выявить причинно-следственные связи, понять мотивацию, обнаружить страхи, услышать сомнения, найти инсайты.
Разработка дизайн-решения
На этом этапе результаты исследований интерпретируются в конкретные требования к продукту: какой должна быть навигация, какие нужны экраны, какие потребности они должны закрывать и многое другое.
Для трансформации исследований в требования к продукту существует множество инструментов: User-Centered-Design, Value Proposition Canvas, Jobs-To-Be-Done и другие, но все они приводят к одному результату – осознанному проектированию интерфейса.
Результатом разработки дизайн-решения становятся бумажные наброски – скетчи, которые в дальнейшем превращаются в прототипы высокой детализации.
Контент
Прежде, чем перейти от скетчей к прототипам высокой детализации, нужно подготовить весь контент. Соблазн использовать текстовую рыбу чреват последствиями: такой прототип невозможно реально оценить, к тому же, когда реальный контент все-таки появится, окажется, что он не ложится в уже разработанный продукт. И тогда контент придется подгонять под заданные рамки.
Поэтому сначала ЧТО (контент), а потом КАК (дизайн).
Прототип
Пройдя весь путь от исследований и выработки дизайн-решений до написания контента, команда находится в максимальном вовлечении и способна выдать действительно свежие интерфейсные решения, учитывающие потребности целевой аудитории и поставленные бизнес-задачи. Такие прототипы легко тестировать на пользователях и/или использовать для донесения идеи людям, принимающим решение о создании продукта.
Как отличить хороший прототип от плохого
Вот простой чек-лист, который без каких-то знаний в области проектирования взаимодействия позволит определить, подсовывают ли вам под видом прототипа «заливную рыбу» или результат реальной работы.
Итак, всего несколько пунктов:
Заключительная история
Но все решилось уже в процессе исследований, когда выяснились, что пользователям не нужен такой продукт и эффективней использовать более простое, и, главное, уже существующее решение.
Эта история хороша тем, что отлично иллюстрирует, с одной стороны, важность создания прототипа перед разработкой реального продукта, с другой — важность процессов, необходимых перед слепым проектированием интерфейса.
Если вам показалось, что все слишком сложно и долго, вот доказательство обратного: UX-challenge: проектирование приложения мобильного банка за 5 дней
Как мы разрабатываем прототипы
Что такое прототип?
Прототип — это быстрое визуальное представление будущего продукта. Прототип позволяет увидеть проектируемую систему на самом раннем этапе.
Протипирование может занимать половину времени разработки интерфейса проекта. На этом этапе происходит утрясание концепции, поиск решений и корректировка первоначальных планов.
Прототип сразу дает представление о продукте, экономит деньги и время при разработке.
Прототип плюс ТЗ
Проектирование должно вестись гибко, не должно быть жестких, неизменных технических заданий. Во время прототипирования появляется понимание, как все должно работать. Написание ТЗ и прототипирование — процесс взаимодополняющий.
Когда мы пишем ТЗ, мы уже должны представлять как будет выглядеть проект, но на этапе прототипирования обязательно появятся новые решения, которые будут отличатся от первоначального замысла.
Исследование
Сначала проходят обсуждения проекта с владельцем продукта, выясняются задачи, цели. Параллельно собирается другая информации по теме: анализируется рынок, конкуренты, аудитория, составляются портреты пользователей продукта.
Постепенно начинает вырисовываться концепция, возникает понимание как продукт может выглядеть. Первый подход прототипу можно изобразить так:
Из информационного хаоса проектировщик начинает выявлять закономерности, отсекать лишнее, создавать гипотезы и предположения.
Первый прототип
В какой-то момент собранной информации становится достаточно и можно переходить к визуализации. Первые эскизы появляются еще в самом начале работы, но давайте считать прототипом то, что получается после обстоятельного исследования.
Сначала отрисовывается один ключевой экран. Из него можно понять основные принципы работы системы:
Прототип внутренней системы работы с тарифами мобильного оператора
С этого момента разработка принимает цикличный характер. Каждый вариант тестируется, выдвигаются гипотезы, вносятся изменения.
Прорабатываются другие функционалы:
Для сложных функционалов отдельно продумывается логика работы:
Схема функционала добавления сервисной информации интерфейса промышленного кондиционера
Интерактивность
Понять устройство системы можно только попробовав ее в динамике. Большинство современных систем прототипирования позволяют создавать интерактивные прототипы, имитирующие реальное использование системы.
Интерактивный прототип позволяет понять работу продукта в динамике
Для своих проектов мы используем сервис прототипирования UXPin.com. Это мощный инструмент онлайн-прототипирования.
Часто в интерактивные прототипы связываются готовые дизайн-макеты. В этом случае нет возможности реализовать все анимации и взаимодействия, но зато получается посмотреть на дизайн в действии. Для этих целей мы используем сервис marvelapp.com
Готовый прототип
В итоге, после множества итераций, разрабатывается полное представление будущей системы. Какие-то элементы могут быть упрощенными, а дизайн схематичен, но у владельца продукта и разработчиков теперь есть полное представление, как все будет работать.
Скриншоты прототипа рекламной системы
Перед переходом к следующему этапу, дизайну интерфейса, рекомендую внимательно проверить все детали. Чем точнее и полнее прототип, тем проще дизайнеру в отрисовке интерфейса а программистам в разработке. Хороший прототип — это экономия времени, денег и нервов всех участников создания продукта.
Прототип, блочная схема, макет – что выбрать?
Пару лет назад я понял, что многие из моих коллег(не дизайнеров) по разному называют результаты моей работы. Они предположили, что блочная разметка (wireframe), прототип (prototype) и макет (mockup) – это одно и тоже – своего рода сероватый, квадратный, эскиз поясняющий гениальные идеи.
Проблема данного обобщения в том, что они не всегда знают, чего ожидать от работы UX дизайнеров (User Experience designers), и по-этому часто путаются. «Почему, черт возьми, этот элемент не активен?», «Ну, я не знал, что должно было произойти после клика по этой ссылке. » – подобные комментарии раздражают многих в UX дизайн проектах…
Смешение понятий блочная схема и прототип равносильно тому, что считать архитектурный проект и эскиз фасада здания одним и тем же.
Вы можете, конечно, попробовать жить внутри красивой картинки. Вы знаете – своей красотой она затмит любой другое здание. Но вы не можете рассчитывать на комфортное пребывание в нем без архитектурного проекта, который поясняет, как это надо было строить.
Эскиз фасада и архитектурный план – это различные виды коммуникации в архитектуре:
— архитектурный проект дает понятие о том, как здание должно быть построено;
— эскиз фасада здания всего лишь демонстрирует то, как здание будет выглядеть будущим жильцам.
То же сравнение может быть применено к блочной схеме, прототипам и макетам. Они выглядят и работают по-разному, они служат разным целям.
Эскиз фасада здания и архитектурный проект действительно имеют много общего – они оба представляют собой конечный продукт – фактический дом. Тоже самое с прототипами, блочными схемами и макетами – все эти документы являются одной из форм представления конечного продукта.
Хотите верьте, хотите нет, разница между прототипом, блочной схемой и макетом всегда была одной из первых вещей, который я пытался научить членов моей команды UX дизайнеров.
И это действительно важно.
Давайте обсудим каждый из подходов, чтобы понять что и когда использовать.
Блочная схема (wireframe)
1. Что такое блочная схема?
Блочная схема является низко детализированным представлением дизайна продукта.
Она должна четко отображать:
— основные группы содержимого (что?)
— структуру информации (где?)
— описание и основные визуализации взаимодействия пользователя и системы (как?)
Блочная схема – это не просто бессмысленные наборы серых блоков (хотя на первый взгляд может показаться именно так). Их необходимо рассматривать в качестве основы дизайна и не забывать, что схема должна отражаться все важные части конечного продукта.
«Представление» является одним из важнейших здесь терминов, который поможет вам найти правильный баланс показателей скорости и качества отрисовки. Вы не можете вдаваться в детали, но с другой стороны, вы должны создать четкое представление окончательного проекта, которое не упустит ни одной важной детали. Вы даете направление проекту в целом и людям, которые работают с вами (разработчики, дизайнеры, копирайтеры, руководители проектов – все они нуждаются в качественных схемах). На самом деле вы создаете карту города. Каждая улица, изображенная на карте, значительно упрощена. Вы можете почувствовать все величие города, если вы посмотрите на карту, но вы не можете ощутить его красоты.
Блочная схема должна создаваться быстро, а основное время должно тратиться на общение с членами команды и продумывание деталей. Само же создание макета должно быть очень быстрым.
Визуализация должна быть аккуратной, но очень простой. Черно-серо-белая гамма является типичной (в некоторых случаях можно добавить синий цвет для указания ссылок).
Если что-либо занимает слишком много времени (например, выбор иконки, для кнопки загрузки изображения), необходимо представить её в упрощенном виде. Попробуйте заменить ее схематичным изображением в виде прямоугольника с двумя скрещенными линиями внутри и добавить соответствующее описание.
Мы склонны полагать, что блочная схема дает не полное представление о желаемом результате.
Помните – хорошо созданная схема является основой чистового дизайна и определяет направление работы для всей команды.
2. Когда используется блочная схема.
Блочные схемы, как правило, используются в качестве документации к проекту. Так как она является статической и отображает взаимодействие пользователя с интерфейсом на определенный момент времени, схема должна сопровождаться описанием (от коротких заметок, объясняющих взаимодействие – до комплекса технической документации).
Однако схемы могут использоваться менее формальным образом. Благодаря их простоте, они могут служить для улучшения взаимодействия членов команды. Если разработчики спрашивают, каким образом сделать тот или иной механизм – ответом для них может являться быстро созданная блочная схема.
Блочные схемы практически не используется для юзабилити-тестирования, хотя они могут помочь собрать обратную связь на первых этапах. Они не годятся для исследований, в которых важна методологическая чистота. А для того, чтобы попытаться получить быстрое понимание задачи – вполне.
Блочные схемы в контексте всего процесса разработки могут быть удивительно эффективными. И, хотя в последние годы они получают некоторые негативные отзывы, блочные схемы по-прежнему являются неотъемлемой частью многих проектов.
Прототип (prototype)
1. Что такое прототип?
Прототип (часто путают с блочной схемой) является средне или высоко детализированным представлением конечного продукта, имитирующим взаимодействие с пользователем.
Прототип используется для:
— отражения основных способов взаимодействий с пользователям;
— тестирования взаимодействия разрабатываемой системы с пользователем в качестве готового продукта.
Прототип представляет собой имитацию окончательного взаимодействия между пользователем и программой. Он может не выглядеть так же, как конечный продукт, но должен быть достаточно подробным.
Особое внимание должно уделяться сходству прототипа с конечным продуктом. Интерфейс обычно тесно связаны с программной частью, по-этому зачастую прототипирование позволяет сократить расходы и ускорить циклы разработки.
2. Когда использовать прототип?
Полный потенциал прототипов раскрывается при проведении юзабилити-тестирования. Подробное моделирование взаимодействия системы с пользователем дает возможность проверить удобство интерфейса ещё до начала разработки.
Обычно прототип не является «чистовым» отображением готового продукта. С другой стороны, прототип является наиболее привлекательной формой проектной документации, позволяющей в доступной форме донести задачу.
Помните, что прототипирование весьма дорогой и трудоемкий вид деятельности. Я бы советовал создавать прототипы, которые могли бы использоваться в разработке (да, это означает, что вам придется писать часть HTML, CSS кода). Это особенно эффективно в относительно простых проектах.
Если все сделано правильно, то в сочетании с юзабилити-тестированием, прототипирование может дать хорошие результаты.
Макет (mockup)
1. Что такое макет?
Макет является средне или высоко детализированным статичным дизайном проекта. Очень часто макет представляет собой конечный дизайн частей или в целом проекта.
Качественно сделанный макет:
— передает структуру информации, визуализирует содержание и демонстрирует основные функциональные возможности в виде статистических изображений;
— позволяет людям понять, как будет выглядеть конечный продукт.
Макеты часто путают с структурными схемами, из-за названия некоторых компаний(gomockingbird.com, mockupbuilder.com).
2. Когда использовать макет.
Создание макетов особенно полезно, если вы хотите согласовать проект с заказчиками на ранних стадиях. Благодаря большей детализации, макеты не вызовут недопонимания и негатива, как могло бы быть в случае со структурными схемами. А их создание занимает намного меньше времени, чем для создания прототипа. Макеты дают хорошую обратную связь, их так же можно использовать при составлении технической документации.
Что же в итоге?
С чего начать?
Прежде чем выбрать один из подходов к проектированию, вам необходимо:
— определить проблемы, которые вы пытаетесь решить;
— ознакомиться с целевой аудиторией;
— посмотреть на достижения конкурентов в этой области
— установить общие требования к продукту
Это минимум. А теперь подумайте, какой из результатов будет наиболее подходящим для вас. Рассмотрим ваш продукт и команду. Что будет лучше для всех вас? Формализованная документация, или неформальные наброски с совместной работой, дискуссии? У вас есть время и деньги на основательное юзабилити-тестирование, или вы собираетесь сделать пару эскизов от руки в местной кафешке?
Какими навыками вы владеете? Можете ли писать код?
Взглянув на себя и всю команду в целом, вы без труда определитесь с необходимым для вам методом.
Можно, конечно, воспользоваться ими всеми и… в большинстве случаев у вас все получится! Не бойтесь идти на этот шаг. У каждого из методов есть свои плюсы, и если все сделано правильно, вы получите отличный дизайн.