Создание условных макетов (wireframe) — занятие старое, не особо почтенное и технологически простое. Примерно каждые три года эти три свойства вызывают очередную полемику о нужности/ненужности таких макетов, о том, как именно их правильно делать и, порой, куда именно их надо засовывать. Лично у меня был период, когда я (после мнения об их важности и полезности) считал их ненужными/в целом вредными, но он закончился довольно давно, и с тех пор я — обеими руками за вайрфреймы (и без всяких признаков близящегося разочарования).
Думаю, это потому, что я наконец-то научился делать их правильно. Об этом и расскажу.
Общераспространенное мнение гласит, что плюсы условных макетов заключаются в том, что макеты:
Это цитата из книги Dan M. Brown. Communicating Design: Developing Web Site Documentation for Design and Planning. Я тоже так думал, но сейчас склонен не согласиться. На мой взгляд, подобные способы использования ведут только к проблемам (что уже многократно разжевано в интернете), например:
За более чем десятилетний опыт рисования условных макетов я обнаружил, что вышеприведенные цели лучше всего воспринимать как дополнительные и не особо важные. Получится обеспечить вайрфреймом «быстрый и простой способ презентации концепции интерфейса» и т.д. по списку — неплохо, не получится — немного жаль, но в целом тоже неплохо.
«На самом деле» самое главное в вайрфреймах — инвентаризация объектов; поэтому гораздо более продуктивно ставить перед собой следующие цели макетирования:
Разберу эти цели подробнее.
Одна из самых сложных проектных задач заключается даже не в том, чтобы сделать хорошо, а в том, чтобы решить, что именно нужно делать (по возможности хорошо), а чего — по сумме причин — не стоит делать вовсе.
Все три пункта никак не завязаны на интерфейс. Это задачи совершенно другого класса:
Мой опыт показывает, что пункты
Практика показывает, что хорошие идеи приходят в голову не тогда, когда нужно, а когда хотят. Несложно сделать вывод, что чем дольше делаешь работу, требующую генерации идей, тем больше шансов, что за время работы идея все-таки появится, а значит, долгая работа — лучше короткой. Условные макеты очень хорошо помогают именно в этом отношении. Хотя создание макета занимает минимум времени и проект фактически не удлиняет, оно позволяет начать предметно думать о проекте несколько раньше, чем получается без макетирования.
Предположим, у нас есть сайт на 10 страниц и проект занимает 10 дней, при этом на одну страницу уходит день. Без вайрфрема только первая сделанная страница будет в работе все 10 дней, каждая же последующая будет в работе на день меньше. С вайрфреймом же все 10 страниц будут в работе все 10 дней, обеспечивая больше возможностей придумать что-то еще лучше.
Если сделать в Гугле поиск по картинкам со словом wireframe, становится видно, что подавляющее большинство условных макетов собственно не специфицируют контент. Двумя полюсами текущей моды являются либо полноценные прототипы, либо абсолютно условные наборы прямоугольников, на которых написано, что это такое. И то и другое не вовсе бесполезно (особенно прототипы), но можно сделать еще лучше: использовать условный макет как носитель требований к контенту.
Например, если проектом является титульная страница новостного сайта и задача спроектировать список новых статей, можно:
Первый вариант хорош, но долог (и вообще это уже будет не вайрфрейм, а прототип, потому что уже фиксирует композицию блока). Второй вариант тоже хорош, но не совсем понятно, что именно он фиксирует — слишком уж он самоочевидный (понятно, что будут заголовки, понятно, что есть картинки, но все это было понятно и до рисования вайрфрейма).
На мой взгляд, гораздо продуктивнее на стадии вайрфрейма просто зафиксировать содержимое блока словами, но зато конкретно и точно написав, что именно будет в блоке отображаться. Всего-то нужно нарисовать прямоугольник, а на нем написать нечто вроде:
«Перечень последних статей. Примеры здесь (URL), здесь (URL) и здесь (URL). Последняя статья: картинка ~500px шириной, заголовок, автор, аннотация. Последние десять статей, для каждой картинка (~200px по ширине, заголовок, дата, автор, аннотация). Предпоследних 10 статей, для каждой: заголовок, дата, автор. Заголовок: не более 120 знаков. Дата: как всюду. Аннотация:
Написать такое — несравненно быстрее, чем рисовать полноценный прототип, а информативность значительно выше, чем у просто набора прямоугольников. Не говоря уже о том, что места для разночтений тут нет, а значит, не будет технологических проблем с утверждением проекта у заказчика.
Объем функциональности/контента, даже будучи известным заранее, на практике предсказуем не очень. Например, известно, что в интерфейсе будет всего 10 экранов; это хорошее, полезное знание, но хотелось бы еще лучше — по закону Паретто два и только два из этих экранов займут 80% работы. Горе проектировщику, который с легким сердцем, не спеша, случайно сделает простые экраны первыми — на сложные времени гарантированно не останется. Условный макет в такой ситуации оказывается очень полезным, поскольку позволяет заранее предположить объем работы.
У этого достоинства есть, кстати, не только практический, но и эмоциональный смысл. Без вайрфрейма дизайнер, заканчивая очередную страницу, испытывает сладостное чувство от хорошо сделанной работы. Оно, правда, обычно несколько омрачается сознанием факта, что работы еще много. С вайрфреймом же, в придачу к сладостному чувству свершения, получается испытывать еще и не менее сладостное облегчение, вызванное наглядным уменьшением будущей работы. С вайрфреймом видно не только как куча сделанного растет, но и как куча несделанного уменьшается.
На мой взгляд, эти четыре ценности с лихвой оправдывают существование условных макетов. Обратите внимание, что ни в одном из этих пунктов нет ничего про интерфейс — именно поэтому я и считаю интерфейсные свойства вайрфреймов сугубо необязательными, хотя, конечно, и желательными.
Осталось рассказать, как их делать быстрее всего и лучше всего.
Предлагая неконвенционное восприятие вайрфреймов, предложу более-менее конвенционное решение, как их делать. Есть несколько простых правил и алгоритм действий. Начну с правил.
Если будет делаться прототип, крайне желательно делать вайрфрейм в той же программе, что и будущий прототип, и в том же шаблоне. Тогда во время прототипирования можно будет заменять блоки вайрфрема/страницы и в любой момент видеть, как вайрфрейма становится меньше, и где еще осталась работа. Совет — если рисовать вайрфрейм не в оттенках серого, а в оттенках какого-либо другого цвета, различать вайрфрейм и куски уже сделанного прототипа будет легче. Альтернатива чуть похуже — готовить вайрфрейм так, чтобы его было легко распечатать — и каждый день перечеркивать в нем уже запрототипированные блоки. Наглядность прежде всего.
Вайрфреймы должен обязательно содержать все экраны, страницы и окна интерфейса. Нормально, если на большинстве будет написано нечто вроде «Не входит в состав проекта», «Делается по образцу N» или «УЗНАТЬ ПОТОМ!!!». Ненормально, если что-то упущено, потому что это на корню убивает возможность использовать вайрфрейм для целей инвентаризации.
Если известно, что в продукте должен быть блок N, но еще непонятно, куда его пихать, допустимо, и, более того, правильно сделать страницу вайрфрейма под названием «Куда сувать будем???» и засунуть блок туда. Когда придет время, это (а) послужит напоминалкой принять решение вовремя и (б) не позволит вытеснить проблему из памяти.
Условный макет обязательно должен хотя бы минуту существовать в состоянии, когда в нем отображено имеющееся знание и не отражено еще ни одного мнения. Проще говоря, в начале макетирования нужно фиксировать в вайрфрейме только то, что уже известно или уже решено — и только закончив этот этап, можно пытаться отразить в макете то, что еще не известно точно.
Приведу пример. Есть страница, на которой должны быть блоки А, Б, В, Г, Д и Е. Известно, что блоки А и В самые важные, а Д — самый неважный. Уже примерно известны минимальные размеры этих блоков по высоте и ширине. В такой ситуации:
Неправильно: Пытаться расположить эти блоки на странице так, как они примерно должны располагаться.
Правильно: Сначала просто сложить эти блоки в кучку, пометив их относительную важность (см. ниже) и написав в каждом их минимальный размер, и только потом, когда все блоки уже будут находиться на всех страницах вайрфрейма, постараться найти приемлемое расположение блоков.
У этого правила есть веская причина: пытаясь располагать блоки, мы переводим сознание из режима поиска того, что нужно иметь в продукте, в режим располагания блоков. Это совершенно разные активности и тратить время на переключение головы туда-сюда (что попросту получается медленно) просто вредно.
Кроме того, когда придет время утверждать вайрфрейм у заказчика/коллег, проверяющим не придется поминутно спрашивать себя «Так, это мы уже решили или еще нет?».
Важная часть работы над вайрфреймом заключается в том, что (внешне) дизайнер тупо пялится в него и (внутренне) напряженно думает «Не забыл(а) ли я чего?». Собственно говоря, от качества именно этой работы больше всего качество вайрфрейма и зависит. Так вот, если макет не единообразен, с этой деятельностью начинаются проблемы — разглядываешь вайрфрейм и отвлекаешься на несущественные различия. Это, кстати, еще одна причина, почему не надо прорабатывать вайрфрейм до того, как он стал полон.
Поэтому очень важно делать условные макеты чистенькими: (а) по сетке, (б) с единообразным количеством оформления и (б) что особенно важно, с единообразной проработкой блоков. Если вы на одной странице написали некий факт, очень важно именно писать подобное и на других страницах, даже если нарисовать — плевое дело, десять секунд.
Существует две школы мысли в вайрфреймостроении: принтерная и экранная. Приверженцы принтерной школы горой стоят за то, что вайрфреймы нужно рисовать тонкими линиями, так что весь вайрфрейм состоит из белых прямоугольников с окантовками. Школа же экранная учит, что вайрфрейм может иметь отдельные линии-разделители, но в целом должен состоять из закрашенных прямоугольников безо всяких рамок.
У принтерной школы есть крупное достижение, благодаря которому у нее множество последователей — при печати таких вайрфреймов экономится тонер. У экранной школы последователей меньше, но зато достоинств, на мой взгляд, побольше, поэтому я — за нее:
Теперь перейдем к алгоритму. Предположим, мы делаем новый продукт (если делается новая версия продукта существующего, легче просто сделать карту текущего интерфейса и работать поверх нее). Оптимальна следующая последовательность шагов:
Только после седьмого этапа вайрфрейм становится готовым для синхронизации с другими людьми.
Мой опыт показывает, что соблюдение этих нехитрых правил заметно помогает сделать интерфейс лучше, не удлиняя работу сколько-нибудь заметным образом (сама процедура рисования очень быстрая, а медленно принимаемые во время макетирования решения все равно придется рано или поздно принять, так что проект они не удлиняют).
Источник: http://usethics.ru/blog/lib/wireframing/
Отличная статья. Видно, что автор — настоящий практик. Возможно, не все ее тезисы будут очевидны для тех, кто не занимается прототипированием, но мысль, заложенная в статье, показывает, как все обстоит в реальности.
Я не совсем понимаю, по каким критериям Влад разделяет 2 понятия: вайфреймы и прототипы, но полностью разделяю идею. Основная польза от использования прототипов / вайфреймов заключается не в общепризнанных «быстро и итерационно», а в том, что на этапе прототипирования, и благодаря этому процессу, происходит огромная работа по уточнению и выяснению требований:
Поэтому при прототипировании нетривиальных вещей в нашей компании параллельно с дизайнером-проектировщиком работает аналитик. Он в ходе работы погружается в предметную область, общается с заказчиками, пользователями, фиксирует функциональную спецификацию и информационную структуру сайта/приложения. Таким образом, процесс проектирования становится более целенаправленным и при ежедневных созвонах с заказчиком — весьма динамичным.
Больше четырех лет я использую вайрфеймы и на мою работу с ними за это время, пожалуй, больше всего повлияли разработчики из EightShapes и проекты Usethics. Спасибо Владу Головачу, что он продолжает делиться своим опытом. И пара моих размышлений.
«Вайрфреймы сковывают графического дизайнера и вообще приводят к шаблонным решениям».
Есть две крайности, с которыми приходиться сталкиваться. В одном случае, в качестве результата работы дизайнера я получаю раскрашенный вайрфрейм, во втором, дизайнер не считается с вайрфреймами и начинает перетасовывать информацию и блоки на свое усмотрение, как правило, попутно удаляя что-то на него взгляд лишнее.
Очевидно, что дизайнер должен уметь работать с вайрфреймами. Хорошо, когда дизайнер является частью команды и участвует в проектировании и обсуждении концепций.
«Удлинить процесс решения/вдохновения»
Вайрфрейм - возможность не только «удлинить» процесс разработки и дать себе время подумать, но и возможность упорядочить взаимоотношения с заказчиком и дать подумать ему.
Во время обсуждения макетов заказчик всегда более вовлечен, чем просто обсуждая проект. Раньше присутствовал страх, что заказчики не поймут, что это им показывают и приходилось по многу раз говорить, что это еще не дизайн и т.д., сейчас же таких трудностей нет. Возможно, мы просто уже не работаем с заказчиками, которые не понимают, зачем нужно макетирование, но хочется думать, что это растет общая грамотность.
«Обеспечить задание на контент»
Очевидная и хорошая идея — задание на контент. Очевидна и причина, почему эта идея хороша — контента как всегда нет. Т.е. перед началом работы контент или в ограниченном объеме, а иногда вообще отсутствует.
Я предпочитаю вайрфреймы, которые содержат максимально реалистичные тексты и со своими максимами и минимумами, т.е. разные по длине особенно для коротких блоков. Практика показывает, что передавая вайрфрейм в дизайн, мы передаем дизайнеру текст, с которым он будет работать. Мы рассчитываем, что будет изменяться визуальная составляющая, но текст чаще всего никогда не меняется.
На мой взгляд, лучшая позиция проектировщика не только прописать формальные ограничения «тут будет заголовок длинной
Проведите конкурс среди участников CMS Magazine
Узнайте цены и сроки уже завтра. Это бесплатно и займет ≈5 минут.
Руководитель отдела проектирования и дизайна в РосБизнесКонсалтинг
Я часто комментирую статьи Влада на сайте юзетикс.ру, данная же статья осталась без внимания только по одной причине — я полностью согласен с подходом, предлагаемым Владом.
Пару моментов из личной практики с налетом бизнеса и управления процессами:
>(в) трудноуловимое свойство, в просторечии называемое «знание жизни»
Зачет! :-)