Инструменты дизайна не работают. Вот как мы можем их исправить.

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

Недавно я написал в Твиттере об инструментах дизайна - что, как известно, происходило время от времени.

Я был не единственным, кто высказал свое мнение в тот день, другие тоже вмешались.

28 июля 2017 года не было удачного дня для инструментов дизайна.

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

Мы все просто рисуем картинки. Это безумие.

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

  1. Вы не можете взаимодействовать с изображением. Инструменты создания прототипов позволяют нам добавлять переходы экрана и простые взаимодействия с изображениями. Однако, поскольку наши продукты продолжают требовать более совершенных переходов между экранами и микро-взаимодействий, изображения просто не могут идти в ногу.
  2. Изображения не являются текучими. Передача адаптивных дизайнерских решений с помощью изображений обычно является сложной задачей.
  3. Изображения не с состоянием. Чтобы эффективно сообщать различные состояния для пользовательского интерфейса, часто требуется много изображений.
  4. Растровые изображения зависят от разрешения. С появлением устройств сетчатки изображения иногда могут плохо отображаться.
  5. Файлы изображений имеют тенденцию быть тяжелыми и часто громоздкими для хранения, управления или обмена.

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

Это очень важный момент, потому что по своей сути почти все инструменты дизайна преобразуют векторные фигуры в изображения. Photoshop, Illustrator, Marvel, Adobe XD, Sketch и Figma одинаковы в этом отношении. И все же изображения могут лишь частично отражать замысел проекта Поскольку наши продукты продолжают внедрять и поддерживать сложные взаимодействия, голосовой ввод, ввод видео, дополненную реальность, виртуальную реальность, чувствительность к температуре и т. Д., Ценность, которую обеспечивают эти инструменты, будет быстро уменьшаться. Имиджевый дизайн - это тупик.

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

Наши продукты являются интерактивными. Наши инструменты статичны.

Я коснулся этого в моем предыдущем пункте, но это очень важно, поэтому я решил немного подробнее остановиться.

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

  • Наведение кнопки
  • Фокусировка ввода
  • Флажок
  • Содержание с вкладками
  • Области прокрутки
  • Индекс вкладки для целевых состояний
  • Горячие клавиши

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

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

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

Наши инструменты должны поддерживать макет веб-макета

Примерно год назад единственным способом создания макетов в Интернете было использование свойств отображения: таблицы и выравнивания по вертикали. Теперь у нас есть Flexbox и скоро у нас будет CSS-сетка. Эти три механизма компоновки функционируют примерно одинаково, используя поток DOM. Почти все сайты создаются с использованием одной из этих трех систем верстки.

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

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

  • Адаптивный дизайн становится очень трудным, потому что каждый слой должен быть переставлен вручную для каждой точки останова. В качестве альтернативы может быть введена система макетов на основе ограничений, но это добавляет сложности, ускоряет обучение и в конечном итоге не позволяет разработчикам переносить макет непосредственно в Интернет.
  • Поскольку каждый слой находится за пределами потока документа, манипулирование контентом становится сложным. Например, если вы хотите добавить элемент в список, вы должны вручную изменить положение других элементов в этом списке. Конечно, функции повтора и другие необычные функции могут быть введены, чтобы облегчить боль, но опять же, это добавляет дополнительную сложность и усложняет то, что DOM дает нам бесплатно.
  • Абсолютное позиционирование естественным образом приводит к фиксированным пиксельным координатам и размерам. Это порождает негибкость и, опять же, огромный отход от того, как функционирует сеть. Сеть построена на таких единицах, как em, rem, vh, vw и%. Наши инструменты должны поддерживать эти модули по умолчанию.

Инструменты дизайна не должны напоминать или отражать сеть и ее нюансы - они должны просто БЫТЬ.

Монолитный инструмент не так

