Сегодня расскажу о том, как работает системное мышление в дизайне и как мы используем этот подход при создании дашбордов.
Что значит "мыслить системно" и почему это важно
Системное мышление — это способ проектирования по определенным, заранее установленным алгоритмам. При таком подходе дизайн строится и развивается сам по себе, с минимальным участием дизайнера. Представим дизайн как конструктор: если все детали заранее проработаны и совместимы, его сборка занимает минимум времени, и пересобрать его не составит труда.
У нас есть подробная внутренняя документация по каждому проекту, и доступ к ней есть у всех сотрудников: если от клиента приходит ТЗ по добавлению новой страницы, она может собрать себя сама по заданным правилам. Системное мышление позволяет создавать одновременно стабильные и гибкие продукты, которые можно легко изменять и масштабировать.
У подхода есть несколько плюсов. Во‑первых, дизайнеры становятся взаимозаменяемыми: если кто‑то уходит в отпуск или переключается на другой проект, любой из членов команды может продолжить работу без ущерба качеству и временных затрат на онбординг. Во‑вторых, разработчикам не приходится каждый раз с нуля разбираться в новой логике продукта, потому что все элементы ведут себя предсказуемо. И в результате клиент получает продукт, который выглядит и работает консистентно, даже если над ним работало много людей.
Как выстроить дизайн-систему
Прежде чем вводить системный подход, стоит понять, нужен ли он вообще. Например, если вы создаете простые лендинговые сайты или уникальные арт‑проекты, тратить время на разработку системных решений вам необязательно. Но в дизайне сложных цифровых продуктов, тем более аналитических риалтайм решений, которые мы создаем, — система необходима.
Системный подход подразумевает подробное описание всех решений и правил, которые вы используете в работе. В создании системы важно не хвататься за все сразу — это только отдалит конечный результат и повысит возможность возникновения ошибок. Продвигайтесь поэтапно: соберите минимальный скелет, который будете постепенно наращивать новыми данными.
Когда мы начинаем работу над проектом, то сначала рисуем концепт, не задумываясь о системе — чтобы не стопорить креатив. После того как концепты утверждены, начинается самое интересное. На основе тех страниц, которые отрисованы и утверждены, мы проектируем сетку. Этому этапу обычно посвящаем много времени, потому что стандартные решения нам не подходят, ведь мы часто работаем с необычными экранами. Продумываем крупно‑блочную структуру: как располагаются страницы, как осуществляется переход между ними, закладываем какие‑то общие принципы анимации. Все это записываем и документируем.
На внешний вид сетки влияет много факторов: геометрия экрана, рассадка людей в помещении, положение спикера при презентации и т. д.
На следующем этапе мы уже продумываем поведение блоков внутри страниц, что, куда, зачем и как — отрабатываем базовый минимум, сильно не вдаваясь в подробности. На этапе описания чего‑то нового главное не перестараться и продвигаться постепенно, потому что любая система не заканчивается на дизайне. Дизайн нужно будет передать разработчикам, и, если изначально заложить слишком много вводных, продукт надолго застрянет на этапе разработки.
После описания всех элементов переходим к разработке дизайн системы, UI‑кита, и прочим украшательствам. Важно приступать к этому шагу как можно позже, насколько это позволяет продакшн‑план, потому что логика должна быть важнее дизайна. Выстроить дизайн по рабочей логике несложно, а вот описать логику дизайна, который к ней не готов, практически невозможно. В нашей практике несколько раз было такое, что дизайн нужен был срочно и мы отправляли его в билд, не особо понимая логику — потом приходилось переделывать.
Нужно понимать, что перед тем, как система облегчит сборку проектов, пройдет довольно много времени. На первых этапах придется потратить время на описание и структуризацию всех решений. Иногда бывает сложно объяснить заказчику, которого интересует видимый результат, необходимость постепенного построения системы. Поэтому при работе над проектами мы отдельно готовим красивые концепции, которые представляем клиентам, и отдельно ведем внутреннюю систему, описывая все стадии разработки. В конце мы собираем все воедино и получаем решение, которое одновременно нравится клиенту и стабильно работает.
Концепты, которые мы показывали заказчику. Это наброски, чтобы утвердить подход к дизайну визуальной части, а заодно представить, как будет выглядеть сетка, минимальные шрифты, и цвета. Эти макеты красивые визуально, но не учитывают ничего больше, включая данные. Финальный дизайн с подключенной системой был внешне очень похож на первый — но внутри изменилось все. В нашем подходе разработка концепции и разработка системы могут идти параллельно. Пока с клиентом утверждается внешний вид дашборда, который важен для него в первую очередь, мы продумываем логику и структуру будущего интерфейса.
Какие принципы помогают автоматизировать процессы
В дизайне очень помогает знание математики, и в целом восприятие дизайна как математической системы, со своими внутренними закономерностями и строгими правилами, которые их регулируют. Это поможет понимать, как разные элементы дизайна работают и как влияют друг на друга. Такой подход не убивает креатив — наоборот, он дает дополнительное пространство для экспериментов.
Второй шаг к системному подходу, который часто дается непросто, — поумерить свои художественные амбиции. В сложных аналитических продуктах на первый план выходит не творческое самовыражение дизайнера, а аккуратность и продуманность. Эстетика уступает функциональности, и финальное решение должно быть прежде всего максимально понятно и удобно пользователю.
Эта диаграмма выглядела круто с точки зрения дизайна и понравилась всем внешне, но для пользователей она была бы неудобной — поэтому мы от нее отказались.
Следующий вариант диаграммы, напротив, был очень интуитивно‑понятным, функциональным и гибким в плане данных. К сожалению, от него тоже пришлось отказаться — эта диаграмма не понравилась нам уже внешне. В итоге нам удалось разработать третий дизайн, который был и визуально красивым, и функциональным.
Как мы уже писали выше, в наших дизайнах всегда есть место для творчества: системный подход совершенно не означает, что все должно быть однообразным и скучным.
При создании системы возьмите за правило объяснять любое действие и появление каждого нового элемента: зачем вводится конкретное правило, что оно позволяет делать и в каких случаях будет использовано. Все решения должны быть аргументированы с точки зрения реальной пользы. «Так будет красиво» — не аргумент.
Какие элементы дашборда можно (и нужно) стандартизировать
Прелесть системного мышления в том, что этот подход подразумевает гибкость и вариативность: систему всегда можно модифицировать, добавляя новые правила и изменяя существующие. В случае наших интерактивных дашбордов мы всегда закладываем в проект место для креатива и эффектных визуализаций, которые не вписываются в рамки готовых решений. Внутри каждого проекта мы выделяем зоны более классического формата представления данных и зоны для «красоты». В первом случае мы можем повторно использовать отдельные элементы из репозитория «коробочных» решений: например, виджеты таблиц, списков, стандартных диаграмм и т. д. Это черно‑белые макеты, которые можно красить и видоизменять под нужды конкретного проекта.
Например, в этом дашборде мы изначально планировали сетку таким образом, чтобы по центру всегда была эффектная 3D‑визуализация, будь то интерактивная карта или линейная диаграмма. По бокам экрана расположены данные в более привычном формате. Конкретно в этом случае система построена так, что центральная часть дашборда очень гибкая в плане изменений, а боковые сделаны консистентными.
Инструменты и технологии
Основа работающей системы — исчерпывающая документация, которая описывает каждый элемент проекта не только внешне, но и с точки зрения механики его работы.
Описание каждого виджета должно отвечать на 4 ключевых вопроса:
Как это работает, как с этим взаимодействовать и какие данные это показывает?
Как это работает в пороговых значениях? (например если виджет показывает 0, или 100, или какую‑то цифру, которая не предполагается)
Как это работает, если данные по каким‑то причинам не приходят?
Как реагирует система, если этого элемента не будет?
Это лишь малая часть общей документации, на самом деле правил может быть сильно больше, но эти вопросы — обязательный минимум, который должен быть описан.
Здесь показана только часть описания одной единственной страницы. Можно представить, сколько информации у нас хранится по всем продуктам студии.
Для хранения информации по 2D‑макетам отлично подходит Figma: в ней можно хранить визуалы и описывать правила и взаимосвязи как внутри конкретного проекта, так и по проектам в целом. Также она позволяет бесшовно тянуть элементы из проекта в проект, что сильно упрощает развитие дизайн‑системы. Благодаря тому, что мы потратили время на подготовку внутренней библиотеки, которая постоянно обновляется, у нас есть универсальная база для онбординга новых сотрудников.
Для 3D макетов подойдет любая нодовая система, мы, например, используем Blender. Плюс таких систем визуального программирования в том, что они работают по определенному набору правил, и если эти правила понимать, то при разработке 3D визуалов можно тонко чувствовать ограничения разработки и понимать что возможно, а что нет. На своих проектах я руководствуюсь правилом: если я могу что‑то собрать на нодах и объяснить, как я это собрал, не будучи разработчиком, то и разработчики смогут это собрать. За 6 лет работы в студии это правило ни разу меня не подводило. Понимание нодовых систем помогает дизайнеру разговаривать с разработчиками на одном языке, при этом не будучи разработчиком.
Такую нодовую систему мы собираем в Blender для дизайна какой‑то интерактивной штуки и последующей передачи в разработку. Все это очень легко объяснять разработчикам, потому что они понимают ноды и умеют их читать.
Работа с данными
Частый соблазн в дизайне дашбордов — подстраиваться под текущий набор данных. Такой подход может сильно затянуть процесс дизайна. Мы взяли за правило, наоборот, отталкиваться от структуры, которая будет лучше всего работать, а не от доступных данных. Используем практику, довольно распространенную в UX дизайне: представляем себя на месте пользователя и прикидываем, какие данные он хотел бы увидеть. Рисуем по максимуму, не стесняясь предлагать и придумывать — при необходимости дополнительные данные обычно удается подтянуть. А если вдруг не получится, гибкая система всегда позволит адаптировать структуру дашборда и убрать лишние элементы. Самый страшный вопрос — не заданный.
Вывод
Системный подход не ограничивает дизайнера, а сокращает вероятность ошибок и освобождает от рутины, позволяя сосредоточиться на более сложных и интересных задачах. Его использование требует терпения, дисциплины, внимательности и времени на проработку — но на выходе дает надежную базу, на основе которой можно строить рабочие решения.