Крис Штраль, Основатель и Генеральный Директор Knapsack – Интервью Серия

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

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

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

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

Переход от агентской и консалтинговой работы к построению продукта компании показал более глубокую проблему, которую существующие инструменты систем дизайна и платформы рабочего процесса не решали. Какой был основной пробел, который сформировал архитектуру и направление Knapsack?

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

Эра “холста” уступает место живым, связанным с кодом системам. Как вы определяете этот сдвиг, и что меняется для команд, когда создание продукта переходит от статических файлов к непрерывно обновляемым системам?

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

Генерируемый агентом UI часто терпит неудачу без системы записи, отражающей реальные компоненты, правила и ограничения. Почему эта якорная层 необходима для того, чтобы ИИ производил готовые к предприятию интерфейсы?

ИИ может синтезировать компоновки и копию, но ему нужен авторитетный словарь, чтобы производить готовые к предприятию интерфейсы. Якорная слой, содержащий конкретные компоненты, свойства, ограничения, токены и правила использования, дает ИИ границы, которые он должен уважать. Без него агенты выдумывают стили, игнорируют требования доступности или генерируют код, который не соответствует тому, что инженерные команды фактически отгружают. С реальным графом компонентов и набором правил агенты производят результаты, которые являются реализуемыми, соответствующими и согласованными с брендовыми стандартами. Это разница между красивым макетом и развертываемым интерфейсом.

Когда Интеллектуальный Продуктовой Двигатель развивался, что оказалось наиболее трудным в объединении активов дизайна, кода, бренд-правил, требований соответствия, шаблонов UX и данных производительности в одну согласованную систему?

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

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

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

После Серии А, что стало приоритетными областями фокуса для ускорения разработки продукта и корпоративного внедрения?

Серия А позволила нам ускорить в трех областях. Первое – это процесс ингестии и настройки, который позволяет предприятиям создать систему записи за несколько дней вместо месяцев. Второе – это Интеллектуальный Продуктовой Двигатель, включая возможности, выровненные с моделью, которые обеспечивают, что сгенерированные интерфейсы уважают бренд и правила. Третье – это корпоративные контроли, такие как разрешения, аудит и крючки соответствия, которые обеспечивают, что лидеры чувствуют уверенность в принятии Knapsack во всей крупной организации. Эти рычаги стимулируют реальное внедрение в масштабе.

Корпоративные команды часто борются с переходом от статических рабочих процессов к динамическим, готовым к агенту системам. Какие являются наиболее значительными препятствиями, и как Knapsack помогает организациям адаптироваться?

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

Когда создание продукта становится все более автоматизированным, какие новые возможности, по вашему мнению, команды должны разработать, чтобы оставаться эффективными в среде, где ИИ генерирует больше основной работы?

Командам необходимо разработать более сильные системные навыки мышления, в частности, способность создавать ограничения, политики и контракты компонентов, которые агенты могут использовать. Они также нуждаются в лучших практиках мониторинга и проверки, включая наблюдаемость в решениях агентов, контроли рулонов и рамки Q&A для сгенерированного UI. Грамотность управления становится необходимой, особенно способность выражать требования соответствия, доступности и конфиденциальности в машиночитаемом формате. Организации, которые преуспеют, будут теми, которые смогут кодифицировать политику и качество в своих системах.

Оглядываясь вперед на пять лет, как вы ожидаете, что создание продукта, обусловленное ИИ, будет эволюционировать, и какую позицию вы хотите, чтобы Knapsack занял на следующем этапе отрасли?

Через пять лет создание продукта будет напоминать композицию сервисов против живого графа компонентов, а не передачу статических компов между командами. Агентские инструменты будут генерировать готовые к производству поверхности, используя политики, бюджеты производительности и бренд-ограничения. Моя цель – сделать Knapsack канонической системой записи, на которую агенты и приложения полагаются, чтобы понять истинные примитивы UI и правила компании. Это включает в себя глубокую интеграцию с моделями и CI/CD, сильное управление для регулируемых предприятий и быструю настройку для новых команд. Knapsack должен быть доверенным слоем для бренда, поведения и безопасности, когда компании позволяют агентам работать более автономно.

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