Проектирование и разработка интерфейсов: инхаус или аутсорс

Так обычно и выясняется, что проектирование и разработка интерфейсов — не слой лака поверх продукта, а часть системы. Просто у неё другие логи: воронка, тепловые карты, саппорт, NPS, записи сессий, мат в чате продаж. И вопрос «инхаус или аутсорс» здесь не про вкус. Это вопрос владения контекстом, скорости, стоимости и того, кто будет разгребать последствия после релиза.

Экономика владения: штатный дизайнер стоит не только зарплату

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

Штатный UX/UI-дизайнер — это не строка «зарплата» в табличке. Это рекрутинг, испытательный срок, оборудование, софт, обучение, менеджмент, налоги, соцпакет, отпуск, больничные, внутренние встречи, простои между задачами. Накладные расходы легко добавляют 20–30% сверх фонда оплаты труда. Не потому что кто-то жадный. Просто физика процесса.

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

Инхаус выгоден, когда интерфейс — постоянный фронт работ. Личный кабинет, CRM, SaaS, маркетплейс, банковский продукт, B2B-платформа с ролями, правами, статусами и прочей веселухой. Там дизайн не заканчивается на релизе. Он живёт. Сегодня меняем форму заявки. Завтра добавляем новый тип пользователя. Послезавтра выясняется, что бухгалтерия ломает сценарий, потому что поле «контрагент» спрятали на второй шаг. Классика.

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

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

Контекст: почему штат выигрывает в долгую

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

Штатный дизайнер каждый день видит одну и ту же систему. Он знает, почему в профиле нельзя просто удалить поле. Потому что его читает биллинг. Знает, почему фильтр по статусам выглядит уродливо. Потому что статусов 17, четыре из них легаси, два нужны только саппорту, один нельзя показывать клиенту, но он всё равно всплывает в API. Красота.

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

Это и есть 100% вовлечённость инхаус-дизайнера в продукт. Не в смысле «горит глазами». Оставим это HR-лендингам. В смысле доступа к ежедневному шуму: тикетам, багам, фидбеку продаж, аналитике, спорам с разработкой, ограничениям фронта, тупикам бэка. Дизайнер начинает проектировать не картинку, а рабочий путь через систему.

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

Проблема не в макете. Проблема в том, что через два месяца после сдачи кто-то добавляет новый бизнес-процесс, а в команде уже нет человека, который помнит, почему компонент был сделан именно так. Начинается археология. «А почему тут disabled?» «А зачем тут второй CTA?» «А что значит статус pending_review_hold?» Отлично. Открываем Figma, Jira, Slack, Notion. Ищем истину среди костылей.

Где инхаус особенно силён

Есть типы продуктов, где штатная UX/UI-команда почти неизбежна:

1. Сложные B2B-системы. Много ролей, прав, статусов, интеграций. Интерфейс связан с бизнес-процессами, которые не помещаются в бриф.

2. Продукты с постоянной итерацией. SaaS, финтех, e-commerce, личные кабинеты, внутренние платформы. Каждая неделя приносит изменения.

3. Системы с накопленной аналитикой. Когда решения надо принимать не по вкусу CEO, а по данным: воронкам, когортам, сегментам, ошибкам ввода.

4. Команды, где дизайн плотно связан с разработкой. Если дизайнер каждый день обсуждает ограничения компонентов, API, состояния загрузки, ошибки и пустые экраны — внешний подрядчик быстро превращается в прокси с задержкой.

5. Продукты с долгим жизненным циклом. Если интерфейс будет жить годы, дешевле выращивать экспертизу внутри, чем каждые полгода объяснять заново, почему нельзя «просто сделать красиво».

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

Аутсорс: когда скорость важнее полного погружения

Теперь про внешних подрядчиков. Разработка UI/UX на аутсорсинге — не магическая кнопка «сделать интерфейс». Это покупка готового процесса и доступа к специалистам, которых долго и дорого держать в штате.

Надо запустить MVP? Агентство часто быстрее. У него есть исследователь, UX-дизайнер, UI-дизайнер, копирайтер, арт-директор, иногда фронтенд. Не надо три месяца закрывать вакансии. Не надо спорить с рекрутером, почему «Figma уверенный пользователь» — это не компетенция. Подрядчик заходит пакетом.

Особенно хорошо аутсорс работает, когда задача ограничена:

• сделать прототип нового сервиса для проверки спроса;
• собрать дизайн лендинга под запуск продукта;
• перепроектировать критичный сценарий: регистрация, оформление заказа, онбординг;
• подготовить UI-kit или первую версию дизайн-системы;
• провести UX-аудит и найти очевидные точки потерь;
• закрыть редкую экспертизу: motion, иллюстрации, accessibility, сложная типографика, дизайн дашбордов.

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

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

Но есть минусы. И они не декоративные.

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

Второй — зависимость от коммуникации. Аутсорс не читает мысли. Если владелец продукта пропадает на неделю, ревью не идёт, данные не дают, аналитика в виде скриншота из Excel — получите интерфейс по догадкам. Потом начнётся «мы имели в виду другое». Нет, не имели. Вы молчали.

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

Хороший аутсорс экономит месяцы. Плохой аутсорс оставляет после себя Figma-мавзолей и двадцать нерешённых состояний формы.

Дизайн-система: мост, без которого всё разваливается

Если в компании спорят «инхаус или аутсорс», но не говорят про дизайн-систему, можно сразу открывать incident channel. Будет боль.

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

При работе с аутсорсом дизайн-система критична по двум причинам.