Хороший дизайн происходит поэтапно. Хорошо структурированная система проектирования имеет несколько отдельных слоев:

  1. Палитра стилей Коллекция цветов, теней, интервалов, радиусов границ, шрифтов, размеров шрифтов, анимации и других стилей, которые формируют индивидуальность вашего бренда. В настоящее время большинство инструментов дизайна поддерживают только цветовые палитры. Пока они не поддерживают другие свойства стиля, систематически создавать чрезвычайно трудоемко.
  2. Активы Сюда входят такие элементы, как значки, иллюстрации и изображения. Есть несколько феноменальных графических редакторов, и векторный инструмент Figma превосходен, но когда дело доходит до поддержки SVG, наши инструменты дизайна оставляют желать лучшего.
  3. Библиотека компонентов Компонент - это набор стилей и ресурсов, который отображает данные в один элемент в различных вариантах. Примеры включают кнопки, вводы, значки и т. Д. Как я уже упоминал, Figma и Sketch недавно абстрагировали этот процесс от основного процесса рисования - жаль, что они представляют собой просто изображения компонентов, а не фактические компоненты.
  4. Модули Модуль / композиция - это набор компонентов, которые визуализируют данные в инкапсулированную часть пользовательского интерфейса в различных состояниях. Примерами могут быть панели заголовков, меню вкладок, формы входа в систему, таблицы и т. Д. Поскольку модули - это просто сложные компоненты, я полагаю, что Figma и Sketch могут справиться с ними. Хотя может быть некоторая заслуга в их разделении.
  5. Экраны Экран - это набор модулей, компонентов и данных для формирования полного пользовательского интерфейса, с которым пользователь может взаимодействовать.

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

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

Разработка иконки требует совершенно другого способа мышления, чем разработка пользовательского потока. Простой SVG-редактор, который позволял мне рисовать собственные SVG-прямоугольники, круги, линии и пути, а затем экспортировать оптимизированный SVG-код, был бы идеальным вариантом.

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

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

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

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

Наши инструменты должны поощрять хороший дизайн

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

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

И почему бы нет…? Потому что инструменты дизайна не заботятся.

Инструменты дизайна настолько очарованы идеей неограниченного творчества, что упустили из виду, что значит разумный дизайн, в том числе дизайн, систематический дизайн.

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

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

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

Мы должны проектировать с живыми данными

Живые данные были в некоторой степени включены многими инструментами, что приятно видеть. В Adobe XD есть несколько действительно полезных функций для создания поддельных данных, которые напоминают типичные живые данные. Invision Craft также предоставляет некоторые интересные функции для работы с данными в Sketch.

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

Наши инструменты дизайна предоставляют нам такую ​​роскошь?

Одним словом, нет.

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

Сеть открыта. Наши инструменты тоже должны быть.

Одна из действительно красивых вещей в сети - это ее открытость. Веб-сайт можно просматривать в любом веб-браузере практически на любом устройстве.

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

Большинство инструментов дизайна - огороженные сады. Если один коллега работает в Photoshop, другой коллега не может открыть этот проект в Sketch. Недостаточно, чтобы вся ваша команда использовала один и тот же инструмент - они также должны использовать одну и ту же версию этого инструмента.

Marvel и Figma делают хорошую работу здесь, предлагая бесплатные планы и инновационные функции для совместной работы.

Итак, каково будущее инструментов дизайна?

Инновации в инструментах дизайна чрезвычайно ценны, и их было много в последнее время. В инструментах проектирования Airbnb Джон Голд и Бенджамин Уилкинс работают над React-Sketchapp, который берет компоненты React и отображает их в Sketch. Джон и Бен также работают над новым умопомрачительным инструментом, который берет наброски салфеток и каким-то образом превращает их в компоненты React.

Адам Морс, Брент Джексон и Джон Отандер работают над набором инструментов в Compositor, которые в основном решают все проблемы в этой статье и, возможно, в мире.

Я работаю над Modulz, новым средством проектирования и системой проектирования с открытым исходным кодом, которое также направлено на решение проблем, упомянутых в этой статье. Если вам интересно, следите за обновлениями в Твиттере.

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

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

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

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

Если систематический инструмент дизайна должен завоевать наши сердца, он должен сначала обучать.