Как работает дизайн-команда Форсофт: процесс, система и ИИ спустя 20 лет

Зачем Фора Софт написала эту статью

Это взгляд изнутри на то, как мы проектируем продукты в Фора Софт — для основателей, CTO и продуктовых руководителей, которые выбирают подрядчика и хотят понять, умеет ли команда действительно проектировать, а не просто двигать пиксели. За 20 лет мы выпустили более 625 продуктов в видео, AI, e-learning, телемедицине, видеонаблюдении и финтехе. Кейсы BrainCert, V. A. L. T. и Tradecaster показывают, какого масштаба задачи вытягивает наша дизайн-команда.

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

Дизайн — это перевод, а не украшение

Самая полезная ментальная модель, которую мы выработали за 20 лет: продуктовый дизайн — это работа переводчика. Сырьё — сложный домен (торговая платформа, поток приёма пациента в телемедицине, классная комната с прямым видеоэфиром), а на выходе — экран, на котором уставший человек разберётся за 6 секунд без чтения документации.

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

Как это выглядит на практике: до того как дизайнеры открывают Figma, они проходят рабочий сценарий «на ногах». Для стримингового приложения это значит провести день рядом со стримером и зрителем. Для торговой платформы — посмотреть, как трейдер сканирует стакан заявок. Для телемедицины — понять, как клиницист проводит 90-секундную сортировку. Экраны рисуются в последнюю очередь.

Наш процесс дизайна по этапам

Этап 1 — Исследование (1–2 недели). Интервью с пользователями, анализ конкурентов, наблюдение за экспертами в предметной области, проверка доступности существующего продукта, если он есть. На выходе — бриф с описанием проблемы, реальные персонажи и список ограничений, которые дизайнеры будут учитывать.

Этап 2 — Вайрфреймы (1–3 недели). Низкодетализированные вайрфреймы в Visily или Figma, интерактивные прототипы в Axure или Figma для проверки. Аналитик и ведущий дизайнер работают тесно; продакт-менеджеры и стейкхолдеры утверждают структуру до начала визуального дизайна.

Этап 3 — Визуальный дизайн и система (2–5 недель). Дизайн-токены, библиотека компонентов, основные сценарии в высокой детализации. Мы строим систему от токенов — так она остаётся удобной для поддержки, а не превращается в набор красивых, но разрозненных экранов. Требования к доступности (минимум WCAG 2.2 AA) закладываем в токены заранее, а не добавляем потом.

Этап 4 — Сопровождение в спринтах (постоянно). Дизайнеры участвуют в ревью спринтов. Они проверяют пул-реквесты по дизайн-системе, выявляют регрессии и поддерживают библиотеку компонентов по мере развития инженерной части. Именно на этом этапе накапливается 80% дизайн-долга, если его пропустить.

Рис. 1. Наш четырёхэтапный процесс дизайна.

Инструменты наших дизайнеров (и почему именно они)

Подробнее о том, как мы выбираем AI-инструменты для дизайна, — в нашем разборе AI-инструментов для UI/UX-дизайна.

Как ИИ изменил наш дизайн-процесс

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

1. Первый прогон вайрфреймов за минуты. Visily и Figma AI генерируют стартовый макет по промпту. Дизайнеры дорабатывают его под задачу и нужный уровень детализации — теперь никто не сидит перед пустым холстом.

2. Синтез результатов исследования. 10 транскриптов интервью с пользователями LLM суммирует и тематизирует за 15 минут вместо двух дней. Дизайнеры проверяют и уточняют выводы, а не расшифровывают аудиозаписи.

3. Аудиты доступности. LLM с моделями зрения находят проблемы с контрастностью, размером кликабельных элементов и пробелы в ARIA прямо по макету. Подробнее о применении — в статье об AI-доступности в UI/UX-дизайне.

4. Предиктивный UX. Мы внедряем паттерны предиктивного UX — предсказание намерений пользователя и подсветка вероятных следующих действий — в SaaS-продукты, где время на странице и выполнение задач напрямую влияют на бизнес-метрики.

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

Что отличает сильного продуктового дизайнера (и кого мы нанимаем)

1. Исследовательский инстинкт. Начинает с пользователей, а не с Dribbble.

2. Имеет позицию, но опирается на данные. Обосновывает решения исследованиями и метриками, а не личным вкусом.

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

4. Системное мышление. Проектирует компоненты, а не экраны, и поддерживает систему по мере роста продукта.

5. Доступность как базовый уровень. WCAG 2.2 AA — это не задача на пятом спринте. Это решение на уровне токенов.

6. Инженерная грамотность. Понимает управление состоянием, работу с API и ограничения по производительности — достаточно хорошо, чтобы не создавать макеты, которые сложно реализовать.

