Прототип, блочная схема, макет – что выбрать?

image

Это перевод оригинальной статьи «Wireframing, Prototyping, Mockuping – What’s the Difference?».

Итак


Пару лет назад я понял, что многие из моих коллег(не дизайнеров) по разному называют результаты моей работы. Они предположили, что блочная разметка (wireframe), прототип (prototype) и макет (mockup) – это одно и тоже – своего рода сероватый, квадратный, эскиз поясняющий гениальные идеи.


Проблема данного обобщения в том, что они не всегда знают, чего ожидать от работы UX дизайнеров (User Experience designers), и по-этому часто путаются. «Почему, черт возьми, этот элемент не активен?», «Ну, я не знал, что должно было произойти после клика по этой ссылке...» – подобные комментарии раздражают многих в UX дизайн проектах…

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

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

Блочная схема (wireframe)


image

1. Что такое блочная схема?

Блочная схема является низко детализированным представлением дизайна продукта.
Она должна четко отображать:
— основные группы содержимого (что?)
— структуру информации (где?)
— описание и основные визуализации взаимодействия пользователя и системы (как?)

Блочная схема – это не просто бессмысленные наборы серых блоков (хотя на первый взгляд может показаться именно так). Их необходимо рассматривать в качестве основы дизайна и не забывать, что схема должна отражаться все важные части конечного продукта.

«Представление» является одним из важнейших здесь терминов, который поможет вам найти правильный баланс показателей скорости и качества отрисовки. Вы не можете вдаваться в детали, но с другой стороны, вы должны создать четкое представление окончательного проекта, которое не упустит ни одной важной детали. Вы даете направление проекту в целом и людям, которые работают с вами (разработчики, дизайнеры, копирайтеры, руководители проектов – все они нуждаются в качественных схемах). На самом деле вы создаете карту города. Каждая улица, изображенная на карте, значительно упрощена. Вы можете почувствовать все величие города, если вы посмотрите на карту, но вы не можете ощутить его красоты.
Блочная схема должна создаваться быстро, а основное время должно тратиться на общение с членами команды и продумывание деталей. Само же создание макета должно быть очень быстрым.
Визуализация должна быть аккуратной, но очень простой. Черно-серо-белая гамма является типичной (в некоторых случаях можно добавить синий цвет для указания ссылок).
Если что-либо занимает слишком много времени (например, выбор иконки, для кнопки загрузки изображения), необходимо представить её в упрощенном виде. Попробуйте заменить ее схематичным изображением в виде прямоугольника с двумя скрещенными линиями внутри и добавить соответствующее описание.
Мы склонны полагать, что блочная схема дает не полное представление о желаемом результате.
Помните – хорошо созданная схема является основой чистового дизайна и определяет направление работы для всей команды.

2. Когда используется блочная схема.

Блочные схемы, как правило, используются в качестве документации к проекту. Так как она является статической и отображает взаимодействие пользователя с интерфейсом на определенный момент времени, схема должна сопровождаться описанием (от коротких заметок, объясняющих взаимодействие – до комплекса технической документации).
Однако схемы могут использоваться менее формальным образом. Благодаря их простоте, они могут служить для улучшения взаимодействия членов команды. Если разработчики спрашивают, каким образом сделать тот или иной механизм – ответом для них может являться быстро созданная блочная схема.

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

Прототип (prototype)


image

1. Что такое прототип?

Прототип (часто путают с блочной схемой) является средне или высоко детализированным представлением конечного продукта, имитирующим взаимодействие с пользователем.

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

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

2. Когда использовать прототип?

Полный потенциал прототипов раскрывается при проведении юзабилити-тестирования. Подробное моделирование взаимодействия системы с пользователем дает возможность проверить удобство интерфейса ещё до начала разработки.
Обычно прототип не является «чистовым» отображением готового продукта. С другой стороны, прототип является наиболее привлекательной формой проектной документации, позволяющей в доступной форме донести задачу.
Помните, что прототипирование весьма дорогой и трудоемкий вид деятельности. Я бы советовал создавать прототипы, которые могли бы использоваться в разработке (да, это означает, что вам придется писать часть HTML, CSS кода). Это особенно эффективно в относительно простых проектах.
Если все сделано правильно, то в сочетании с юзабилити-тестированием, прототипирование может дать хорошие результаты.

Макет (mockup)


image

1. Что такое макет?

