Наука и искусство условного макетирования

09.06.2012

Создание условных макетов (wireframe) — занятие старое, не особо почтенное и технологически простое. Примерно каждые три года эти три свойства вызывают очередную полемику о нужности/ненужности таких макетов, о том, как именно их правильно делать и, порой, куда именно их надо засовывать. Лично у меня был период, когда я (после мнения об их важности и полезности) считал их ненужными/в целом вредными, но он закончился довольно давно, и с тех пор я — обеими руками за вайрфреймы (и без всяких признаков близящегося разочарования).

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

Цели макетирования

Общераспространенное мнение гласит, что плюсы условных макетов заключаются в том, что макеты:

• Provide a fast, easy way to present concepts for interfaces
• Focus on underlying logic, behavior, and functionality
• Enable rapid iteration on design.

Это цитата из книги Dan M. Brown. Communicating Design: Developing Web Site Documentation for Design and Planning. Я тоже так думал, но сейчас склонен не согласиться. На мой взгляд, подобные способы использования ведут только к проблемам (что уже многократно разжевано в интернете), например:

• Вайрфреймы сковывают графического дизайнера и вообще приводят к шаблонным решениям.
• Вайрфреймы врут, как только дело касается тонкой проработки продукта в дальнейшем. Большой блок оказывается маленьким и наоборот.
• Заказчик видит в вайрфрейме нечто, что потом не узнает в готовом продукте («Я думал, оно будет вот так, а почему оно тогда так?»).

За более чем десятилетний опыт рисования условных макетов я обнаружил, что вышеприведенные цели лучше всего воспринимать как дополнительные и не особо важные. Получится обеспечить вайрфреймом «быстрый и простой способ презентации концепции интерфейса» и т.д. по списку — неплохо, не получится — немного жаль, но в целом тоже неплохо.

«На самом деле» самое главное в вайрфреймах — инвентаризация объектов; поэтому гораздо более продуктивно ставить перед собой следующие цели макетирования:

• Определить, что нужно, что не нужно, что хотелось бы, чего не хотелось бы.
• Удлинить процесс решения/вдохновения.
• Обеспечить ТЗ на контент.
• Уточнить объем работы по проекту.

Разберу эти цели подробнее.

Что нужно, а что не нужно

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

Все три пункта никак не завязаны на интерфейс. Это задачи совершенно другого класса:

1. Что сделать нужно обязательно, а что нет?
2. Если обязательные пункты конфликтуют между собой, что более обязательно, а что менее?
3. Какова примерная стоимость разработки/тестирования блока контента или функции? Оправдается ли эта затрата?
4. Что можно выкинуть, чтобы сделать работу в срок?
5. Не забыто ли что-то? Не упущено ли что-то?

Мой опыт показывает, что пункты 1–4 прекрасно отрабатываются составлением таблицы блоков контента/функциональности и последующего рейтингования элементов этой таблицы. А вот последний пункт таблицей не решается никак. Строго говоря, надежно он не решается вообще, но рисование условного макета — как процесс, не как результат — по крайней мере, здорово помогает вспоминанию. Когда рисуешь вайрфрейм, идеи приходят в голову сами со значительно большей скоростью, чем при любой другой деятельности. Это — крупное достоинство условных макетов.

Медленное решение

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

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

Задание на контент

Если сделать в Гугле поиск по картинкам со словом wireframe, становится видно, что подавляющее большинство условных макетов собственно не специфицируют контент. Двумя полюсами текущей моды являются либо полноценные прототипы, либо абсолютно условные наборы прямоугольников, на которых написано, что это такое. И то и другое не вовсе бесполезно (особенно прототипы), но можно сделать еще лучше: использовать условный макет как носитель требований к контенту.

Например, если проектом является титульная страница новостного сайта и задача спроектировать список новых статей, можно:

1. Детально нарисовать модуль этого списка, вставив подходящие изображения, написав (уже не условно) интерфейсные тексты, подставив реалистично выглядящие заголовки.
2. Нарисовать перечеркнутые прямоугольники для картинок и добавить лоремипсума в качестве заголовков.

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

На мой взгляд, гораздо продуктивнее на стадии вайрфрейма просто зафиксировать содержимое блока словами, но зато конкретно и точно написав, что именно будет в блоке отображаться. Всего-то нужно нарисовать прямоугольник, а на нем написать нечто вроде:

Перечень последних статей. Примеры здесь (URL), здесь (URL) и здесь (URL). Последняя статья: картинка ~500px шириной, заголовок, автор, аннотация. Последние десять статей, для каждой картинка (~200px по ширине, заголовок, дата, автор, аннотация). Предпоследних 10 статей, для каждой: заголовок, дата, автор. Заголовок: не более 120 знаков. Дата: как всюду. Аннотация: 150–300 знаков.

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

Объем работы

Объем функциональности/контента, даже будучи известным заранее, на практике предсказуем не очень. Например, известно, что в интерфейсе будет всего 10 экранов; это хорошее, полезное знание, но хотелось бы еще лучше — по закону Паретто два и только два из этих экранов займут 80% работы. Горе проектировщику, который с легким сердцем, не спеша, случайно сделает простые экраны первыми — на сложные времени гарантированно не останется. Условный макет в такой ситуации оказывается очень полезным, поскольку позволяет заранее предположить объем работы.

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

