Данная статья является переводом оригинальной - "Chapter 1. Designing Systems" автора Бреда Фроста (Brad Frost)
От дизайнера Айрата Хабибрахманова
Данная статья была переведена исключительно для расширения понимания другой статьи - Методология атомарного дизайна. Поэтому после ознакомления с этой статьей рекомендую перейти к изучению упомянутой выше.
Вот рекомендуемый порядок изучения:
- Что такое Дизайн-системы? (текущая статья)
Создавайте дизайн-системы, а не просто страницы
В далекие-далекие времена существовали такие вещи, назывались они книгами. Вы их помните? Эти приспособления были тяжелыми, громоздкими и изготавливались они из мякоти мертвых деревьев! Они содержали в себе такие штуки, как страницы. Переворачивая одну за другой страницу вы подвергали себя опасности, ведь могли порезать свои незащищенные и хрупкие пальчики.
Ужасные вещи. Я так рад, что эти книжные штуки с их бритвенно-острыми страницами больше не существуют.
Хотя, погодите-ка...
Наше страничное прошлое
Понятие "страница" существует уже очень давно. Точнее, несколько тысячелетий. Первые книги появились около 4 тыс. лет назад в виде толстых глиняных плит, которые вскоре были заменены свитками в качестве предпочтительного способа потребления письменного слова. И хотя технологии чтения прошли долгий путь - от папируса до пергамента, от мягкой обложки до пикселей, - концепция страницы остается актуальной и по сей день.
Метафора страницы вошла в лексикон интернета с самого начала. Тим Бернерс-Ли изобрел Всемирную паутину, чтобы он, его коллеги из ЦЕРН и другие ученые могли легко обмениваться документами и связывать их воедино. Именно поэтому концепция страницы, основанная на документах, так глубоко вошла в лексикон Интернета.
И что же?
Как мы будем обсуждать на протяжении этой книги (данная статья = первая глава книги), способ, которым что-то называется, сильно влияет на то, как это воспринимается и используется. Мышление о вебе как о страницах имеет реальные последствия для взаимодействия людей с веб-пространством и влияет на то, как мы создаем веб-интерфейсы.
С самого начала, метафора страницы предоставила пользователям знакомый язык для того, чтобы они могли ориентироваться в этом новом мире Всемирной Паутины. Такие понятия, как добавление в закладки и пагинация, помогли новым пользователям изучить и, в конечном итоге, освоить совершенно новую среду, используя привычные им понятия.
Страница была - и продолжает быть - очень заметной и полезной метафорой для пользователей веба. Она также оказывает глубокое влияние на то, как создаются веб-приложения.
На заре становления Интернета компании, стремящиеся выйти в Сеть, просто переносили свои печатные материалы на веб-сайты. Но даже несмотря на то, что эти сайты-брошюры давали очень одномерное представление о том, что может предложить Интернет, создатели легко воспринимали сайты как цифровое представление печатной страницы.
Но вот уже 25 лет, как мы живем в новой среде, и эта некогда необходимая фигура речи исчерпала себя. К сожалению, метафора страницы продолжает глубоко влиять на то, как мы определяем и выполняем наши веб-проекты. Вот лишь несколько примеров, которые я слышу регулярно:
- "Мы - стартап, который собирается запустить пятистраничный сайт в октябре этого года..."
- "Брэд, сколько времени займет создание главной страницы?"
- "Как мы вообще собираемся переделывать этот университетский сайт, содержащий более 30 000 страниц?!"
Во всех приведенных выше высказываниях содержится фундаментальная ошибка, заключающаяся в том, что страница - это однородная, изолированная, количественно измеримая сущность. Реальность такова, что Интернет - это текучая, интерактивная, взаимозависимая среда передачи информации. Как только мы осознаем этот факт, понятие "страница" быстро перестает быть полезным средством для определения и создания веб-опыта.
Сколько времени займет создание главной страницы? Ну, это зависит от того, что на ней находится, верно? Может быть, главная страница состоит просто из теглайна и фонового изображения, что означает, что она может быть сделана к обеду. А может быть, она изобилует каруселями, динамическими формами и интеграциями со сторонними разработчиками. В этом случае на создание главной страницы может уйти несколько месяцев.
Что касается университетского сайта объемом 30 000 страниц, то может возникнуть соблазн заявить: "Тысячи страниц?! Ничего себе, звучит сложно!". Но в действительности эти 30 000 страниц могут состоять из трех типов контента и двух общих макетов.
В конечном счете, уровень трудоемкости проекта гораздо лучше определяется функциональностью и компонентами, содержащимися на этих страницах, а не количеством самих страниц.
Метафора страницы сослужила свою службу, помогая пользователям освоиться в Сети, и дала создателям необходимый переходный язык, на котором они могли бы творить для совершенно новой среды. Но для создания продуманных интерфейсов, предназначенных для множества подключенных устройств, пришло время выйти за рамки "страницы".
Разрывая страницу...
К счастью, веб-сообщество активно работает над созданием принципов и практик, помогающих нам эффективно обсуждать и создавать веб-приложения. И есть одна концепция, которая постоянно всплывает в каждом разговоре о том, как создать успешный веб-опыт: это модульность.
Модульность появилась задолго до появления Интернета. Промышленная революция привела к появлению взаимозаменяемых деталей, а сборочный конвейер Генри Форда навсегда изменил процесс производства автомобилей. Первые автомобили и их компоненты изготавливались по отдельности, что приводило к многочисленным кошмарам безопасности и ремонтопригодности. Форд разделил автомобиль на составные части и унифицировал процесс сборки. Результаты говорили сами за себя: с завода выходили более унифицированные, более надежные и безопасные автомобили, причем в рекордно короткие сроки.
Когда век машин сменился веком компьютеров, ученые-компьютерщики начали практиковать объектно-ориентированное программирование и устанавливать такие важные модульные концепции, как разделение задач и принцип единой ответственности. Именно из этого мира родилась Всемирная паутина, поэтому неудивительно, что модульный дизайн быстро стал принципом проектирования архитектуры Интернета.
Медленно, но верно эти концепции проникали в рабочие процессы веб-дизайнеров. В начале 2000-х годов появились такие библиотеки, как YUI и jQuery UI, которые предоставили разработчикам набор виджетов и шаблонов для создания более последовательных пользовательских интерфейсов.
Если модульность существует так давно, то почему мы говорим о ней сейчас?
Короткий ответ заключается в том, что модульность важна как никогда. В настоящее время вся наша индустрия тонет в море устройств, размеров экранов и онлайн-сред. И в ближайшем будущем ситуация не изменится.
Процесс изменения будет только ускоряться. Количество и разнообразие подключенных устройств - многие из которых мы еще не представляем - будет расти, как и количество и разнообразие людей во всем мире, которые их используют. Существующие стандарты, рабочие процессы и инфраструктура не выдержат. Сегодняшний натиск устройств уже подталкивает их к пределу прочности. Они не выдержат того, что их ждет впереди. // из Манифеста "Дружественное будущее"
Нравится нам это или нет, но многоплатформенный мир - это наша реальность. Было достаточно сложно добиться стабильного отображения веб-страниц в нескольких браузерах для настольных компьютеров, но сейчас нам поручено обеспечить красивый внешний вид и функциональность нашего веб-пространства на огромном количестве смартфонов, планшетов, фаблетов, нетбуков, ноутбуков, настольных компьютеров, телевизоров, игровых приставок и многом другом.
Чтобы справиться с этой реальностью и при этом сохранить рассудок, нам совершенно точно необходимо сделать шаг назад и разбить эти гигантские обязанности на более мелкие и управляемые куски.
Именно этим и занимаются специалисты. Дух модульности проникает во все аспекты процесса создания веб-сайтов и оказывает глубокое влияние на стратегию, процессы, контент, дизайн и разработку организаций.
Управляемая стратегия
Все организации наконец-то осознают, что сносить свой веб-сайт и заменять его новым блестящим каждые 3-8 лет не является (и никогда не являлось) оптимальным решением.
"Долой старое! Да здравствует новое!" - это, конечно, привлекательная перспектива. Но еще до того, как конфетти на вечеринке по случаю запуска сайта будут разбросаны, начнут поступать звонки. Пользователи, потратившие годы на освоение прежнего интерфейса и функциональности, кричат: "Вы переложили мой сыр!
В случае, когда запускаются масштабные переработки с существенными изменениями в пользовательском опыте, пользователи оказываются на пути, который Джаред Спул называет "волшебным эскалатором приобретенных знаний". Огромный редизайн системы сильно сбивает с толку пользователей, и вновь разочарованные пользователи вынуждены тратить много времени и сил на то, чтобы заново освоить систему и медленно подниматься по эскалатору приобретенных знаний.
Кроме того, такие монолитные переработки не решают корневых проблем в организации. Без фундаментальных изменений в процессе, история обречена повторяться, и то, что сегодня является новым и современным, завтра станет устаревшим и неудобным. Этот цикл повторяется, когда компании откладывают незначительные обновления до следующей большой переработки, в конечном итоге парализуя себя и разочаровывая пользователей.
К счастью, даже крупные организации берут пример с небольших стартапов и стремятся быстрее выпускать свои продукты. Создавая минимально жизнеспособные продукты (MVP) и выпуская их часто с целью итеративного улучшения опыта, организации могут лучше учитывать отзывы пользователей и следить за постоянно меняющейся веб-средой.
Переход от редизайна по принципу Рона Поупила "поставил и забыл" требует целенаправленных изменений в организационной структуре и рабочем процессе. А это гораздо легче сказать, чем сделать.
Итеративный процесс
Если бы мне платили каждый раз, когда я слышал от закачиков или стейкхолдеров фразу: "Мы стараемся быть более гибкими", я бы уже бороздил просторы космоса на своем собственном космическом корабле, а не писал эту книгу.
Желание быть более гибкими - это, конечно, похвально, но agile - это многозначный термин, и между Agile (с большой буквы) и agile (с маленькой буквы) имеются большие различия.
- Agile - это конкретная методология разработки программного обеспечения, снабженная манифестом и сопутствующими фреймворками, такими как Scrum и Lean.
- А вот agile (с маленькой буквы) - это скорее неформальное стремление к созданию эффективного процесса. Это стремление, безусловно, может включать в себя принятие общих принципов из Agile, но оно также может и не включать в себя принятие Agile-процесса в полном объеме.
Вот как об этом отзывается руководитель проекта Бретт Харнед:
Мы хотим быть более гибкими; мы принимаем изменения, продолжаем совершенствоваться, быть максимально гибкими и адаптироваться по своему усмотрению. Дело в том, что мы никогда не станем по-настоящему Agile, как говорится в Манифесте. И это нормально, если мы говорим, кем мы будем. - Бретт Харнед
Организационная структура, отношения с клиентами, личные качества и т.д. - все это играет важную роль в определении процесса реализации проекта. Сложность заключается в том, чтобы найти процесс, который будет наилучшим образом работать для вас, ваших организационных ограничений и возможностей.
Несмотря на то, что внедрить целиком и полностью Agile-процесс невозможно, все же целесообразно работать в междисциплинарных командах, быстрее переходить к окончательному варианту, рано и часто выпускать продукт и разбивать большие задачи на более мелкие компоненты. В главе 4 (ссылка на оригинальный источник) мы подробно рассмотрим, как организовать эффективный рабочий процесс на основе шаблонов.
Модулирование контента: "Я в команде Чанка!"
Раньше публикация контента для Web была довольно простым делом, поскольку web был "единственным игроком в поле". Но все изменилось. Сегодня наш контент потребляется множеством смартфонов, телефонов, нетбуков, ноутбуков, планшетов, электронных читалок, умных часов, телевизоров, игровых приставок, цифровых табло, приборных панелей автомобилей и т.д.
Чтобы правильно работать с этим все более разнообразным цифровым ландшафтом, нам необходимо кардинально пересмотреть свое представление о контенте и инструментах, используемых для управления им.
В будущем, как я полагаю, у нас появятся более совершенные инструменты управления контентом и его публикации. У нас появятся способы получения хорошо структурированного контента, хорошо продуманных фрагментов контента, которые затем можно будет реструктурировать, опубликовать и отобразить таким образом, чтобы они идеально подходили для соответствующей платформы. - Карен МакГрейн
И это будущее уже наступает. Организации осознают необходимость создания модульного контента для более эффективного охвата аудитории, где бы она ни находилась. А системы управления контентом выходят за рамки своей платформы веб-публикации и превращаются в инструменты, способные элегантно создавать и поддерживать модульный контент. Хотя сложные системы управления контентом существуют уже много лет в виде специализированных решений, таких как платформа COPE (Create Once, Publish Everywhere - Создайте один раз, Опубликуйте везде) компании NPR, разумное модульное мышление пробивает себе дорогу в основные системы управления контентом.
Стандартный код
Как мы уже говорили, модульность уже давно является одним из основных принципов в мире компьютерных наук. Хотя этот принцип существовал задолго до изобретения Интернета, потребовалось некоторое время, чтобы модульность укоренилась в умах и сердцах веб-разработчиков.
Несмотря на то, что JavaScript, язык программирования для Интернета, существует с 1995 года, ему пришлось пройти через некоторые трудности роста, чтобы превратиться в тот способный и уважаемый язык, которым он является сегодня. Теперь, когда JavaScript повзрослел, разработчики могут применять эти проверенные временем принципы информатики в своих процессах веб-разработки. В результате мы видим, как разработчики создают сложные паттерны и архитектуры JavaScript.
Применение принципов модульного программирования к JavaScript не вызывает сомнений, поскольку JavaScript сам по себе является языком программирования. Но объектно-ориентированное мышление прокладывает себе путь и в другие аспекты Web, включая CSS, язык стилей для Web. Появились такие методологии, как OOCSS, SMACSS и BEM, которые помогают веб-дизайнерам создавать и поддерживать модульные CSS-архитектуры.
Визуальная правка
Модульность не только проникает в кодовую часть стиля в Интернете, но и революционизирует подход визуальных дизайнеров к современному веб-дизайну.
По мере увеличения количества видовых экранов и сред, стало неприемлемым создавать статические макеты каждой страницы веб-опыта. Как отметил Стивен Хей, представление полностью готовых композиций в Photoshop "самый эффективный способ показать клиентам, как никогда не будет выглядеть их веб-сайт.
Это не значит, что инструменты статического дизайна, такие как Photoshop и Sketch, не важны. Это далеко не так. Но то, как мы используем эти инструменты, претерпело значительные изменения. В то время как создание сотен полномасштабных композиций не представляется реальным, эти статичные инструменты позволяют создать площадку для того, что Энди Кларк называет "атмосферой дизайна":
Атмосфера описывает те чувства, которые вызывают у нас цвет, текстура и шрифт. Возможно, вы уже представляете себе атмосферу в других терминах. Можно назвать ее "чувством", "настроением" или даже "визуальной идентичностью". Какие бы слова вы ни выбрали, атмосфера дизайна не зависит от компоновки. Она не зависит от компоновки и визуального размещения. Она будет видна или ощутима при любом размере экрана и на любом устройстве.
Установка атмосферы дизайна на ранней стадии критически важна для успешности проекта, поэтому дизайнеры нашли способы облегчить эти важные обсуждения, не создавая полномасштабных макетов. Дизайнер Саманта Уоррен разработала дизайнерские артефакты, называемые плитками стиля, которые демонстрируют исследования цвета, типа и текстуры в виде красивого сайта-одностраничника. Дизайнер Дэн Молл развил идею Саманты с концепцией, называемой коллажами элементов, которые демонстрируют исследования атмосферы дизайна во взрывном коллаже элементов интерфейса.
Разбивая визуальные исследования на более мелкие фрагменты, дизайнеры экономят время и силы, избегая демонстрации заказчикам нереалистичных, преждевременных макетов. Что еще более важно, такие подходы позволяют заинтересованным сторонам не просто реагировать на красивую картинку, а проводить важные беседы об общем направлении дизайна и его взаимосвязи с целями проекта. Более подробно мы рассмотрим эти концепции в главе 4, но достаточно сказать, что рабочий процесс в области визуального дизайна претерпевает значительные изменения!
Систематический дизайн интерфейса
Мы не дизайнеры страниц, мы дизайнеры систем компонентов - Стивен Хей
Из чего состоит интерфейс? Какие у нас кирпичики Lego? Какие у нас кусочки Subway сэндвича, которые мы комбинируем в миллионы вкусных комбинаций? Именно эти вопросы мы все чаще задаем себе сейчас, когда отправляем наши интерфейсы во все новые и новые места.
Несколько лет назад Этан Маркотт познакомил нас с идеей отзывчивого веб-дизайна и тремя его основными постулатами: плавными сетками, гибким медиа и медиазапросами CSS. Эти три составляющие заложили столь необходимую дизайнерам основу для создания гибких макетов, умело адаптирующихся к любому размеру экрана. Что еще более важно, отзывчивый дизайн помог дизайнерам увлечься созданием продуманного, адаптируемого к различным устройствам веб-опыта.
Как быстро обнаружили дизайнеры, создание веб-интерфейса для множества устройств - это не просто создание "мягких" страниц. Каждый отдельный элемент интерфейса содержит свои собственные уникальные задачи и возможности для того, чтобы он прекрасно выглядел и функционировал на экранах разных размеров и в разных средах.
Как мы можем представить основную навигацию – обычно отображаемую как горизонтальный список на больших экранах – вдумчивым образом на меньших экранах? Как лайтбоксы, хлебные крошки и карусели переводятся на меньшие видовые экраны и альтернативные типы ввода? Это вопросы, которые привели меня к созданию "This Is Responsive" - витрины отзывчивых шаблонов, демонстрирующих различные способы реализации того или иного компонента в отзывчивой среде.
Хотя "This Is Responsive" успешно демонстрирует, как эти паттерны интерфейса могут масштабироваться в зависимости от размера экрана и среды использования - воплощать их в жизнь должны дизайнеры и разработчики. И, как оказалось, это очень сложная работа.
Фреймворки пользовательского интерфейса в теории и на практике
Дизайнеры и разработчики и так ограничены во времени и ресурсах, а теперь перед ними ставится задача создания интерфейсов, которые будут прекрасно выглядеть и функционировать в любой среде. Это очень сложная задача.
Необходимость решать проблему растущего разнообразия устройств и при этом разумно реализовывать проекты привела к появлению таких фреймворков, как Foundation от Zurb и Bootstrap. Эти фреймворки предоставляют дизайнерам набор готовых шаблонов HTML, стилей CSS и JavaScript для добавления функциональности интерактивным компонентам, таким как выпадающие окна и карусели. По сути, эти фреймворки представляют собой удобные наборы инструментов для быстрой сборки интерфейсов.
И как же они популярны. На момент написания этой статьи Bootstrap является самым популярным репозиторием на сайте обмена кодами GitHub, имеющим более 77 000 звезд и 30 000 форков. Популярность этих фреймворков свидетельствует о том, что дизайнеры и разработчики ищут твердую почву для опоры в этом постоянно усложняющемся веб-пространстве.
Одним из наиболее привлекательных аспектов этих фреймворков является скорость. Такие фреймворки, как Bootstrap, позволяют дизайнерам быстро реализовывать свои идеи, быстро создавать прототипы и быстрее запускать сайты. Поскольку шаблоны, предоставляемые набором инструментов, уже протестированы на кроссбраузерность, разработчики могут потратить свое время на более важные задачи, а не биться головой об стол, тестируя какую-нибудь архаичную версию Internet Explorer. А если дизайнеры все же застрянут, то сообщества разработчиков этих фреймворков могут оказать им полезную поддержку и дать совет.
Для фрилансеров такое увеличение скорости работы может означать, что они смогут взять на себя дополнительный проект или несколько таковых, что обеспечит большую финансовую стабильность. А в мире стартапов, где Bootstrap присутствует повсеместно, минимально жизнеспособные продукты (MVP) могут быть запущены раньше, что позволяет быстрее получить ответы на вопросы о жизнеспособности продуктов.
Таким образом, фреймворки, подобные Bootstrap, являются безумно популярными системами проектирования, которые предоставляют хорошо проверенные компоненты, что приводит к согласованности дизайна и более быстрому запуску. Но, как и во всем, что происходит в жизни, наряду с плюсами есть и минусы.
Проблемы в райском месте фреймворков
Когда я был ребенком, я смотрел научно-фантастические фильмы и телепередачи со странным увлечением. Меня не покидал один вопрос: почему все они одеты одинаково?
Мне оставалось только догадываться, что при достаточном количестве времени мы решаем проблему моды. "Скажем, эти комбинезоны очень стильные, и к тому же удобные! Давайте с сегодняшнего дня все будем носить их". "По-моему, неплохо!"
Конечно, люди устроены по-другому. У всех нас разные вкусы, цели и желания. Разнообразие, как говорится, приправа жизни, а мода, музыка и дизайн отражают нашу многогранную природу. Однако в Интернете мы часто попадаем в ловушку, когда хотим, чтобы все делали одинаково. "Почему бы всем браузерам просто не стандартизировать WebKit?" "Почему производители устройств не могут просто использовать одинаковые размеры экранов?" "Всегда используйте jQuery!" "Никогда не используйте jQuery!" "Просто используйте фреймворки!" "Никогда не используйте фреймворки!"
Как и в реальном мире, разнообразные потребности, цели и желания веб-проектов приводят к появлению огромного количества различных решений. Конечно, для всего есть свое время и место, и дизайнерам и разработчикам нужно быть разборчивыми, чтобы знать, какие инструменты использовать и когда.
Фреймворки - это инструменты, обеспечивающие конкретное решение и определенный внешний вид. Хотя такие решения помогают ускорить разработку, в итоге получаются эффекты, напоминающие фантастические комбинезоны. Когда все используют одни и те же кнопки, сетки, выпадающие окна и компоненты, все, естественно, начинает выглядеть одинаково. Если бы компании Nike, Adidas, Puma и Reebok перепроектировали свои сайты с использованием Bootstrap, они бы выглядели очень похожими. А это, конечно, не то, к чему стремятся эти бренды. Конечно, каждый бренд может модифицировать и расширять стандартный внешний вид и функциональность, но через некоторое время кастомизация означает борьбу с заданной структурой, стилем и функциональностью фреймворка.
Помимо проблем с внешним сходством, эти фреймворки могут создавать ненужный объем данных. Это замечательно, что фреймворки предоставляют множество готовых компонентов и функциональных возможностей, но значительная часть дизайнеров и разработчиков не будет использовать все аспекты фреймворка. К сожалению, пользователям все равно приходится загружать неиспользуемые CSS и JavaScript фреймворка, что приводит к замедлению загрузки страниц и разочарованию.
С другой стороны, фреймворки могут оказаться недостаточно эффективными, в результате чего разработчикам придется создавать значительное количество собственного кода для достижения целей своих проектов. В какой-то момент наступает порог, когда первоначальные преимущества использования фреймворка, а именно скорость разработки, перевешиваются временем, затрачиваемым на модификацию, расширение и исправление фреймворка.
А затем возникает проблема с именованием. Использование фреймворка означает подчинение чужой структуре, именованию и стилевым соглашениям. Конечно, важно установить полезный лексикон для фронтенд, но то, что имеет смысл для организации, может не совпадать с тем, что выходит из коробки фреймворка. Я, например, возмутился бы идеей использования стандартного компонента Bootstrap для области с особо важным контентом, которую они называют "jumbotron". Прежде чем сесть на поезд фреймворка, следует как следует обсудить, как его соглашения об именовании сочетаются с существующей кодовой базой и рабочим процессом.
Теперь, когда мы проверили фреймворки на прочность, важно сделать шаг назад и понять, что с концептуальной точки зрения эти фреймворки очень хороши. Это отличная идея работать с набором инструментов для дизайна, который обеспечивает консистентность и ускоряет время разработки. Обсуждая переоформление домашней страницы Microsoft веб-студией Paravel из Остина, разработчик Дейв Руперт подчеркнул важность создания и предоставления системы дизайна их клиенту. Дейв замечательно выразился, что речь не обязательно идет об использовании Bootstrap для каждого клиента, а скорее о создании "маленьких Bootstrap для каждого клиента".
Отзывчивые продукты должны выглядеть как полноценные системы в стиле Twitter Bootstrap, адаптированные под нужды клиента. Эти живые примеры кода представляют собой самодокументирующиеся руководства по стилю, расширяющиеся в соответствии с потребностями клиента и постоянно развивающейся веб-средой с несколькими устройствами. - Дэйв Руперт
Речь идет не просто об использовании готовой дизайн-системы, а о создании своей собственной.
Дизайн-системы спасают положение
Как же выглядят надежные дизайн-системы? Какую форму они имеют? Как их создавать, поддерживать и внедрять?
Основой хороших систем дизайна являются стайл-гайды, которые документируют и организуют материалы дизайна, предоставляя рекомендации, правила использования и ограничения.
Как водится, существует множество разновидностей руководств по стилю, включая документацию по фирменному стилю, написанию, голосу и тону, коду, языку дизайна и шаблонам пользовательского интерфейса. В этой книге (напоминаю, что данная серия статей основана на книге) не будут подробно описаны все категории руководств по стилю, но важно рассмотреть каждую из них, чтобы лучше понять, как каждое руководство по стилю влияет на другие, и как руководства по стилю для Интернета вписываются в более широкую экосистему.
Фирменный стиль
Рекомендации по фирменному стилю определяют активы и материалы, которые делают компанию уникальной. Логотипы, типографика, цветовая палитра, сообщения (например, формулировки миссии и теглайны), сопутствующие материалы (например, шаблоны визитных карточек и PowerPoint) и многое другое - все это обобщается и описывается в рекомендациях по фирменному стилю.
Бренду необходимо представлять себя целостным образом во все большем количестве средств массовой информации, каналов и точек соприкосновения. Как сделать так, чтобы все сотрудники организации говорили в один голос и чувствовали себя частью единого целого? Как третьи лица узнают, какие цвета Pantone следует использовать и как правильно применять логотип бренда? Руководство по фирменному стилю дает ответы на эти фундаментальные вопросы в одном централизованном узле.
Исторически сложилось так, что руководства по фирменному стилю содержались в книгах в твердой обложке (помните, такие книги со страницами?), но, как и во всем остальном, руководства по фирменному стилю переходят в онлайн-формат.
Язык дизайна
Если руководство по фирменному стилю достаточно осязаемо, то руководство по языку дизайна определить несколько сложнее. Руководства по стилю языка дизайна формулируют общее направление дизайна, философию и подход к конкретным проектам или продуктам.
Для того чтобы представить себя в растущем ассортименте продуктов и средств массовой информации, компания Google разработала язык дизайна, получивший название Material Design. Руководство по стилю Material-дизайна определяет общую философию дизайна, цели и общие принципы, а также дает конкретные примеры применения языка Material-дизайна.
Руководства по языку дизайна могут включать (и обычно включают) аспекты других категорий руководств по стилю, чтобы сделать высокоуровневые концепции более осязаемыми.
Руководства по языку дизайна не являются незыблемыми, как руководства по брендам. Например, однажды компания Google, вероятно, разработает новый язык дизайна, который заменит Material-дизайн, поэтому, хотя бренд Google в целом останется неизменным, лексика дизайна ее продуктов изменится.
Голос и тон
Люди взаимодействуют с брендами по огромному количеству каналов и средств массовой информации. Помимо цифровых СМИ, которые мы уже упоминали, бренды также работают в печатных изданиях, розничной торговле, наружной рекламе, на радио, телевидении и в других каналах. Когда бренду приходится общаться в таком большом количестве разнообразных точек соприкосновения, единая, последовательная манера изложения становится критически важной для его успеха.
Голос - это неотъемлемый аспект идентичности бренда, поэтому, как правило, в руководствах по фирменному стилю содержится определенная ссылка на голос бренда. Однако эти рекомендации обычно не содержат особых нюансов, поэтому так важны рекомендации по голосу и тону.
Рекомендации по голосу и тону позволяют разобраться в тонкостях, определяя, как должен меняться голос и тон компании в различных сценариях. Великолепные рекомендации MailChimp по голосовым и тональным характеристикам определяют, как меняется тон бренда в различных типах контента, так что, когда пользователю отказывают в выдаче кредитной карты, авторы знают, что нужно отказаться от своего обычно веселого и игривого тона и перейти на более серьезный тон.
Письмо
Возникновение Веба и сайтов с управляемым контентом значительно упрощает публикацию контента для многих сотрудников организации. Однако это может быть и двухсторонним мечом, так как поддержание последовательного стиля письма для организации со множеством голосов может быть сложной задачей. Руководства по стилю письма предоставляют каждому автору некоторые руководства и ограничения для создания контента.
Руководства по стилю написания текстов могут быть очень подробными, определяя особенности пунктуации и грамматики, но они не всегда должны быть такими подробными. Руководство по стилю написания текстов Университета Далхаузи представляет собой краткий перечень принципов и лучших практик, которым должны следовать авторы материалов.
Руководства по стилю кода
Для команд очень важно писать разборчивый, масштабируемый и поддерживаемый код. Но если нет способа поощрения и обеспечения согласованности кода, то все легко может развалиться и каждый разработчик останется один на один с собой.
Руководства по стилю кода содержат соглашения, шаблоны и примеры того, как команды должны работать с кодом. Эти рекомендации и ограждения помогают сдержать безумие, чтобы команды могли сосредоточиться на совместной работе, а не на рефакторинге кучи неаккуратного, несогласованного кода.
Библиотеки паттернов
И вот главная для нас часть. Паттерн-библиотеки (также известные как стайл-гайды фронтенда, библиотеки пользовательского интерфейса или библиотеки компонентов) быстро становятся основой современного дизайна интерфейса.
Остальная часть книги (напоминаю, что данная серия статей основана на книге) будет посвящена систематическому подходу к проектированию интерфейсов, а также созданию и сопровождению библиотек паттернов.
Преимущества руководства по стилю
Обеспечить работу пользовательского интерфейса на множестве экранов разных размеров, устройств, браузеров и сред - задача не из легких. Но если учесть других членов команды, клиентов, стейкхолдеров и организационные особенности, то ситуация становится просто пугающей.
Руководства по стилю - это важный инструмент, который помогает избежать хаоса как с точки зрения дизайна и разработки, так и с точки зрения организации. Вот почему руководства по стилю стали неотъемлемым инструментом современного веб-дизайна и разработки.
Неизменно великолепный
Руководства по веб-стилю обеспечивают согласованность и единство пользовательского интерфейса. От такой согласованности выигрывают как те, кто создает эти интерфейсы, так и их пользователи.
Недавно я зашел на сайт своей страховой компании, чтобы оплатить счет. В течение пяти щелчков мышью я столкнулся с четырьмя различными дизайнами интерфейса, некоторые из которых выглядели так, как будто к ним последний раз прикасались в 1999 году. Такое непоследовательное восприятие возложило на меня, пользователя, бремя выяснения того, что где находится и как интерпретировать разрозненные элементы интерфейса. Когда я дошел до формы оплаты, мне показалось, что я не могу доверять компании в том, что она успешно и безопасно обработает мой платеж.
Руководства по стилю помогают устранить эти несоответствия, поощряя повторное использование элементов интерфейса. Дизайнеры и разработчики могут обратиться к существующим шаблонам, чтобы убедиться в том, что их работа соответствует уже созданным образцам.
Даже сторонние разработчики, отвечающие за соответствие своих пользовательских интерфейсов внешнему виду и внутренним интерфейсам компании, могут с успехом использовать руководство по стилю. Внешние интерфейсы, такие как платежные порталы или локализованные сайты, могут лучше соответствовать внешнему виду основного интерфейса за счет применения стилей, определенных в руководстве.
Если сделать руководство по стилю центральным элементом процесса, то пользовательские интерфейсы станут более едиными и надежными, что поможет пользователям быстрее выполнять свои задачи и даст им возможность овладеть интерфейсом.
Общий словарь
Что означает "панель инструментов утилиты"? Все ли понимают, что такое "герой сенсорного слайдера"?
При увеличении количества людей, работающих над проектом, очень легко возникают сбои в коммуникации. Нередки случаи, когда в разных дисциплинах один и тот же модуль называется по-разному, а отдельные специалисты придумывают собственные соглашения по наименованию. Для настоящего сотрудничества необходимо, чтобы команды говорили на одном языке. Руководства по стилю призваны помочь в создании такого общего словаря.
Руководства по стилю устанавливают единую терминологию для всех участников проекта, способствуя сотрудничеству между дисциплинами и сокращая количество сбоев в коммуникации.
Обучение
В своей книге Front-End Style Guides Анна Дебенхем ловко объясняет многочисленные преимущества создания руководств по стилю, включая одно из самых важных: обучение.
Обучение так же важно, как и документирование. Руководство по стилю может показать клиентам, что сайт - это система, а не набор страниц. - Анна Дебенхэм
Руководства по стилю демонстрируют клиентам, заинтересованным сторонам и представителям других дисциплин, что в процессе разработки и создания сайта была проделана большая вдумчивая работа, а не просто "Эй, давайте сделаем новый сайт". Библиотека паттернов передает язык дизайна в очень осязаемой форме, что помогает заинтересованным сторонам понять, что конечный интерфейс определяется базовой системой.
Руководства по стилю могут помочь смягчить то, что я называю "синдромом снежинки", когда некоторые отделы организации считают, что у них уникальные проблемы, и поэтому требуют уникальных решений. Раскрывая систему дизайна в виде руководства по стилю, эти "особые снежинки" могут лучше оценить последовательность и понять, почему их запросы на индивидуальный дизайн вызывают отторжение.
Эмпатичный рабочий процесс
Обучение важно не только для клиентов и заинтересованных сторон. Хорошее руководство по стилю помогает информировать дизайнеров и разработчиков об инструментах, которые они имеют в своем арсенале, а также предоставляет правила и лучшие практики их правильного использования.
Если сделать руководство по стилю краеугольным камнем рабочего процесса, дизайнеры и разработчики будут вынуждены задуматься о том, как их решения влияют на всю систему дизайна в целом. Становится труднее действовать нестандартно и легче думать о благе. А это именно то место, где вы хотите видеть членов команды.
Руководство по стилю дает возможность каждой дисциплине высказать свои соображения и соображения по поводу паттернов. Собирая все эти соображения под одной крышей, руководство по стилю становится центром для всех участников проекта, что помогает каждой дисциплине лучше понять систему проектирования с разных точек зрения.
Тестирование, тестирование, 1-2-3
Вы говорите, что главная страница не работает? А что именно сломалось?
Возможность разделить интерфейс на составляющие его части значительно упрощает тестирование. Руководство по стилю позволяет рассматривать шаблоны интерфейса изолированно, что дает разработчикам возможность определить, что именно вызывает ошибки, несоответствия в браузере или проблемы с производительностью.
Скорость
Ранее мы обсуждали, что ускорение проектирования и разработки является одной из основных причин популярности таких фреймворков пользовательского интерфейса, как Bootstrap. Нам приходится работать над проектами как можно быстрее. Разработав собственную систему проектирования, можно получить те же преимущества в скорости, что и при использовании готовых наборов инструментов для создания пользовательского интерфейса.
Действительно, разработка системы проектирования интерфейса и создание собственной библиотеки паттернов требует много времени, размышлений и усилий. Но как только библиотека паттернов создана, последующее проектирование и разработка становятся гораздо быстрее, что, как правило, радует всех.
Федерико Холгадо, ведущий UX-разработчик компании MailChimp, рассказал, как библиотека паттернов MailChimp первоначально состояла из паттернов, созданных на основе четырех основных экранов приложения. Но когда они перешли к другим областям сайта, они поняли, что могут использовать существующие паттерны, а не генерировать каждый раз новые с нуля.
...Как только мы это сделали, по мере внедрения на других страницах мы начали понимать: чувак, эта система действительно будет работать здесь, а эта - здесь и здесь. - Федерико Хольгадо
Это игра вдолгую
Несомненно, руководства по стилю помогают командам эффективно решать задачи "здесь и сейчас". Но, подобно изысканному вину, ценность руководств по стилю возрастает со временем. Прекрасная особенность дизайн-систем интерфейсов заключается в том, что их можно и нужно модифицировать, расширять и совершенствовать в течение многих лет.
Как уже говорилось, создание библиотеки шаблонов требует большой предварительной работы, но эта работа должна стать структурной основой для будущих итераций и доработок. Уроки, извлеченные из аналитики, пользовательского тестирования, A/B-тестирования и опыта, должны быть включены в руководство по стилю, превращая его в мощный концентратор истины, знаний и лучших практик.
Более того, даже если вам предстоит серьезный редизайн, многие структурные элементы интерфейса останутся неизменными. У вас по-прежнему будут формы, кнопки, заголовки и другие общие шаблоны интерфейса, так что нет необходимости выбрасывать все в помойку. Руководство по стилю обеспечивает надежный фундамент для всех будущих работ, даже если эти будущие работы будут выглядеть совершенно иначе.
Проблемы, связанные с руководством по стилю
К этому моменту преимущества создания дизайн-систем должны быть очевидны, и, надеюсь, в вашей голове уже пляшут образы сахарных слив и прекрасных руководств по стилю. Но чтобы достичь нирваны руководства по стилю, сначала необходимо преодолеть множество опасностей, сопутствующих этой области.
Непростые торги
Для того чтобы воспользоваться руководствами по стилю, организации должны сначала выделить необходимое время и бюджет для их создания. Это требует от организаций преодоления краткосрочной ментальности, которая слишком часто проникает в корпоративную культуру.
Долгосрочные преимущества, которые руководства по стилю предоставляют, очевидны для тех, кто уже думает о долгосрочной перспективе. Таким образом, вызов заключается в том, чтобы убедить тех, кто застрял в краткосрочном мышлении, о том, что создание продуманной системы дизайна является разумным вложением в будущее.
Вопрос времени
Самое сложное - создать машину, которая будет производить продукт. - Деннис Кроули
Пожалуй, самая большая и неизбежная проблема заключается в том, что создание руководств по стилю отнимает много времени. Не знаю, как вы, а я не хожу каждый день на работу, размышляя, чем бы занять свое время. Я не встречал ни одного человека, который бы не испытывал давления, связанного с необходимостью выполнить работу, и это давление естественным образом приводит к концентрации на основном веб-проекте. К сожалению, жесткие сроки и ограниченные бюджеты отвлекают от усилий, необходимых для создания руководств по стилю, даже если команды преданы этому делу.
Вспомогательные проекты
Библиотеки паттернов часто рассматриваются как вспомогательные проекты, а не как составные части конечного продукта. Если рассматривать библиотеки паттернов как нечто отдельное от основного проекта, то они, как правило, попадают в категорию "приятно иметь" и становятся первыми, кто попадает под сокращение, когда становится трудно.
Эта проблема со вспомогательными проектами напоминает мне о том, что я часто слышу в отношении учета доступности в проектах. Они говорят: "О, мы хотели бы иметь время и бюджет для обеспечения доступности, но...". Мнение о том, что доступность (и другие принципы, такие как производительность и отзывчивость) - это дорогостоящая дополнительная статья расходов, является ошибочным. Библиотеки шаблонов, как и доступность, являются хорошими идеями, которые следует включить в рабочий процесс независимо от того, предусмотрены ли они в плане проекта.
Поддержка и управление
Даже если на создание руководств по стилю выделяется время и деньги, эти ценные инструменты часто гибнут, если им не уделяется должного внимания для раскрытия их потенциала.
Стратегия сопровождения и управления является критически важной для успешного использования руководств по стилю. Руководства по стилю будут выброшены в мусорную корзину и заброшены без надлежащей стратегии, определяющей, кто будет управлять ими, поддерживать и следить за их соблюдением.
Путаница с аудиторией
Руководства по стилю могут быть неправильно восприняты как инструменты, полезные только дизайнерам или разработчикам, что приводит к недостаточной видимости их эффективности. Вместо того чтобы служить "водопоем" для всех сотрудников организации, руководство по стилю может стать секретом, охраняемой одной дисциплиной. Простите мое наивное мнение, но я не думаю, что это способствует развитию культуры сотрудничества.
Не учитывая широкую аудиторию, руководства по стилю могут показаться слишком расплывчатыми или слишком техническими, что может отпугнуть представителей других дисциплин и заставить их считать эти ресурсы не предназначенными для них.
Структура руководства по стилю
Для того чтобы руководства по стилю были полезными ресурсами для всех сотрудников организации, они должны четко представлять, что это такое и почему они важны. Руководства по стилю должны быть привлекательными, привлекательными, наглядными, понятными и простыми в использовании. Как уже говорилось выше, они должны учитывать, что их будет просматривать множество аудиторий, поэтому должны стремиться быть приветливыми и полезными для как можно большего числа людей.
Отсутствие контекста
Контекст является ключевым фактором для понимания системы проектирования. К сожалению, большинство библиотек паттернов не дают никаких подсказок о том, когда, как и где используются их компоненты. Не предоставляя контекста, дизайнеры и разработчики не знают, насколько глобальным является тот или иной паттерн, и, как следствие, не знают, какие страницы приложения необходимо будет пересмотреть, проверить и протестировать в случае внесения изменений.
Отсутствие четкой методологии
Как бы мне ни нравились библиотеки паттернов, я не могу не заметить отсутствие структуры во многих из них. Не поймите меня неправильно, я считаю совершенно замечательным, что команды мыслят систематически и документируют свои шаблоны пользовательского интерфейса. Но мне часто кажется, что многие библиотеки паттернов представляют собой не более чем небрежно расставленные модули. Мне кажется, здесь есть место для улучшений.
В поисках методологии дизайна интерфейса
Для того чтобы создавать пользовательские интерфейсы в этом эклектичном веб-ландшафте, мы должны продвигаться дальше от метафоры страницы, которая с нами с самого зарождения веба. К счастью, организации все больше принимают модульность в каждом аспекте процесса создания веб-сайтов, что приводит к более интеллектуальной работе и устойчивым системам.
Поскольку число устройств, браузеров и окружений продолжает расти со страшной скоростью, необходимость создания продуманных, осознанных систем дизайна интерфейса становится более явной, чем когда-либо ранее.
Вот где на сцену выходит атомарный дизайн.
Что дальше?
Теперь вы готовы к изучению следующей статьи: Методология атомарного дизайна.
Всем спасибо за внимание!
Данная статья была написана специально для телеграм-канала "Айрат о дизайне"