Во-первых, она задаёт границы. Подрядчик не изобретает каждый раз новый select, новую модалку и новый empty state. Он работает в рамках продукта. Это снижает хаос и ускоряет разработку.

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

Минимальный набор, который должен остаться после серьёзной работы:

1. Библиотека компонентов в Figma. Не просто нарисованные кнопки, а варианты, состояния, свойства, auto layout без шаманства.

2. Правила типографики. Заголовки, текст, подписи, ошибки, числовые данные, таблицы. Типографика в вебе — это не «поставим Inter и норм». Нет, не норм.

3. Цветовые токены. Основные, вторичные, статусы, фоны, границы, состояния hover/focus/disabled/error.

4. Сценарии и паттерны. Как строятся формы, фильтры, таблицы, модалки, уведомления, пустые состояния, ошибки API.

5. Документация для разработки. Что происходит при загрузке, ошибке, отсутствии данных, долгом ответе сервера, конфликте прав. Если этого нет, разработчик придумает сам. Потом не плачьте.

6. Правила расширения. Как добавлять новый компонент, кто ревьюит, где живёт changelog, как синхронизируется дизайн и фронтенд-библиотека.

Особенно это важно в гибридной модели, где часть задач делает штат, часть — агентство. Без дизайн-системы гибрид превращается в зоопарк. Один подрядчик любит скругления 12 px, другой — 8 px, внутренний дизайнер устал и сделал 10 px. Где-то в углу плачет Storybook.

Коммуникация: главный скрытый интерфейс

У интерфейса есть пользовательский слой. И есть слой производства. Второй обычно страшнее.

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

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

Разница выглядит примерно так:

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

Для создания интерфейсов для бизнеса опаснее всего не выбор модели, а иллюзия, что модель сама всё решит. Не решит. Если у продукта нет владельца, нет метрик, нет доступа к пользователям, нет нормального процесса разработки — дизайнеры будут перекладывать пиксели. Инхаус, аутсорс, гибрид — неважно. Garbage in, garbage out. Да, это не только про базы.

Гибридная модель: нормальный вариант, если не делать из неё свалку

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

Это здраво. Штат держит контекст. Аутсорс добавляет мощность. Но схема работает только при жёстком владении архитектурой интерфейса внутри компании.

Как это обычно выглядит без костылей:

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

2. Аутсорс закрывает выделенный объём. Новый раздел, редизайн потока, UI-концепт, исследование, дизайн-система, визуальная часть.

3. Дизайн-система принадлежит компании. Подрядчик может её развивать, но не должен быть единственным носителем знания.

4. Ревью проходит внутри. Не «понравилось/не понравилось», а проверка на сценарии, доступность, компоненты, разработку, метрики.

5. Передача в разработку формализована. Макеты, состояния, спецификации, связи с задачами, acceptance criteria. Иначе фронт опять будет гадать.

Гибрид плох, когда компания пытается сэкономить на всём сразу. Один внутренний дизайнер «на подхвате», три подрядчика без общего стандарта, продакт занят, разработка узнаёт о редизайне за два дня до спринта. Это не гибрид. Это distributed monolith, только в дизайне.

Хороший гибрид похож на нормальную инфраструктуру. Есть owner. Есть правила. Есть репозиторий знаний. Есть ревью. Есть мониторинг качества. Нет магии.

Как выбирать без религиозной войны

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

Выбирать надо по параметрам продукта.

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

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

Если компания растёт и не понимает, сколько дизайна ей нужно, гибрид — разумный промежуточный режим. Один сильный внутренний владелец интерфейса плюс внешняя команда под объём. Дальше смотреть по нагрузке: если задачи постоянные — нанимать. Если волнами — держать подрядчиков.

Вот грубая диагностика без шаманства:

Главное — не врать себе про зрелость. Если внутри нет человека, который может принять дизайн-решение, а не просто сказать «мне нравится», аутсорс станет дорогим генератором вариантов. Если внутри нет времени на онбординг дизайнера, инхаус тоже не взлетит. Человек не телепортируется в контекст. 3–6 месяцев на сложный продукт — нормальный срок, а не баг.

Что остаётся после релиза

Хороший интерфейс после релиза оставляет не только экраны. Он оставляет систему: компоненты, правила, понятные сценарии, измеримые изменения, меньше тикетов в саппорт, меньше ручных объяснений, меньше случайных решений.

Инхаус лучше хранит эту систему внутри. Аутсорс быстрее приносит недостающую мощность и методологию. Гибрид позволяет не выбирать религию, если хватает дисциплины.

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

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

А теперь сухой остаток для тех, кто любит проверять не презентации, а систему. Перед стартом выполните хотя бы это:

1. backup продуктового знания: выгрузите текущие сценарии, метрики, боли пользователей, ограничения разработки.

2. audit дизайн-активов: Figma, компоненты, токены, документация, фронтенд-библиотека.

3. grep по саппорту: найдите повторяющиеся жалобы на интерфейс, а не фантазируйте в переговорке.

4. diff между макетом и продом: посмотрите, где дизайн уже разъехался с реализацией.

5. assign owner: назначьте владельца интерфейса с правом принимать решения.

6. document or die: фиксируйте компоненты, состояния, правила и причины решений.

7. backup again: делайте бэкапы макетов, библиотек, решений и контекста. Особенно перед тем, как «быстро отдать подрядчику».

Потому что прод падает не только от плохого кода. Иногда его валит кнопка, которую никто не считал частью системы.