Суммируя

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

Осталось рассказать, как их делать быстрее всего и лучше всего.

Как делать

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

Побольше наглядности

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

Полнота

Вайрфреймы должен обязательно содержать все экраны, страницы и окна интерфейса. Нормально, если на большинстве будет написано нечто вроде «Не входит в состав проекта», «Делается по образцу N» или «УЗНАТЬ ПОТОМ!!!». Ненормально, если что-то упущено, потому что это на корню убивает возможность использовать вайрфрейм для целей инвентаризации.

Если известно, что в продукте должен быть блок N, но еще непонятно, куда его пихать, допустимо, и, более того, правильно сделать страницу вайрфрейма под названием «Куда сувать будем???» и засунуть блок туда. Когда придет время, это (а) послужит напоминалкой принять решение вовремя и (б) не позволит вытеснить проблему из памяти.

Только достоверное знание

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

Приведу пример. Есть страница, на которой должны быть блоки А, Б, В, Г, Д и Е. Известно, что блоки А и В самые важные, а Д — самый неважный. Уже примерно известны минимальные размеры этих блоков по высоте и ширине. В такой ситуации:

Неправильно: Пытаться расположить эти блоки на странице так, как они примерно должны располагаться.

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

У этого правила есть веская причина: пытаясь располагать блоки, мы переводим сознание из режима поиска того, что нужно иметь в продукте, в режим располагания блоков. Это совершенно разные активности и тратить время на переключение головы туда-сюда (что попросту получается медленно) просто вредно.

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

Вайрфрейм должен быть единообразен

Важная часть работы над вайрфреймом заключается в том, что (внешне) дизайнер тупо пялится в него и (внутренне) напряженно думает «Не забыл(а) ли я чего?». Собственно говоря, от качества именно этой работы больше всего качество вайрфрейма и зависит. Так вот, если макет не единообразен, с этой деятельностью начинаются проблемы — разглядываешь вайрфрейм и отвлекаешься на несущественные различия. Это, кстати, еще одна причина, почему не надо прорабатывать вайрфрейм до того, как он стал полон.

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

Линиям нет, заливкам — да

Существует две школы мысли в вайрфреймостроении: принтерная и экранная. Приверженцы принтерной школы горой стоят за то, что вайрфреймы нужно рисовать тонкими линиями, так что весь вайрфрейм состоит из белых прямоугольников с окантовками. Школа же экранная учит, что вайрфрейм может иметь отдельные линии-разделители, но в целом должен состоять из закрашенных прямоугольников безо всяких рамок.

Правильно и неправильно.

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

• На распечатке без большого количества линий легче писать заметки/комментарии.
• В вайрфрейме без линий, но с оттенками, легче расставлять не только размер будущих блоков, но и их относительную важность. Достаточно всего лишь менее важные объекты делать светлее других, а более важные — темнее.
• При равном вложении усилий вайрфреймы без линий выглядят лучше.

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

1. Все, что есть у конкурентов, нужно записать в виде списка — функции, блоки контента, сообщения и т.п.
2. Для каждого пункта нужно попытаться придумать одну-две причины, по которым соответствующая вещь появилась — т.е. зачем оно нужно пользователям или бизнесу. Если придумать не удалось, или причина получается какой-то мелкой, есть повод насторожиться — обычно это признак того, что мы чего-то не знаем. Вообще, для неподготовленного человека эта задача не просто сложна, но обычно находится вне пределов разумения, так как единственные источники правильных решений здесь — это (а) знание бизнес-реалий, (б) знание конкурентов и того, что они делают и (в) трудноуловимое свойство, в просторечии называемое «знание жизни». Все три свойства редки среди всех людей, а пункт Б совсем уж редок среди дизайнеров интерфейсов. Поэтому здесь очень уместно смирение; лучше переборщить, чем недоборщить.
3. Для каждого пункта надо составить мнение (лучше формальное, способов для этого много, но все они выходят за рамки темы условных макетов) о том, нужен ли он нам. Теоретически, нужно всё, но подход «сделаем всё, что есть у конкурентов» никогда ещё не приводил к пристойному результату.
4. Из списка выкидывается все, что по сумме причин не нужно. Важно: даже если есть ТЗ, этот и предыдущие пункты все равно очень нужны, потому что никакое ТЗ, кроме самого вайрфрейма или прототипа, не может описать и специфицировать все интерфейсные объекты (и сам факт того, что вам приходится делать вайрфрейм, свидетельствует о том, что эта работа вам нужна).
5. К списку добавляется то, что нужно именно вам в именно вашем продукте.
6. Делается первая версия вайрфрейма. Там должны быть все объекты, которые должны быть (себя стоит проверять и перепроверять), но совершенно необязательно, что они должны быть правильно разложены по страницам/экранам/окнам (выше уже описано, почему не надо делать две работы одновременно).
7. Во второй версии вайрфрейма нужно уже постараться нащупать оптимальную структуру интерфейса, не думая о том, что нужно или не нужно, но зато думая о том, как правильнее всего распределить объекты, и нельзя ли заменить их на другие, получше.

Только после седьмого этапа вайрфрейм становится готовым для синхронизации с другими людьми.

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

Мы, Usethics, проектируем интерфейсы, проводим юзабилити-тестирование, исследуем пользовательский опыт и поставляем качественные UI и UX с 2001 года.