Как дизайн-инструменты ограничивают нас — DEADSIGN

Они еще никогда так не увеличивали скорость работы.

В них еще никогда не было столько фич для дизайна интерфейсов.

Они вывели совместную работу на новый уровень, сделав её как никогда эффективной.

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

Но я понимаю, почему так. Многие UI-дизайнеры вышли как раз оттуда. И тем не менее, мы продолжаем говорить о UI-дизайне, как об искусстве. В нашем лексиконе есть такие термины, как «холст» и «артборд» словно мы создаем произведение, которое однажды окажется на стене музея за красной бархатной ленточкой.

Не окажется.

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

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

Начнем с этого:

Нам нужна блочная модель

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

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

Один элемент сдвигает другой. И у каждого из них свой размер. Они делят между собой пространство. Сайты и приложения — это большой старый-добрый тетрис, где блочная модель задаёт размер и форму «кирпичиков».

НО В ИНСТРУМЕНТАХ ДЛЯ ДИЗАЙНА ЭТОГО НЕТ.

ПОЧЕМУ.

РАДИ БОГА ОБЪЯСНИТЕ, ПОЧЕМУ.

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

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

Но вообще это так не работает.

В HTML, практически всё, что занимает пространство, выталкивает из этого пространства что-то ещё. И по мере того, как я пишу это предложение, абзац становится все больше. Абзац растягивается, а с ним растет и контейнер, который его содержит. Чем больше места занимает контейнер, тем ниже по странице опускаются остальные элементы. Эти элементы, опускаясь, увеличивают высоту всей страницы. Если бы я рисовал этот макет в каком-нибудь инструменте для дизайна, в моем фрейме/ артборде увеличение объема текста не учитывалось бы вообще. Его размер не поменяется, пока я не подвину границу текстового контейнера. Это же так тупо.

Будь это блочная модель, черный прямоугольник на гифке ☝️ опускался бы вниз по мере увеличения текста, а родительский контейнер увеличивался бы в размерах. Документы в Word уже несколько ДЕСЯТИЛЕТИЙ так могут. Почему же тогда в наших инструментах все элементы существуют независимо друг от друга? Такое поведение подходит для редактирования фотографий, создания разметки для печати или иллюстрации — но точно не для дизайна интерфейсов.

Подолью масла в огонь: этот пробел в функционале привёл к повальному незнанию того, что такое блочная модель — и это ж просто офигеть. Я то и дело слышу от дизайнеров: «Не понимаю, почему почему мои макеты на этапе разработки превращаются во что-то другое». Главная причина в том, что инструменты и среда, для которой мы делаем дизайн, абсолютно изолированы друг от друга. HTML и прочие инструменты разметки и стилизации — это тебе не холст какой хочешь формы. Но ведь мы только к такому и привыкли…

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

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

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

Наследование и отношения

Элементы не могут существовать в вакууме. В сети все элементы находятся друг с другом в неких отношениях. Какие-то из них выступают в роли контейнеров для элементов. Они называются родительские. Эта страница — родительский элемент, и «обёртка» этого абзаца — тоже, а следующий абзац по отношению к этому — уже сестринский элемент.

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

Если вы прямо сейчас взглянете на код этой страницы (клик правой кнопкой мыши, выбираете «Просмотреть код»), то увидите, что на самом верху HTML-дерева есть элемент <body>. Нажмите на него и увидите что-то вроде такого:

Ого, как много фоллбэков…

<body> — это родительский элемент всей страницы, здесь у него та же роль, что и у артборда/ фрейма в дизайнерском файле. Однако это совсем другое, потому что здесь есть свои атрибуты. Они определяют шрифт, его цвет и жирность сразу для всей страницы.

Теперь, кликайте на черный прямоугольник рядом с «цветом» и перед вами выскочит цветовая палитра. Если вы поменяете цвет, то увидите, что вместе с ним поменяется вся статья.

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

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

Вот так это могло бы выглядеть:

☝️Сделано с помощью webflow

С помощью того же трюка можно посмотреть, как будет выглядеть ваш UI, если у пользователя увеличен шрифт. Если размер шрифта наследуется из артборда/фрейма, то все что нужно сделать — увеличить его в одном месте, как у меня показано на гифке.

Прелесть этого метода в том, что у вас всё так же остаётся возможность задавать параметры на уровне элементов. И если вы попытаетесь изменить жирность или размер шрифта в <body>, ничего не произойдет — характеристики отдельных элементов всегда вытесняют родительские. Если хочется работать с деталями, работайте с деталями. Если хочется чего-то глобального — пожалуйста.

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

Безграмотная передача разработчику

Надо признать, мне пришлось помучиться, чтобы придумать сюда подходящую картинку…

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

Раньше мне казалось, что всё отлично. Я думал как-то так: «Оо, моим разработчикам это понравится! Мои инструменты правда создают CSS. Крутяяяяк!!»

