Язык модульного проектирования

Когда многие из нас уходят от проектирования страниц к проектированию систем, то возникает одна концепция: модульность (модулирование). Мы часто слышим о преимуществах модульного принципа; модули масштабируемы, заменимы, могут многократно использоваться, их легко проверить, легко собрать – «Прямо как Лего!»

Сперва модульное проектирование может показаться лёгким, но от вашей команды потребуется определённое усилие и настойчивость, чтобы всё заработало.

Самые больше проблемы модульности – это те решения, которые нужно принять: когда использовать модуль ещё раз и когда спроектировать новый, как сделать модули достаточно чёткими, как их сочетать, как избежать дублирования ваших модулей с модулями других дизайнеров и команд и так далее. Когда вы модулируете уже существующий дизайн или проектируете новый не всегда понятно с чего же начать.

Начните с языка

Язык – это основа совместной работы. В своей книге Эбби Коверт говорит, что самое большое препятствие для команды – это отсутствие общего языка. Для того, чтобы создать такой общий язык, она предлагает нам обсуждать, изучать и документировать наши бытовые решения в виде «контролируемых словарей». Если кратко, то мы должны начать с языка, а не с интерфейса.

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

Создайте библиотеку образцов как одна команда

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

image001

Один из наших первых экспериментов с модульностью.

В итоге мы получили три проекта, которые стали работающими прототипами. Да, это упражнение было полезным, но результат, к которому мы пришли, был не совсем модульным:

  • Модули не были чётко определены.
  • У них не было чётких функций; различия между ними были зачастую просто эстетическими.
  • Мы их не стандартизировали и не называли.
  • Мы не думали над тем, каким образом их можно будет использовать ещё раз.

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

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

Как только у нас появилась библиотека, мы стали лучше подготовлены к тому, чтобы думать о проектировании с точки зрения многократного использования его элементов. До тех пор – даже после всех наших экспериментов – мы все ещё проектировали страницами.

Называйте вещи совместно, основываясь на их функции высокого уровня

Итак, теперь, когда вы заложили основу, важно начать развивать язык, которым вы будете пользоваться, как команда. Важная часть такого процесса – это присваивание имён тому, что вы создаёте.

Представьте, что у вас есть простой компонент, целью которого является убедить людей участвовать в необычном онлайн курсе. Как бы вы его назвали?

image003

Компонент пользовательского интерфейса, продвигающий онлайн курс на FutureLearn («Азы кибербезопасности». Записаться. Узнать больше.)

Название зависит от функции компонента и от того, как и где он появляется в интерфейсе. Кто-то, например, может назвать его «изображение заголовка» или «промо курса».

Джеймс Бриттон, хорошо известный британский преподаватель, объясняет в своей работе Язык и обучение, что, давая объектам имена, мы, таким образом, делаем их настоящими. Прямо как дети, которые используют язык, чтобы из ничего создать мир вокруг них. Точно также, если у объекта интерфейса нет названия – названия, которое имеет смысл для вашей команды, знакомо и используется людьми из вашей команды – тогда его не существует, как определенного объекта, с которым можно работать. Как только вы дали объекту название, с тех пор вы создали его будущее. Например, если вы дадите ему презентационное название, тогда его будущее будет ограничено, так как он будет ограничен своим стилем. Название, которое отражает функцию объекта, это лучший вариант. Но функциональные имена трудно подобрать, над ними нужно тщательно думать, так как функция сама по себе относительна. Например, мы почти назвали элемент выше как «постер курса», так как у него есть изображение курса на заднем плане и его функцией является продвижение курса. И такое название было неплохим (на самом деле оно было даже функциональным), но так же было ограничивающим. Примерно в это же время, для другого проекта, другой дизайнер представил компонент, который выглядел (исключая незначительные отличия во внешнем виде и типографии) таким же, как и наш «постер курса».

image005

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

Функцией нового компонента было приглашение людей принять участие в обсуждении. Из-за этого первым названием, которое пришло в голову, было «обсуждение». Поначалу, никто не постарался связать этот компонент с предыдущим. Ведь его название привело к ограничению до одной единственной функции – продвижение курса. А функция «обсуждение» не имеет с этим ничего общего.

Если бы мы дали этим компонентам названия, о которых мы подумали сначала («постер курса» и «обсуждение»), мы бы получили два модуля, которые были практически одинаковы, но не могли быть использованы повторно. Такие оплошности могут привести к повторениям и несоответствиям, которые разрушают принцип модульности.
И хотя по началу их функции кажутся разными, если вы присмотритесь внимательнее и попробуете представить, как можно использовать их в дальнейшем, то поймёте, что они выполняют одно назначение – привлечение внимания. Они как бы призывают пользователя к действию. Другими словами их функция высокого уровня — это фокусирование внимания пользователей на одном важном действии.

