Как сделать ваши системы проектирования динамичными? • Ostapich - разработка сайтов
Scroll to top
© 2019, Ostapich - веб-дизайнер Пользовательское соглашение

Как сделать ваши системы проектирования динамичными?

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

Когда это было реализовано разработчиками, я заметил, что несколько карт вели себя по-разному. У некоторых кнопки находились на фиксированном расстоянии от края, у других – “скакали” вверх-вниз. Прежде чем связываться с руководителями разработчиков и отмахиваться от них, я подумал, что лучше всего ознакомиться с правилами, установленными для этого компонента.

Библиотека была настроена как файл Sketch, и она выглядела великолепно, но я заметил кое-что довольно интересное. На самом деле не было никаких правил поведения кнопок. Все примеры в дизайне имели одинаковое количество текста и никаких заметок об ожидаемом поведении. Неудивительно, что команды разработчиков интерпретировали это по-разному. Они оба были правы, в некотором смысле.

Ограничения наших инструментов

В этом случае вина лежит на команде разработчиков. Проектируя на бумаге и в Sketch, мы не думали о компонентах как о динамичных и адаптируемых. Поскольку инструменты, которые мы используем, в конечном итоге исходят из печати, они в основном ориентированы на статический дизайн. Есть некоторые исключения, которые начинают появляться уже в результате, такие как Framer X и InVision Studio, которые начинают решать эту проблему (подробнее об этом позже). Но сейчас я сосредоточусь на нашем мышлении и на том, как мы должны приложить усилия, чтобы изменить это.

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

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

Этот способ работы и, что более важно, мышление имеет свои недостатки. Наиболее очевидным из которых является абсурдное количество вариантов, вызванных отсутствием гибкости.

Слишком много вариантов

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

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

Это было бы смешно, верно? Очевидно, карты были разработаны, чтобы быть динамическими элементами. Дело в том, что нельзя ожидать, что другие будут читать ваши мысли или чьи-либо еще. Если руководство по системе проектирования не совсем понятно, значит, все честно.

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

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

Правила, а не варианты

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

Используя такие инструменты, как Figma, Framer X и другие, мы уже можем сказать им, чтобы они всегда сохраняли эту форму на 10 пикселей слева или всегда центрировали эту пользовательскую фотографию и 50 пикселей сверху.

Однако это не отражено в системах проектирования, которые я видел. Большинство из них, как правило, демонстрируют красивые макеты компонентов с минимальными или отсутствующими правилами, объясняющими использование и поведение шаблонов, даже если они содержат десятки вариантов.

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

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

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

Приведение в порядок, придача смысла.

Если вы когда-либо создавали библиотеку компонентов или шаблонов или просто использовали ее, вы знаете, насколько они запутаны. И здесь я предлагаю добавить больше информации в кучу. 

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

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

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

  1. Мысли о результате

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

  1. Проектировка системы, а не каркасов или макетов

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

  1. Сборка систем с правилами, а не со скриншотами

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

Графические дизайнеры делают это десятилетиями с помощью логотипов и систем идентификации. Невозможно создать логотип без монохромных, вертикальных, горизонтальных, больших и маленьких вариаций, среди множества других. Это связано с тем, что ожидается, что в презентациях PowerPoint он будет использован неправильно, будет отправлен по факсу, скопирован 5 раз, помечен водяными знаками и с пикселями. Вот почему их конструкции крепкие. Где по пути мы забыли это?

Похожие записи