Но всё вообще не так.

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

Почему тогда эта возможность вообще существует? Спору нет, может быть, инструменты помогают кому-то разобраться с закругленными углами или^, например, скопировать hex-код, но только и всего.

Это лишь дарит дизайнеру ложное чувство уверенности и сопричастности.

Вот пример дизайна:

Представьте, что я передал этот ☝️ фантастический и невероятно оригинальный макет разработчику. Написать его достаточно легко. Вот, слева — тот CSS, который мне нужно было бы написать вручную, а справа — CSS, который мне отдала Figma:

Я ничего не тестил, поэтому не нападайте, если что-то не так. Просто пример для данной статьи.

Это мой интерфейс, и я понимал, как он может себя повести, но даже мне пришлось гадать, каким должен быть интерфейс.

Надо, чтобы у карточки был внутренний отступ или строчка с текстом?

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

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

Должен ли у карточек быть какой-то максимальный или минимальный размер?

Ни одна из этих деталей не прописана в макете. В результате мне, как «разработчику», пришлось гадать. А ВЕДЬ ЭТО МОЙ СОБСТВЕННЫЙ ДИЗАЙН.

Редакторские пометки в файле пригодились, но они не давали мне ответов на вопросы «зачем?». Информация о том, как далеко друг от друга должны быть расположены элементы, ничего не говорит о том, зачем они так расположены. Интерфейс — это вам не гигантская функция X/Y. В одних элементах есть внутренний отступ, а в других — поля, что-то увеличивается, что-то уменьшается, но не меньше определенного значения, одни элементы увеличиваются только вместе с сестринскими элементами, другие — обладают размерами, которые меняются в зависимости от девайса. Для того, чтобы всё правильно работало, одних пометок недостаточно.

Кроме того, разработчики не видят, что скрыто в макетах. Сайты и приложения не статичны, а макеты не дают разработчикам увидеть, что и как будет вести себя — объём информации, который мы можем передать с их помощью, ограничен. Это значит, что если дизайнер хочет подробно разобрать адаптивный макет, то ему нужно показать по 4 вариации каждого экрана? А что если у меня 100 таких экранов? А если что-то поменяется, как все это синхронизировать? И вот что получается: мы — в лучшем случае — предоставляем несколько примеров, а в остальном полагаемся на силу интерпретации.

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

Для этого у разработчиков должна появиться возможность самим выводить все эти окна. Чтобы они могли видеть подробные макеты с клавиатурой, выведенной на экран/во фрейме браузера/с увеличенным шрифтом/когда нет интернета или при медленном API. Из наших инструментов должен исчезнуть маленький первобытный «дизайнерский» мир, инструменты должны показывать, что произойдет, когда что-то пойдет не так. Если эти моменты не поймать, то скорее всего никто и не предусмотрит решение для них.

Дизайн на основе баз данных

Это не бочонок, это база данных…

Как выглядит ваша модель данных?

Как структурированы ваши таблицы баз данных?

Уверены ли вы что вы действительно сможете оперировать данными так, как это показываете на макете?

Как много полей могут остаться пустыми?

Сколько времени нужно вашему API, чтобы осуществить возврат данных?

Какие коды ошибок возвращает ваше API при ошибках соединения?

Какие ошибки он возвращает?

Инструменты, генерирующие тестовые данные или позволяющие определить структуру вашего дизайна в формате JSON, движутся в верном направлении. Проблема в том, что мы, дизайнеры, плохо осознаем, чего именно мы не знаем о наших базах данных. Инструменты для дизайна должны рассматривать back-end разработчиков как пользователей, и позволять им передавать информацию о том, как структурированы эти данные в набор инструментов дизайнера. У нас есть инструменты для создания треугольников, теней, прямоугольников и SVG… но ни одного инструмента, чтобы использовать модель данных и понимать её? Серьезно?

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

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

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

Я бы показал вам свою версию того, как это могло бы выглядеть, но лучше отправлю вас почитать статью Джоша Пакетта 2015-ого года (?!?): https://medium.com/@joshpuckett/modern-design-tools-using-real-data-62d499e97482

Неправдоподобное взаимодействие и моушн

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

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

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

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

Подведём итог

Не поймите меня неправильно, меня очень воодушевляет то, в каком направлении движутся инструменты для дизайна в последние годы. Передаю горячий привет Figma и Webflow за тот крутой поворот, который произошел благодаря им в моей карьере, и за то, как сегодня мы делаем дизайн в Asurion. Теперь мы можем вытворять такое, о чем раньше и не мечтали, с такой скоростью, которая раньше казалась нереальной. Достоинств в отрасли гораздо больше, чем недостатков, и ситуация будет только улучшаться.

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

Инструменты, в которых эти проблемы уже решаются:

—