О важности концептуального виденья Сейчас я и команда в основном работаем над созданием движка низкоуровневой вёрстки для SDUI-фреймворка. И недавно я получил неожиданную просьбу от тимлида разработки: сформулировать концептуальное видение проекта😱
Оказалось, всё просто. Сейчас мы двигаемся поэтапно: слой за слоем я описываю группы компонентов и разные механики. Но так как виден только текущий шаг, без возможности посмотреть на общую картину, становится сложно обсуждать отдельные решения. Непонятно, как они связаны с тем, что уже есть, и — что важнее — с тем, что ещё только предстоит описать.
Я довольно долго мучился, пытаясь найти форму и нужные формулировки. В итоге остановился на формате манифеста и достаточно абстрактных принципах, не привязанных к реализации. И как только я перестал упираться в детали, всё само сложилось в стройную картину. Команда тепло приняла манифест, и я хочу поделиться с вами некоторыми его положениями — именно теми принципами, которые вы легко сможете примерить на свои системы.
🔺****ЦЕЛОСТНОСТЬ (консистентность) Система должна быть единым организмом. Даже если что-то заимствовано, оно проходит переработку — пока не станет элементом нашего языка, а не случайным инородным телом.
Целостность — это не про одинаковость визуала. Это про внутреннюю логику, которая чувствуется при работе с системой: «Да, это работает так же, как и всё остальное».
🔺****МОДУЛЬНОСТЬ Части системы развиваются независимо. Она должна масштабироваться без разрушения структуры. Добавление нового — это расширение, а не ломка.
🔺****НЕ ПЛОДИТЬ СУЩНОСТИ Принцип «расширяй, не создавай заново». Перед добавлением новой сущности — поиск аналогов и попытка обобщить.
Перед созданием любой новой сущности — шаг назад: «Это новое? Или это частный случай уже существующего?»
Система выигрывает, когда обобщает, а не распыляет. В идеале новая сущность — это выражение закономерности, а не «компонент для конкретного кейса».
Новая сущность должна рождаться не из задачи, а из закономерности. Мы ищем то, что повторяется, и поднимаем это на уровень абстракции.
Сущность должна отвечать на вопрос: «Это выражение функции или просто костыль?»
🔺****ПРОСТОТА ДЛЯ ПОЛЬЗОВАТЕЛЯ Сложность решения внутри системы — ок, если внешнее API остаётся простым и предсказуемым.
Простое — это не примитивное. Система может быть сложной, но простой в использовании, т.е. внутренние механизмы могут быть сложными, но внешний язык должен быть лёгким и предсказуемым.
🔺****ОБОБЩЕНИЕ Обобщать — значит замечать закономерности и поднимать уровень абстракции. Не «кнопка отдельная, карточка отдельная», а «интерактивный блок со состояниями», который потом проявляется разными способами.
Обобщение — источник появления сильных, долговечных сущностей. Мы ищем общее между разными решениями. Мы строим не частные компоненты, а абстракции. Кроссплатформенность — естественное продолжение обобщения.
🔺 УНИВЕРСАЛЬНОСТЬ Язык системы должен быть понятен на любой платформе — разработчикам, дизайнерам и всем пользователям системы. Универсальность — не про одинаковость, а про общность принципов.
🔺****КОМБИНИРОВАНИЕ И ВАРИАТИВНОСТЬ
Элементы системы должны сочетаться и порождать новое. Настройки должны позволять выражать разные формы в рамках одних и тех же принципов. Сила системы — в том, как она проявляется в комбинациях. Комбинации должны порождать давать новые свойства, недоступные элементам по отдельности.
🛫Канал: UXFLOW • Сергей Мухин Сайт: uxflow.ru
В этом посте были ссылки, но мы их удалили по правилам Сетки