image006

Компонент билборд в использовании.

В конце концов, мы создали единый компонент, который назвали «билборд». Билборды не ограничены в своём расположении на странице, своим содержанием или своим видом. Они могут появиться в качестве изображения на заднем плане или как часть контента. Самое главное – это функция высокого уровня, и что разные люди в команде понимают эту функцию одинаково.

image008

Example of a billboard component with an image as part of the content. (Обсуждение. «Как это может быть плохо для печени?» Пожалуйста, прокомментируйте каким образом это может плохо повлиять на ваше печень и почему)

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

Сделайте язык проектирования частью вашей ежедневной работы

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

image009

Место в нашем офисе, где мы часто говорим о языке.

Функции высокого уровня легче определить, если у вас перед глазами есть ПИ (пользовательский интерфейс). Таким образом намного легче заметить дублирование и несовместимости.

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

Обычное обсуждение названий на Slack.

Обычное обсуждение названий на Slack.

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

Определите архитектуру css на стадии проектирования

Разумеется, достигнуть соглашения может быть сложно. Например, мы можем не согласиться нужно ли нам использовать ещё раз уже существующий модуль, настроить его для определённого контекста или же создать новый компонент.

Уже написано несколько статей о проектировании элементов пользовательского интерфейса, основанных на контексте. Но Гарри Робертс предположил что «необходимость изменять детали компонента в определенном контексте – это дизайн с душком» — знак того, что ваш дизайн неудачный. Как же это предотвратить?

Нам может помочь попытка стандартизировать элементы на этапе проектирования. Другими словами нам следует начать с языка проектирования. Это значит, что разработчики должны понимать, почему что-то проектируется именно таким образом, а дизайнеры должны знать, как строятся модули, чтобы они могли внести поправки без необходимости создавать другую версию модуля.

Перед написанием CSS дизайнерам и разработчикам полезно понять цель каждого элемента, который они создают. Они могут начать, задав много вопросов: «Будет этот модуль всегда использоваться во всю ширину? Почему? В нём всегда будут эти кнопки? Изменится ли типография? Является ли изображение на фоне решающим для дизайна?»
Ответы на эти вопросы помогут удостовериться, что компоненты будут соответствовать концепции дизайна. Например, вы можете решить специфицировать некоторые стили на атомном уровне, а не на уровне организма, чтобы было легче изменить эти свойства, не изменяя сам модуль.

Привлеките пользователей в процесс проектирования

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

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

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

Выводы

Налаженный язык является мощным инструментом, который позволяет команде сосредоточить свои усилия на реализации модульного проектирования. Но общий язык проектирования должен развиваться органично и постепенно. Каждый член команды делает свой вклад, чтобы язык стал логичным. Эффективный способ заложить основу общего языка – это совместная разработка библиотеки образцов. Использование такой солидной методологии как атомный дизайн может ускорить процесс.

Совместное называние предметов это полезная привычка, так как в процессе поиска названия, которое будет иметь значение, вы определяете его функцию и что самое главное достигаете взаимопонимания. Согласованное имя определяет то, как будет выстроен элемент и побуждает команду использовать это название постоянно. И как пишет Эбби Коверт «Если вы не договоритесь с самого начала, то приготовьтесь впахивать потом».

Настаивайте на том, чтобы использовать, то слово, которое вы подобрали – даже если оно странно звучит в повседневной речи. Приходится заставлять себя называть что-нибудь «коробочка шёпота» (да, у нас есть элемент, который мы называем «коробочка шёпота»). И такое название намного лучше чем «та штука с линиями и иконкой по середине».

Каждый раз, когда вы используете название, которое подобрали, вы развиваете ваш язык проектирования.

Протестируйте ваш язык за пределами вашей команды – в компании, с вашими пользователями и с другими командами. Всегда интересно услышать, как кто-то посторонний, не из вашей команды тоже начинает использовать такое название.

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

Алла Холматова

image014Алла Холматова – проектировщик на FutureLearn, открытой образовательной платформе. Она очарована интерфесами, а уж тем более людьми по обе стороны процесса – дизайнерами и людьми – и она всегда ищет способы сократить разрыв между ними.

 

 

 

<blockquote>Автор: <a href=»http://alistapart.com/author/craftui»>Алла Холматова</a> 11 августа, 2015

Источник: <a href=»http://alistapart.com/article/language-of-modular-design»>http://alistapart.com/article/language-of-modular-design</a>

Перевод: Ольга Тихоньких</blockquote>

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *