Глава 4: Атомарная разработка (часть 2)
← Предыдущая часть | Следующая часть →
Перед вами перевод книги Atomic Design Брэда Фроста, разработчика интерфейсов, поклонника мобильного интернета и создателя методики «Атомарный дизайн».
Если вы здесь впервые, то лучше начните сначала.
Преимущества использования коллекций элементов интерфейса
Создание коллекции элементов интерфейса — дело серьезное. Вот, что оно вам дает:
- Все паттерны, а также любые нестыковки будут задокументированы.
Коллекция содержит все уникальные паттерны интерфейса. Воочию наблюдая соседство очень похожих паттернов, вы сможете обнаружить избыточность некоторых из них и утвердиться в намерении создать последовательный, упорядоченный UX.
- Вы сможете рассчитать объем работы.
Коллекция элементов интерфейса поможет определить, сколько усилий потребуется на проектирование и дизайн каждого паттерна интерфейса. Какие элементы относительно легко сделать адаптивными, а какие сложно? Какой контент, дизайн и перспектива развития присущи каждому элементу? Коллекция поможет вам в ходе важных обсуждений внутри команды, а также рассчитать объем работ и сроки.
- Вы заложите прочную основу для рабочей системы дизайна.
Создание коллекции элементов интерфейса — важный первый шаг при разработке обширной библиотеки паттернов. Необходимо задокументировать все существующие паттерны пользовательского интерфейса и определить, какие из них войдут в итоговый вариант системы дизайна. А еще проведение аудита интерфейса поможет выработать единую терминологию, что тоже важно для успеха будущей системы дизайна.
Просите прощения, а не разрешения
Итак, к этому этапу вы должны были обсудить выгоды от создания рабочей системы дизайна с заказчиками и создать коллекцию элементов интерфейса, чтобы продемонстрировать разброд и шатания в нынешнем интерфейсе.
Вот только почему-то, несмотря на все ваши усилия, они по-прежнему не дают этой инициативе добро. Что в такой ситуации вы, как ответственная команда, можете сделать?
Создать систему дизайна без одобрения свыше.
Точно также, как мы по умолчанию работаем над производительностью, доступностью и адаптивностью наших продуктов, мы также должны создавать и системы дизайна. Вам не нужно благословение клиента, чтобы следовать лучшим практикам вашей отрасли. Когда вы даете заинтересованным сторонам возможность сказать «нет», они так и поступают. Поэтому просто не спрашивайте. Наша задача — отлично выполнить работу для клиентов, а система дизайна — средство для достижения этой цели.
Для создания целого нужно создать его части. А интерфейсы как раз состоят из небольших частей, придаете вы им большое значение или нет. Нужно принять решение: сосредоточиться ли исключительно на создании целого, игнорируя части, или потратить время на работу с частями, чтобы более эффективно создавать целое. В своей книге Multiscreen UX Design Вольфрам Нагель замечательно описывает этот подход, используя кирпичики Lego в качестве аналогии.
Один из способов начать работать с проектом, как с Lego, — просто высыпать кирпичики из коробки на стол, закатать рукава и приступить к творчеству.
Подход к проектам, как к конструктору Lego — безусловно жизнеспособная стратегия, даже если она непростительно хаотична. Вам придется иметь дело со свалкой кирпичиков один единственный раз — когда вы будете перебирать ее в поисках нужной детали.
Между прочим, это весьма похоже на то, как работают над многими интернет-проектами. Клиенту нужен веб-сайт — мы бросаемся на его создание. Клиенту нужно мобильное приложение — мы сразу же начинаем проектировать экраны. Наш взгляд сосредоточен на конечном результате, и мы редко (если вообще когда-либо) обращаем внимание на паттерны, которые лежат в основе финальной версии интерфейса.
Но есть и другой способ применения аналогии Lego при работе над проектами. Вместо того, чтобы нырять головой в работу над результатом, вы можете потратить некоторые время на инвентаризацию доступных элементов и организовать их так, чтобы они стали более полезными.
Несомненно, работа по упорядочиванию требует времени, планирования и усилий. Это стоит денег. И вообще, работа над системой в конечном продукте в явном виде не представлена, что может навести на мысль, будто она отвлекает от реальной работы. Так зачем же тратить на это время?
Уделите внимание организации частей, и вы получите более реалистичный, продуманный и эффективный результат. Создав коллекцию всех доступных элементов, вы сможете более методично работать над проектом и сэкономите огромное количество времени. Вместо того, чтобы тратить время, копаясь в огромной куче из всего-всего, или каждый раз заново придумывать паттерны, лучше создать организованную систему компонентов, которая поможет сделать работу лучше и быстрее.
Что же касается ваших клиентов и прочих заинтересованных сторон, то о них не стоит беспокоится, если работа над проектом движется. Покуда они видят прогресс, только от вас зависит, какую часть внутренней кухни показывать. То, что вы разработали систему дизайна для производства конечного продукта, им на самом деле неинтересно. Это всего лишь решение, принятое вашей командой для более эффективной работы.
Если вы имеете дело с заказчиками, ненавидящими инновации — просто делайте то, что считаете нужным, и попросите их не обращать внимание на то, что происходит за сценой. Как только вы успешно запустите проект и откроете шампанское, тогда можете приоткрыть занавес и сказать: «Кстати, мы создали систему дизайна и библиотеку паттернов, чтобы команда могла более эффективно работать и взаимодействовать». Им будет крайне сложно возразить вам, особенно если вы сдали проект в срок и уложились в бюджет. А если повезет, на волне успеха вы сможете провести инициативу дальше и продолжить развивать систему дизайна.
Конечно, было бы здорово, если б ваши клиенты, коллеги и другие заинтересованные лица проголосовали за создание системы дизайна интерфейсов. Ну или хотя бы не возражали против реализации проекта модульным способом. Но в конечном итоге важнее найти способ следовать лучшим практикам отрасли, даже если вы сталкиваетесь с сопротивлением со стороны заказчика.
(Пере)установка ожиданий
Вы приложили много усилий, чтобы «продать» концепцию системы дизайна, однако, вам все равно нужно согласовать ожидаемый результат с заказчиком, прежде чем приступить к работе.
Вообще, речь идет не столько об «формировании ожиданий», а скорее о «изменении ожиданий». Дело в том, что все мы привносим в проект свой собственный опыт, мнение и предубеждения. Наша индустрия все еще невероятно молода, многие люди, работающие над веб-проектами, приходят из других отраслей, где есть свои собственные «Золотые Правила». Даже те, кто работали исключительно в сфере диджитал, тащат за собой багаж из прошлого. И более того: руководящие принципы, лучшие практики и стратегии цифрового дизайна по-прежнему очень запутаны.
Смешно слышать, как произносят фразу «Мы всегда так делали» в индустрии, которой всего-то 25 лет. К сожалению, нам, людям привычки, не нравится выходить из зоны комфорта. Мы не любим, когда нам некомфортно. Но если мы хотим применять передовые практики в передовой отрасли и создавать успешные цифровые продукты, нужно преодолеть себя.
# Так что же такое дизайн?
Мы прошли долгий путь от простой загрузки печатных PDF-файлов во всемирную паутину. Тем не менее влияние полиграфического дизайна все еще ощущается в том, как разрабатывается цифровой дизайн.
Дизайн в мире печати нацелен преимущественно на визуальную эстетику. В конце концов, все, что вы можете делать с плакатом — это смотреть на него. Я ни в коем случае не имею в виду, будто полиграфический дизайн прост или одномерен; мир полиграфии полон нюансов и тонкостей ремесла. Смысл в том, что двунаправленный интерактивный характер интернета добавляет гораздо больше критериев, которым должен отвечать хороший дизайн. Чтобы создать качественный цифровой продукт, нужно учитывать скорость загрузки, размер экрана, инфраструктуру, технические возможности, форм-фактор, эргономику, удобство использования, доступность, контекст и предпочтения пользователя.
Эти дополнительные критерии дизайна важны для создания первоклассных цифровых продуктов, а между тем очень часто наша работа им не отвечает.
Мы продаем сайты, как если бы это были картины. Вместо этого нужно продавать элегантный и легкий доступ к контенту и интерфейс, независимый от устройства, размера экрана или контекста. ~Дэн Молл
Как мы дошли до того, что начали разрабатывать и продавать веб-сайты, как статичные картинки? Когда интернет только появился, мы создавали опыт, предназначенный для потребления исключительно на персональных компьютерах. Это было оправдано, ведь тогда ПК были единственным вариантом выхода в сеть. В то время идея простого переноса PDF-файлов в интернет казалась оправданной и логичной. И какое-то время это действительно работало!
Однако, это имело последствия. Полиграфические истоки интернета укрепили представление, будто веб-дизайн, как и печатные оффлайн-материалы, может и должен выглядеть одинаково на всех устройствах. Из-за этого мы сосредоточили внимание на том, как выглядит веб-дизайн, а не на том, как он работает, упустив из виду многочисленные уникальные характеристики этой новой среды. Укрепилась вера в то, что мы можем применять те же линейные подходы, которые используются при создании полиграфии, и для цифровых продуктов.
Конечно, шло время, появились мобильные устройства, технологии развивались, интернет стал невероятно большой и разнообразной средой. Закончилась эра персональных компьютеров. Их место заняли смартфоны, сотовые, планшеты, фаблеты, нетбуки, ноутбуки, электронные книги, носимые устройства, смарт-тв, игровые приставки, умные панели автомобилей и многое другое.
Разнообразие нынешней веб-среды покончило с иллюзией, будто мы можем слепо заимствовать приемы полиграфического дизайна и переносить их в веб. Просто поставьте компьютер, смартфон и планшет рядом, и вы сразу поймете ошибочность предположения, что веб-дизайн должен выглядеть одинаково на каждом устройстве.
Для нас эпоха бурного роста количества устройств с доступом в интернет только начинается. В скором времени самых разнообразных гаджетов несомненно будет еще больше. Появятся идеи и технологии, которые сейчас еще сложно представить.
Три предыдущих иллюстрации — крайне показательны, они помогут донести до ваших заказчиков сегодняшние реалии. С их осознанием намного проще обновить свой подход к работе и создавать отличные веб-продукты.
Наша задача — создать хороший опыт для людей, которые используют устройства с разными разрешениями, скоростью подключения, функциями, браузерами, типами ввода, форм-факторами, контекстом и настройками. Все эти переменные еще раз подчеркивают необходимость выйти далеко за границы визуальной эстетики при создании систем дизайна интерфейсов.
Такая задача, бесспорно, могла бы стать одним из подвигов Геракла.
Помимо приятного визуального оформления нам стоит:
- Принять, что интернет проник во все сферы жизни, и поэтому необходимо создавать доступные, устойчивые системы дизайна. Миллионы самых разных людей получат доступ к вашему продукту, поэтому пусть ваша система дизайна будет как можно более универсальной.
- Создавать гибкие макеты и компоненты, чтобы ваши интерфейсы хорошо выглядели и прекрасно работали независимо от разрешения устройства или размера экрана.
- Считать производительность одним из основных принципов дизайна, способствовать максимально быстрой загрузке, уважать пользователей и их время.
- Постоянно улучшать интерфейсы. Для этого создавать базовые возможности, а затем совершенствовать их, чтобы задействовать все уникальные возможности современных устройств и браузеров.
- Закладывать запас на будущее. Ваша система дизайна должна выдержать проверку временем и неизбежные перемены, которые произойдут с устройствами и веб-средой.
Все эти изменения в подходе к разработке нужны для грамотной работы с уникальными аспектами цифрового дизайна. Таким образом, наша с вами задача — сформировать правильные ожидания клиентов, коллег и заинтересованных лиц и донести до них, что на этот раз все будет иначе.
# Конец каскадной модели разработки
Знакома ли вам ситуация?
Команде поручено создать веб-сайт. После первого обсуждения задачи, UX-дизайнер уходит поразмыслить и через какое-то время возвращается с огромным PDF-документом, в котором подробно описан весь пользовательский опыт. Этот внушительный документ передается заказчикам, которые после нескольких правок подписывают его.
Затем UX-дизайнер передает документ графическому дизайнеру. Тот открывает Photoshop или Sketch и заполняет эти оторванные от жизни шаблоны цветом, типографикой и текстурой. На очередном собрании заказчики с нетерпением ждут, когда включится проектор, а руководитель проекта принесет распечатанные копии дизайнерской колоды. Выходит арт-директор и представляет получившийся дизайн: «Узрите, вот новый дизайн сайта!» Презентация закончилась, и начались оживленные обсуждения. После того, как первоначальные восторги и комплименты стихли, все ждут, что же скажет главный заказчик.
И тут он говорит, что хотел бы увидеть примерно то же, но, возможно, с другой компоновкой, что-то, что передает иное настроение, может быть стоит использовать другую фотографию или… какую-то штуку, которая просто внезапно появляется. А коль скоро разговор пошел в этом направлении, другие представители со стороны заказчика вдруг осознают, что у них вообще-то тоже есть собственное мнение и конструктивная критика. К концу собрания у каждого есть список правок.
Немного подавленный, но полный решимости довести проект до конца графический дизайнер вносит правки от заказчика. На следующем собрании все повторяется: в целом им все нравится, но хотелось бы немного большего. «Мы почти у цели. Может быть попробовать …»
Проходят недели, месяцы. Напряжение нарастает, сроки начинают поджимать. И вот под влиянием срочности файл homepage_v9_final_на-согласование_FINAL_правки_дляРаздатки.psd наконец-таки согласован заказчиком.
Счастливый, что завершил свою часть работы, дизайнер крадется к кабинету разработчиков. Тихонько подсовывает согласованный макет в щель под дверью, стучит и убегает, крича на ходу: «Все должно быть готово через три недели! Мы уже отстаем от графика, и у нас нет бюджета!»
Фронтенд-разработчик подбирает макет с пола, а дизайнера уже и след простыл. Он просматривает документ, и его охватывает странное чувство — смесь недоумения, злости и ужаса. Что не так с дизайном, спросите вы? Возможно, это семь видов шрифта и девять уникальных стилей кнопок, разбросанных по всему макету. Возможно, макет слишком заточен под рабочий стол компьютера, и его невозможно реализовать. Возможно, это чересчур идеальный контент, якобы созданный пользователями.
Разработчик пытается поделиться озабоченностью с остальной командой, но его обвиняют в профнепригодности или чрезмерной придирчивости. Увы, вносить существенные правки в дизайн слишком поздно, тем более что он уже согласован заказчиком.
И вот несчастный фронтенд-разработчик пытается выжать что-нибудь из статичных макетов: добиться хоть какой-то адаптивности, сгладить наиболее вопиющие нестыковки, упорядочить состояния паттернов (например, разные состояния кнопок), которые не были продуманы и описаны в проекте. А помимо прочего, ему на ходу приходится принимать решения, которые касаются интерактивных аспектов пользовательского опыта. Обсуждения с дизайнерами становятся все напряженнее, но все понимают, что для завершения проекта это необходимо.
И вот, наконец, сайт запущен — после последних отчаянных попыток отполировать содержимое сайта и QA, до которого дело дошло только в последнюю минуту. Никто не произносит вслух, но все чувствуют: вместо радости от завершения проекта в воздухе повисло разочарование. «Живой» сайт не выглядит доведенным до совершенства, как это было обещано заказчику, а недавние трения между членами команды подорвали командный дух.
Надеюсь, эта история покажется вам выдумкой. Однако, исходя из моего опыта и опыта коллег, предполагаю, что и вам довелось пережить нечто подобное. И, вероятно, это не самые приятные воспоминания. Таким образом, важно признать, что каскадная модель разработки в духе Генри Форда в большинстве случаев не поможет вам создать выдающийся цифровой продукт.
Каскадная разработка целесообразна для печати, архитектуры и различных материальных производств, поскольку в этих случаях стоимость ошибок и правок очень высока. Если команда проглядит ошибку на ранней стадии процесса, позднее за нее придется дорого заплатить. Однако, в цифровом мире таких ограничений нет. Пиксели дешевы. Правки можно внести одним кликом, гипотезы быстро протестировать, а дизайн и код использовать снова и снова.
В основе каскадной модели лежит принцип, что работа должна выполняться последовательно: сначала UX-дизайнер делает свою работу, только потом начнется работа над дизайном графическим. Графический дизайнер должен завершить свою часть работы до начала разработки интерфейса.
Это неверный подход. Очень много работы можно и нужно выполнять параллельно. Для создания хорошего пользовательского интерфейса мы должны сформировать правильные ожидания у заказчиков и вовлечь их в более творческий совместный процесс.
То, что работа будет происходить параллельно, не значит, что всем придется размахивать шашками на протяжении всей разработки. Конечно, большая часть исследований, создание информационной архитектуры и других базовых аспектов UX-дизайна должно быть выполнено раньше, чем другие задачи. Но это не причина откладывать начало работы по остальным фронтам. И даже когда большая часть работы специалиста выполнена, он ни в коем случае не покидает проект. Крайне важно, чтобы все специалисты могли продолжать консультироваться друг с другом и убедиться, что их видение совпадает с желаемым конечным результатом.
В отличие от строгой последовательности каскадной модели, ваша командная работа будет выглядеть примерно так:
Разработка — это дизайн
Когда предыдущий работодатель узнал, что я владею HTML, CSS и презентационным JavaScript, они заставили меня пересесть к программистам и бэкенд-разработчикам. До того момента меня постоянно спрашивали: «Эй, Брэд, сколько времени уйдет на разработку этой штуки?» и «Можешь быстренько нормализовать эту базу данных?»
И вот ведь какое дело: я за всю жизнь ни разу не был на уроке информатики, так как чаще болтался в кабинете ИЗО. В общем, эти вопросы ставили меня в неловкое положение.
Бытует серьезное заблуждение, будто кодинг — это супер-сложная разновидность программирования. Но ни HTML, ни CSS не являются языками программирования. Однако, это все же код, поэтому фронтенд-разработку часто причисляют к той же группе, куда относятся Python, Java, PHP, Ruby, C ++ и другие языки программирования. Эта ошибка часто заставляет фронтенд-разработчиков (и меня в том числе) испытывать глубокий личностный кризис.
Очень часто дизайнеры и разработчики (маркетинг и IT, креативщики и технари и т.д.) оторваны друг от друга на организационном уровне. Сидят на разных этажах, в разных зданиях, городах, а иногда даже в разных странах и на разных континентах. Иногда для подобных решений имеются веские причины, но в целом отделение дизайнеров и фронтенд-разработчиков друг от друга — ужасная идея.
Как дизайнеры работают над созданием интерфейсов в Photoshop и Sketch, так и фронтенд-разработчики собирают их с помощью HTML, CSS и презентационного JavaScript. Для создания жизнеспособных систем проектирования UI, крайне важно рассматривать фронтенд-разработку в качестве основы дизайна.
Когда вы показываете заказчикам лишь статические изображения веб-сайтов, они могут прокомментировать и согласовать лишь картинки. Это ведет к ложным ожиданиям. Зато имея возможность продемонстрировать дизайн в браузере как можно раньше, вы своевременно донесете до заказчиков реальное положение вещей. Работа с HTML, CSS и презентационным JavaScript позволяет не просто создавать приятные глазу продукты, а еще и демонстрировать уникальные аспекты цифрового дизайна:
- гибкость
- влияние сети
- интерактивность
- динамику
- эргономику
- рендеринг цветов и текста
- плотность пикселей
- реализацию прокрутки
- особенности при просмотре на разных устройствах и в разных браузерах
- пользовательские настройки
Важно: более быстрый переход в браузер также ускоряет процесс создания паттернов, которые затем войдут в вашу систему дизайна.
Это не значит, что дизайн нужно целиком и полностью разрабатывать в браузере. Как и везде, применяйте инструменты с умом и в нужное время, тогда отличный результат не заставит себя ждать. Если помимо всего прочего вы сможете отсматривать дизайн в браузере, ваша команда создаст более богатую и реалистичную картину пользовательского интерфейса. Видеть эстетически оформленную концепцию дизайна в виде статического изображения и одновременно рабочий прототип той же идеи в браузере — очень полезно.
Итерации, итерации и еще раз итерации
Разработка в сфере цифрового дизайна очень похожа на создание скульптуры из камня. В начале у скульптора и его заказчика есть общее представление о том, что создается, но пока работа не завершена, они видят лишь промежуточные результаты.
Вот скульптор начинает отсекать лишнее от гигантской каменной глыбы. После первого подхода проявляются грубые очертания, а с каждым следующим — фигура становится все более отчетливой. После нескольких таких подходов становится ясно, что это фигура человека.
Когда общая форма скульптуры готова, скульптор начинает работать над деталями. Например, он может начать с лица и проработать форму глаз, носа и рта. Затем он может перейти к рукам, затем детализировать ноги. Периодически художник делает шаг назад, чтобы увидеть, как работа над деталями повлияла на скульптуру в целом.
Этот процесс завершится только тогда, когда скульптура будет готова, и все будут довольны результатами.
Высеченная из камня скульптура — отличная метафора для разработки успешного цифрового продукта. Однако, в отличие от скульпторов у нас есть волшебное сочетание ctrl+Z!
Крайне важно, чтобы заказчики могли отсматривать промежуточные этапы, а не только видеть итоговый результат. В первой главе я писал, что сегодня все компании хотят стать более гибкими, а итерации — это ключ. Гораздо важнее делать шаги в верном направлении, нежели прикладывать колоссальные усилия, расписывая нереалистичные представления о том, каким будет итог. Хорошая система дизайна — не конвейер. Она состоит из циклов итераций, в результате которых по мере продвижения проекта получается нужный результат.
Возможно, все это звучит немного хаотично. Однако, к вящему разочарованию некоторых менеджеров проектов, процесс дизайна не вписывается в аккуратные таблички Excel и диаграмму Ганта. Плодотворное сотрудничество между специалистами на самом деле несколько хаотично, и в этом нет ничего плохого. Но чтобы рабочий процесс был устойчивым, требуется постоянное общение, непрерывный цикл обратной связи и искреннее желание сотрудничать. Убедите команду в важности разговоров начистоту и сотрудничестве, тогда все встанет на свои места.
У вас получилось сформировать у всех правильные ожидания? Отлично! Тогда закатайте рукава, ведь мы приступаем к созданию системы дизайна.
Над переводом работают Ольга Кокоулина и Ринат Шайхутдинов.
Если вам понравился перевод, дайте нам знать — нажмите кнопку Clap в левой части экрана.
Видеокурсы и практика по дизайну интерактивных систем: ux/ui, веб-дизайн и бренд-дизайн
Вас ждет плотная проектная практика по анимации интерфейсов, дизайну сайтов, а также мобильных и веб-приложений. Под руководством наставников в стиле «смотри и повторяй»!
Breezzly — это среда для тренировки digital-навыков. Здесь вы встретите комплекты видеокурсов в актуальных инструментах интерактивного дизайна, среди них Figma, Principle и Invision Studio. А каждый проект — это живой кейс с историей, собранной по горячим следам!