Макет является средне или высоко детализированным статичным дизайном проекта. Очень часто макет представляет собой конечный дизайн частей или в целом проекта.
Качественно сделанный макет:
— передает структуру информации, визуализирует содержание и демонстрирует основные функциональные возможности в виде статистических изображений;
— позволяет людям понять, как будет выглядеть конечный продукт.
Макеты часто путают с структурными схемами, из-за названия некоторых компаний(gomockingbird.com, mockupbuilder.com).

2. Когда использовать макет.

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

Что же в итоге?



image

С чего начать?



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

Это минимум. А теперь подумайте, какой из результатов будет наиболее подходящим для вас. Рассмотрим ваш продукт и команду. Что будет лучше для всех вас? Формализованная документация, или неформальные наброски с совместной работой, дискуссии? У вас есть время и деньги на основательное юзабилити-тестирование, или вы собираетесь сделать пару эскизов от руки в местной кафешке?
Какими навыками вы владеете? Можете ли писать код?
Взглянув на себя и всю команду в целом, вы без труда определитесь с необходимым для вам методом.
Можно, конечно, воспользоваться ими всеми и… в большинстве случаев у вас все получится! Не бойтесь идти на этот шаг. У каждого из методов есть свои плюсы, и если все сделано правильно, вы получите отличный дизайн.
Поделиться публикацией
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 33

    –5
    Извините, с вами можно пообщаться на тему дизайна интернет магазина?
      +2
      ЛС же.
      0
      После нескольких проектов с первоначальным детальным прототипированием (Axure) сложилось мнение, что хорошо сделанный, откомпентированный прототип заменяет большую часть технического задания на сайт. Интересно, что на этот счет думают профессионалы. :)
        0
        Заменяет.
          0
          Только для довольно простых сайтов.
            0
            Можно поспорить — все зависит от методологий разработки. Делаем высокодетализированные прототипы в Axure + в целом работа по Agile = позволяет делать сложные продукты без документации (функциональной спецификации).
          0
          Вцелом — да. Но за счет банальной человеческой невнимательности, они часто остаются без внимания, по-этому предпочитаю дублировать их в ТЗ.
          Еще есть такой момент, что некоторые вещи проще описать в ТЗ, чем реализовывать в прототипе. В общем, на мой взгляд, нужно сочетать оба подхода таким образом, чтобы сократить общее время на разработку и, чтобы не оставалось неясных моментов.
            0
            Профессионалы считают, что прототип — единственное средство UX-специалиста. Все остальные не дают представления о юзабилити будущего продукта. И да, прототип заменяет ТЗ. Если построить архитектуру таким образом, что прототипы будут ее неотъемлемой частью, то разработка будет приносить массу удовольствия при минимуме ошибок.
              0
              Зачем себя ограничивать? Одно другому не мешает.

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

              В условиях разработки сервисов для уже существующего продукта это точно лучше работает.
                0
                Блочная схема не отвечает ни на один вопрос. На картинке может быть все красиво, начинаешь пользоваться — ужас просто. Юзабилити не заканчивается на расположении, его максимум проявляется как раз в динамике.
                  0
                  Не согласна, блочная схема дает верхний уровень представления об устройстве интерфейса.

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

                  Кстати, блочную схему вполне можно сделать с простой динамикой — тот же balsamiq дает такую возможность.
                    0
                    Вы говорите все верно. Это действительно верхний уровень представления об устройстве интерфейса. Я же говорю про то, что в реальной жизни это высокоуровневое представление не особо нужно, потому что это часть прототипа. Для меня цель не нарисовать расположение элементов, а сделать удобным их использование. Поэтому я не зацикливаюсь на схемах, а сразу рисую прототип.
                      0
                      Ну, вот в нашей реальной жизни in-house дизайнеров это очень удобная и важная штука :) Потому что на этапе продумывания общего концепта нужны именно наброски, которые можно крутить очень быстро, параллельно обсуждая с разработчиками и бизнесом. Удобство — это самое важное, но если думать только о нем, то можно сделать прототип, который в итоге не будет реализован по бизнесовым или технологическим причинам.
                        0
                        Я понимаю, что это важно для вас. И понимаю, что мы с вами говорим на совершенно разных языках.

                        Я недавно пытался пояснить, почему рисовать дизайн по требованиям заказчика — ущербная логика. Меня не поняли. Основной мой постулат был таковым: «Заказчик описывает требования, которые у него были пол года назад, и проблемы, которые он видит через призму своего опыта. Но это не значит, что нужно реализовывать его видение, нужно решать его реальные проблемы, а не бороться с симптомами.»

                        Я тоже однажды попался на крючок, пытаясь создать систему, которая повторяла требования заказчика, его процессы. Я потерпел фиаско. Сейчас я понимаю, что вместо сложных интерфейсов, что я пытался им предоставить, в большинстве случаев можно было обойтись вообще без этого. Например, отчеты можно присылать на почту, единожды настроив их. Человек вообще не будет иметь доступ в систему, потому что ему это не нужно.
                          0
                          Мы действительно говорим на разных языках. Вы не понимаете, почему для меня это важно, мотивация совершенно не та. Смысл не в том, чтобы выполнить требования заказчика (я сама себе заказчик зачастую), а в том, чтобы как можно раньше понимать, где могут быть подводные камни с точки зрения реализации и вложений.
                          Речь не о том, чтобы проектировать, исходя из ограничений. Речь о том, что еще до разработки финального прототипа хорошо бы осознавать, как его будут реализовывать. Иначе модель может оказаться красивой, но настолько дорогой и/или долгой, что ее не выпустят. Или выпустят, но по дороге оторвут что-нибудь (особенно если вы аутсорсер). Если вы понимаете условия реализации, то можете и работать с ними по-человечески. Например, сделать в нужный срок разумную часть того, что хотелось бы, а потом прикрутить остальное. Качество только выигрывает в таких случаях.

                          И потом — вы же начинаете с архитектуры в любом случае. Да, детали взаимодействия вы продумаете потом, но что мешает бэк-энду посмотреть на вашу блочную схему и начать пилить внутренности?
              0
              Зависит от сложности процессов, которые протекают на сайте. Мы сейчас закончили прототип для одного из проектов и теперь на очереди техническое задание. Хотя прототип и показывает большую часть функционала сайта, этот функционал всё таки следует описать в ТЗ. Многие ситуации не видны на прототипе и их нужно продумывать во время составления ТЗ.
              0
              Многие не понимают «как это работает», если показывать просто картинки (блочная схема). Даже, если там реальный контент.

              А если у клиенты был старый полустатичный сайт тремя колонкам, а вы предлагаете что--то новое с динамикой, то без прототипа не обойтись.

              Конечно, вечен холивар насколько сильно детализировать (я за что-то среднее, а вот Нимакс — за дизайнерскую проработку), но в любом случае без прототипа никуда. У Горбунова вроде была выдержка из договора, где прописано, что прототип имеет главный приоритет, потом тз, потом еще что-то…

                0
                Так любой Axure и иже с ним позволяет делать связки «блочных схем» в прототип без кодинга, так что грань между ними довольно тонкая
                  0
                  «Любой Axure» стоит порядка 450 у.е., в отличии от текстового редактора и браузера.
                    0
                    Окай, Pencil. Бесплатных тулз тоже килограмм. И да, труд того, кто будет прототип кодить, стоить может и подороже 450 баксов
                      0
                      Как человек, рисующий прототипы в Axure, и почти год проработавший (по собственной инициативе) под линуксом, ответственно заявляю: бесплатных аналогов Axure, близких к нему по функциональности, не существует, ни в вебе, ни, тем более, в виде десктопных приложений.
                  0
                  Кстати, видел много тулзов для создания блочных схем, но не видел продуктов для прототипирования. Подскажите?
                    +1
                    Для семейства MS, например Expression Blend.
                      0
                      жаль, что под винду
                        0
                        Blend завис в развитии как и весь Expression(
                        0
                          0
                          слишком сложно для прототипа, я так могу и руками написать прототип, зачем мне дримвьювер (не пользовался им уже лет 7, к слову)
                          0
                            0
                            Типичное приложение для блочных схем. Прототип подразумевает динамику.
                              0
                              Balsamiq, конечно, для блочных схем, но простейшую динамику в нем тоже можно делать. Есть же возможность связывать элементы и страницы линком. Грубо говоря, в нем можно делать схематичный прототип.
                            0
                            Продукты для прототипов есть, но они ориентированы на программистов (и, соответственно, называются фреймворки, например twitter.github.com/bootstrap/. Из gui утил на ум приходит только www.axure.com — там есть переходы по страницам и вроде бы еще что-то.
                            0
                            Статья отличная, спасибо!

                            А вы не могли бы к каждому пункту добавить рекомендуемые инструменты для создания? Ну или не к каждому, а к 1-му и 3-му :)
                              0
                              Помогите: habrahabr.ru/qa/22004/

                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                              Самое читаемое