Дизайн-команда Фора Софт изнутри: процесс, система и AI после 20 лет работы

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

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

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

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

Самая полезная ментальная модель, которую мы выработали за 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-дизайна.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что мы сделали. Ведущий дизайнер провёл две недели рядом с активными трейдерами — наблюдал сессии, фиксировал паттерны сканирования и составил карту трёх показателей, к которым трейдер тянется в первые 2 секунды после открытия приложения. Затем мы выстроили мобильную информационную архитектуру: 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%).

Бизнес-KPI. Прирост активации после редизайна (обычно 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), а также для смарт-ТВ и киоск-форматов, когда этого требует проект.

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

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

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

Готовы проектировать осмысленно, а не по наитию?

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

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