Итак, мы разобрались с контекстом, ограничениями и способами создания дизайна. Попробуем теперь понять, как выстроить сам рабочий процесс, который плохо поддается формализации и нестабилен по своей сути.
Судите сами: в начале любого дизайнерского проекта у дизайнера в голове своя фантазия о конечном результате, у клиента — своя (или вообще сиреневый туман) и мы, при всем желании, не можем знать, что получится в конце.
Иначе говоря, нечеткие начальные условия на старте, возможны радикальные перестройки в течение работы (ой, это все не то!) и отсутствие четких критериев оценки получившегося дизайна в конце. Понятно, что хочется поставить этот процесс на бизнес-рельсы с предсказуемыми сроками и результатом. Как это сделать?
С критериями мы уже разобрались в одной из предыдущих частей (ограничения в дизайн-процессе: от нехватки и критерия достаточности до чек-листа для оценки результата). Выясним теперь, как из стартовой точки попасть в финальную.
На помощь приходит главный принцип дизайна «проект всегда готов» или метод прогрессивного джипега, описанный в соответствующем § 167 Ководства Лебедева.
Рассмотрим метод подробнее и начнем с небольшого экскурса в историю. В начале 2000-х годов интернет был медленный и дорогой. Его стоимость напрямую зависела от объема загружаемой информации (трафика), поэтому пользователю необходимо было быстро понять, нужно ему то, что он качает или нет, чтобы вовремя остановить загрузку.
Текст весил мало и грузился быстро, а вот скорость загрузки изображения зависела от того, в каком формате оно было сохранено: обычный или прогрессивный джипег.
Слева — обычный джипег, который грузит картинку последовательно, сверху вниз, поэтому не сразу понятно, что на ней изображено, приходится ждать, пока она загрузится. Причем грузится она сразу в максимальном качестве, медленно и в буквальном смысле жрет трафик!
Получается я потратил трафик (деньги), а это ресурс и время на загрузку (интернет то медленный), а это вновь ресурс. Ладно, если результат меня устроит и это будет именно та картинка, которая мне нужна. А если нет? Ресурсы потрачены зря :-(
Чтобы решить эту проблему, придумали прогрессивный джипег. Сохраненная в этом формате картинка грузится сразу целиком, но в очень низком качестве. Взглянем еще раз:
Особенность такого подхода в том, что трафика тратится мало, а загрузка происходит очень быстро. После загрузки первой нечеткой версии по ней проходит, так скажем, некая волна сверху вниз и картинка становится четче. Потом еще волна, картинка еще четче. Число таких проходов можно задавать при сохранении картинки (обычно от 3 до 5).
В итоге, пользователь сам решает, на каком проходе ему остановиться. Например, увидел первую грубую версию картинки, понял, что это не то, что ему нужно и остановил загрузку. Или же ему не хватает информации для принятия решения и он ждет загрузки второго прохода. Процесс контролируется, ресурсы тратятся оптимально.
У Лебедева, кстати, этим же выводом завершается его параграф:
Получается, что время тратится только на нужную степень прожарки, а общий вид стейка всегда ясен.
Мы же пойдем дальше и выясним, как пользоваться методом прогрессивного джипега в реальных проектах. Поможет нам в этом такая штука, как треугольник Серпинского.
Это фигура из четырех секций (одна белая и три черных), где каждый треугольник имеет половину ширины и высоты оригинала. Затем добавляется еще три белых треугольника и каждый из трех внешних треугольников становится уменьшенной версией целого рисунка. Схема повторяется бесконечно.
На что похоже? Правильно, на прогрессивную загрузку картинки: чем больше проходов, тем более детальным становится результат.
В дизайнерском проекте действуем аналогично — разбиваем работу над проектом на несколько итераций и с каждым проходом прорабатываем детали.
Сначала придумываем (как это сделать, увидим дальше) концепцию того, что мы хотим получить в конце. На основании этой концепции делаем первый проход и смотрим, что получилось.
Очевидно, что первый результат будет грубым, «нечетким» и сырым. Зато мы потратили мало ресурсов (денег, времени, сил) на его создание. Полученный черновик обсуждается с клиентом и уточняется вектор дальнейших действий для второго прохода. Результат второго прохода влияет на третий, третий — на четвертый и т. д.
Чтобы понять, как это выглядит на практике, сравним стартовый и финальный варианты дизайна одного из блоков сайта для квеста c доставкой на дом «Holmes First Problem». Особенность этого квеста — «домик»-конструктор, который собирается на протяжении игры.
В первой итерации дизайнер предложил изометрическую подачу «домика». Контурные руки со смартфоном и лупой дополняли композицию, указывая на важные детали квеста, а последующие 3 картинки раскрывали ход игры.
Все изображения в стартовой версии, — первые попавшиеся в поисковике, либо коллажи, собранные на скорую руку. В финальном макете большинство из них были заменены, а те, что изначально хорошо подошли по смыслу — доработаны. Но главное, что подача в этом блоке осталась неизменной.
Подведем промежуточный итог. Используя принцип «проект всегда готов» мы с самого начала понимаем, что будет в конце. Работа над проектом идет короткими эффективными итерациями, а нужный результат достигается через серию подходов. Процесс легко контролируется, по ходу гибко подстраиваясь под возможные изменения.
Принцип универсален и может применяться на разных уровнях. А что это за уровни, разберем в следующей части статьи.