7. Чувство эмоционального дизайна. Анимация, тайминг, звук, тактильная отдача — это тонкие детали, которые пользователь ощущает, но не может выразить словами.

8. Понятный текст. Если дизайнер не может объяснить логику сценария простым абзацем, он не сможет отстоять её на спринте.

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

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

Мини-кейс: проектируем торговый продукт снаружи внутрь

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

Что мы сделали. Ведущий дизайнер провёл две недели рядом с активными трейдерами — наблюдал за их сессиями, фиксировал паттерны сканирования и составил карту трёх показателей, к которым трейдеры тянутся в первые две секунды после открытия приложения. Затем мы выстроили мобильную информационную архитектуру: 90% десктопного интерфейса свернули в экраны с постепенным раскрытием, а на главную вынесли только тот «двухсекундный» набор данных.

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

Дизайн-система — то, во что большинство команд недостаточно инвестируют

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

Сначала токены. Цвет, отступы, типографика, скругления, анимация — всё задаётся токенами. Каждый компонент использует токены. Меняются токены, а не компоненты.

Компоненты в Figma зеркалят Storybook. Дизайнер добавляет вариант — инженер синхронизирует его в коде. Любое из направлений работает, но они не должны расходиться.

Доступность заложена в токены. Контрастность, фокусные обводки, размеры целевых областей — заданы один раз. Если дизайнер использует систему правильно, создать недоступный интерфейс физически невозможно.

Версионирование и список изменений. Дизайн-система развивается. Относитесь к ней как к внутреннему продукту: у неё должен быть номер версии, changelog и координатор — обычно глава дизайна, который утверждает ломающие изменения.

Эмоциональный дизайн — мелочи, которые влияют на удержание пользователей

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

1. Анимация. Основное действие — 150–250 мс, акцент — 400–600 мс. Линейная кривая не используется: только ease-in-out или пружинная. Анимация короче 100 мс кажется механической, длиннее 700 мс — тормозящей.

2. Типографика. Шкала шрифта — 4–6 ступеней, а не 12. Игра с насыщенностью вместо хаоса из размеров и весов. Высота строки — 1,5 для основного текста. Эти решения показывают внимание к деталям.

3. Текст. Подписи кнопок, которые объясняют, что произойдёт («Сохранить черновик» вместо «Отправить»). Пустые состояния, которые помогают, а не просто информируют. Сообщения об ошибках, которые возвращают уверенность.

4. Дозированные моменты восторга. Один-два неожиданных приятных момента за сессию. Больше — уже похоже на самолюбование.

Как избежать оттока пользователей в приложениях — взгляд со стороны дизайна

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

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

Как понять, нужна ли вам выделенная дизайн-команда

Вопрос 1. Основная ценность вашего продукта — в сценарии, который пользователи повторяют? Если да, дизайн — это конкурентное преимущество, а не просто оболочка.

Вопрос 2. У пользователей есть выбор? Если да (потребительские приложения, SaaS), удержание через дизайн — условие выживания. Если нет (внутренние инструменты, комплаенс-софт), дизайн для удержания менее важен, но всё равно нужен для онбординга.

Вопрос 3. Продукт регулируемый или чувствителен к доступности? Если да, нужен дизайнер, для которого WCAG — базовый уровень, а не отдельный комплаенс-спринт.

Вопрос 4. Будет ли продукт развиваться после первой версии? Если да, то нужна дизайн-система и команда, которая будет её поддерживать.

Вопрос 5. Готов ли основатель или продакт оспаривать дизайн-решения? Если да — команда раскроется на полную. Если нет — энтузиазм сгорит за три спринта.

Пять дизайн-ловушек, которые мы видим в проектах на спасение

1. Дизайн как этап «передачи». Дизайнер сдаёт макеты в Figma и исчезает. Инженеры импровизируют. К третьему спринту от единого стиля ничего не остаётся.

2. Дизайн-системы нет, есть просто экраны. Каждый экран — отдельная история. Изменение одной кнопки затрагивает 40 файлов.

3. Доступность добавляют в спринте номер двенадцать. Доделывать доступность после завершения работы обходится в 5–10 раз дороже, чем закладывать её с самого начала.

4. Красиво, но медленно. Тяжёлые анимации, большие изображения, блокирующие шрифты. Дизайн, который портит Core Web Vitals, портит и конверсию.

5. Никто не защищает пользователя. Продакт выигрывает все споры; дизайн превращается в свалку фич.

KPI, по которым мы оцениваем работу дизайн-команды

Качественные KPI. Доля успешных юзабилити-тестов по основным задачам — более 85%. Соответствие стандартам WCAG 2.2 AA для новых компонентов — 100%. Доля дизайн-долга в бэклоге — не более 10%.

Бизнес-метрики. Рост активации после редизайна (обычно 15–30%). Рост удержания на 7-й день (обычно 5–15%). Время до получения первой пользы для новых пользователей.

Системные KPI. Покрытие новых экранов дизайн-системой (цель — более 90%). Соответствие Figma и кода (цель — более 95%). Доля повторного использования компонентов.

Как устроена наша дизайн-команда

На типовом проекте работает ведущий дизайнер (сеньор, отвечает за общее видение и дизайн-систему), один поддерживающий дизайнер (мидл, занимается повседневной разработкой) и приглашённые специалисты по узким направлениям — анимация, доступность, иллюстрация. Над ними стоит глава отдела дизайна, который развивает команду и координирует взаимодействие между проектами.

На небольших проектах ведущий дизайнер делает всё сам. На крупных мы добавляем выделенного UX-исследователя и специалиста по анимации. Мы не создаём лишних ролей — вы платите за результат, а не за структуру команды.

Когда дизайнер от Фора Софт вам не нужен

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

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

Агентная инженерия + дизайн = быстрый запуск

Результаты нашего дизайна напрямую применяются в практике спецификационно-управляемой агентной инженерии. Дизайн-токены компилируются в код, контракты компонентов превращаются в тесты, интерактивные прототипы становятся основой для критериев приёмки. Замкнутая петля «дизайн — инженерия» — один из главных плюсов нашей агентной практики: расхождения с реализацией снижаются, а соответствие пикселей в первой же сборке заметно растёт.

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

Несколько слов о культуре

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

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

Часто задаваемые вопросы

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

Да. Мы делаем самостоятельные дизайн-проекты: от исследования до вайрфреймов, визуального дизайна и создания системы — за 4–8 недель. Файлы в Figma остаются у вас, и вы можете передать их любому техническому партнёру. Многие клиенты возвращаются к нам за разработкой, но даже те, кто не возвращается, видят ценность в самой работе.

Вы умеете работать с нашей существующей дизайн-системой?

Да. Наши дизайнеры подключаются к вашим Figma-библиотекам и дополняют систему там, где вашей команде нужна помощь. Мы не навязываем свою систему — мы уважаем вашу и улучшаем её, если вы попросите.

Можете ли вы провести аудит доступности (WCAG 2.2 AA) существующего продукта?

Да. Типичный аудит занимает 1–2 недели и завершается приоритизированным списком нарушений с предложениями по исправлению на уровне дизайна и инженерии. Для регулируемых рынков мы можем стремиться к соответствию WCAG 2.2 AAA в критичных сценариях.

Как вы решаете разногласия стейкхолдеров по направлению дизайна?

Большую часть споров решают юзабилити-тесты и метрики. Ведущий дизайнер проводит короткие количественные тесты (Maze, UserTesting) по двум вариантам и представляет результаты. Если данные неоднозначны, мы по умолчанию выбираем вариант с меньшим риском реализации.

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

Ведущие дизайнеры на регулируемых проектах (телемедицина, финансы, видеонаблюдение) имеют 5–10 и более лет опыта в соответствующей области. Мы не поручаем джунам работу с HIPAA — и заранее сообщаем, кто будет задействован, ещё до подписания договора.

Как вы рассчитываете стоимость дизайна?

Либо фиксированный объём (от исследования до визуального дизайна, 4–8 недель), либо T&M внутри инженерного контракта. Цену называем после установочного созвона — оценка обоснована: у каждого диапазона есть своя причина.

Вы проектируете для мобильных устройств, веба и кросс-платформенных решений?

Все три. У нас есть отдельные паттерны для адаптивного веба, нативных iOS и Android, кросс-платформенных решений (React Native, Flutter), а также для смарт-ТВ и киоск-форматов — в зависимости от требований проекта.

Можем ли мы познакомиться с дизайнером до подписания договора?

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

Что почитать дальше

Готовы проектировать осознанно, а не наугад?

Дизайн в Фора Софт — это перевод: из сложного домена в продукт, которым приятно пользоваться. Мы исследуем, прежде чем сделать первый набросок, создаём системы, а не отдельные экраны, закладываем доступность в токены и остаёмся в проекте с самого запуска и далее. Искусственный интеллект берёт на себя рутину, чтобы больше времени оставалось на мастерство и экспертизу. Так мы выпустили более 625 продуктов за 20 лет — и именно это мы принесём в ваш следующий проект.

Если вы выбираете дизайн-партнёра, самый быстрый способ получить полезный ответ — короткий созвон с ведущим дизайнером, который будет работать над вашим проектом.