«Мусор входит, сокровища выходят»: главный дизайнер Anthropic рассказывает о философии продукта Cowork и правде о запуске за 10 дней

整理 & 编译：深潮TechFlow

Гость: Jenny Wen, руководитель отдела дизайна Cowork

Ведущий: Peter Yang

Источник подкаста: Peter Yang

Заголовок: Claude Cowork Tutorial from Cowork s Design Lead (40 Min) | Jenny Wen

Дата выхода: 2026年3月29日

Краткое изложение ключевых моментов

Jenny — руководитель отдела дизайна Cowork. Она подробно рассказала мне о том, как устроены процессы в Anthropic изнутри: о том, как она использует дизайн и разработку Cowork для создания продуктов, а также о реальной истории, стоящей за появлением Cowork. В Anthropic почти каждый день выходят новые функции — и то, как они работают, меня действительно очень поразило.

Краткое резюме ярких мыслей

О том, как выглядит повседневная работа

Большая часть того, что я делаю, — это выпуск продукта наружу. Но я думаю, что сейчас это может выглядеть не так, как пару лет назад. Значительная часть работы — это на самом деле совместная “жам-сессия” (improvisational collaboration) с инженерами, людьми из продуктовых команд и т. п. Обычно мы вместе смотрим на прототип и указываем на то, как он может развиваться и к чему прийти дальше.

О философии использования “плохое — в мусор, ценное — наружу”

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

О различиях между Cowork и Claude Code

Помимо очень детальной работы по написанию production code, сейчас почти все мои задачи я делаю с помощью Cowork. Если же есть сценарии, где нужно сфокусироваться на некоторых деталях кода, я все равно буду использовать Claude Code. Но для повседневных коммуникаций и совместной работы сейчас я полностью полагаюсь на Cowork.

О реальной истории появления Cowork

Фраза “они сделали это за 10 дней” — на самом деле вырвана из контекста: ее вырезали из какого-то интервью или медиа-материала. Но реальность такая: в направлении Cowork мы уже начали думать еще с того момента, когда я год назад присоединилась к Anthropic. Мы все время размышляли о том, как создать “партнера по мышлению” (thinking partner), который будет помогать всем универсальным специалистам по интеллектуальной работе.

Хотя Claude Code уже отлично справляется с задачами, связанными с кодом, наша цель — охватить все сценарии работы со знаниями. И я думаю, настоящее испытание было в следующем: как именно мы реализуем эту идею? Какая архитектура будет наиболее подходящей? Какой UX (пользовательский опыт) будет правильным?

О развитии дизайнерского процесса

Я по-прежнему делаю Figma. Но сейчас мы не так часто делаем спецификации, и они обычно не такие подробные. Мы все еще расставляем приоритеты: это все равно существует как документ, но обычно там всего несколько bullet points — не те красивые таблицы, которые выглядят как результат чрезмерного дизайна.

О планировании и видении

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

О будущем для дизайнеров

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

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

Открытие

Peter Yang: Всем привет, сегодня я очень рад поприветствовать руководителя отдела дизайна Anthropic — Jenny. Jenny покажет, как она использует Claude Cowork и Claude Code, чтобы проектировать и выпускать продукты, и также расскажет внутреннюю историю Cowork; возможно, поговорим и о том, как будут выглядеть ее следующие шаги в продукте.

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

Jenny:

Я не знаю, есть ли вообще такой “типичный типичный день”, но большую часть времени я трачу на то, чтобы выпускать продукт. Однако я думаю, что это может выглядеть иначе, чем год-два назад. В частности, значительная часть — это совместная jam-сессия (improvisational collaboration) в довольно неформальном формате с инженерами, людьми из продуктовых команд и т. д. Обычно мы вместе смотрим на прототип и указываем на то, как его можно развить дальше. Иногда это просто обсуждение того, как проявляется функциональность; иногда — когда я сама что-то реализую. Я считаю, что все еще большая часть времени — это когда я проектирую, делаю прототипы и т. п., но сейчас сам процесс дизайна ощущается более свободным.

Peter Yang: То есть, по сути, ты через Claude генерируешь пачку прототипов, а потом вместе с инженерами “жамишь”, даешь фидбек, а дальше используешь промпты, чтобы AI улучшал их — правильно?

Jenny:

На самом деле обычно это даже не прототипы в привычном смысле, а рабочие прототипы, которые уже построены внутри нас в виде экземпляров Claude или Cowork и запускаются. Я обычно трачу время на то, чтобы использовать этот функционал, продвигать его, смотреть, на что он способен, формировать мнение; а следующий шаг итерации обычно такой: я сажусь и говорю инженерам примерно следующее: “Эй, вот как я это вижу. Вот что, на мой взгляд, должно быть изменено”. Я думаю, что по-прежнему очень-очень важно, чтобы у меня было время на итерации, шлифовку и доведение до качества внутри дизайнерских инструментов. Просто, поскольку я одновременно веду больше проектов, я ощущаю, что сейчас более эффективен способ действовать очень свободно и неформально.

Peter Yang: Я думаю, это всегда была самая приятная часть для меня как product manager или дизайнер: свести вместе дизайнера и инженера, смотреть, как продукт итеративно улучшается. Поэтому вы сейчас не так часто делаете планы в виде спецификаций, Figma-документов и т. п.? Или вы просто итеративно обновляете прототипы прямо в коде?

Jenny:

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

Демонстрация Cowork на практике

Peter Yang: Можешь показать нам, как ты используешь эти продукты, или что именно ты делаешь каждым из них?

Jenny:

Конечно. Я расскажу, как я использую Cowork. У меня есть небольшая тайна: кроме очень детальной работы по написанию production code, сейчас почти все мои дела я выполняю с помощью Cowork. Если же нужно сфокусироваться на некоторых деталях кода в конкретных сценариях, я все равно использую Claude Code. Но для повседневной коммуникации и совместной работы сейчас я полностью полагаюсь на Cowork.

Я думаю, самое впечатляющее в Cowork — это его способность к структурированию информации. Я люблю называть это “плохое — в мусор, ценное — наружу”. Он может собирать информацию из самых разных источников, затем быстро выделять ключевые моменты, извлекать ценное содержимое и превращать это в результаты, которые реально повышают производительность.

Пример: сейчас я подключил папку, в которой хранятся записи пользовательских интервью. Наша команда Cowork очень ценит тесную связь с пользователями — и это одна из ключевых причин некоторого нашего успеха. Мы проводим традиционные исследования пользовательского опыта (UXR) и напрямую разговариваем с пользователями. Также мы делаем это в режиме внутреннего “self-use”, например: у нас есть специальный Slack-канал для сбора фидбека. Кроме того, мы следим за обсуждениями в социальных сетях и прислушиваемся к мнению самых вовлеченных пользователей. Именно потому, что мы постоянно держим тесную связь с пользователями и можем быстро итеративно улучшать продукт, мы можем постоянно совершенствоваться и добиваться тех результатов, которые у нас есть сейчас.

Итак, что я делаю сейчас: я говорю Claude: “Эй, у меня есть папка с этими интервью”. Но я также прошу Claude заглянуть в соцсети, Reddit и в другие отзывы клиентов Cowork, чтобы он сказал мне, какие крупнейшие инсайты он нашел. Это может занять некоторое время, потому что он действительно должен обработать так много данных и переработать их. Но он сделает некоторые вещи: например, иногда может развернуть дочерних агентов параллельно и обрабатывать вместе, а также потратить время на поиск в интернете.

Peter Yang: В вашей реальной работе у вас есть что-то вроде еженедельного отчета с инсайтами — автоматом сводит все и отправляет тебе и команде?

Jenny:

Сейчас мы можем сделать это прямо через Cowork. Я думаю, у нас есть исследовательская команда, которая готовит и выпускает это, и еще у нас есть версия, которая пингует нас в Slack. Мы также напрямую слушаем внутренние Slack-каналы. Мы очень полагаемся на внутренние и на самых сильных пользователей, которые дают нам такой фидбек “на передовой”, потому что внутренние люди действительно готовы быть с тобой честными — они часто доводят функции до самого дальнего предела и дальше проще отслеживают.

Peter Yang: Я думаю, так и должно происходить, и я ощущаю, что в большинстве компаний команды между собой слишком разобщены. Но в Anthropic ощущение совсем другое.

Jenny:

Я думаю, это также важная часть успеха Claude Code — умение слушать “полевых” пользователей. И это же то, чем мы очень много занимались в Figma: много внутреннего dogfooding. Потому что особенно когда речь идет про интеракционный дизайн и шлифовку, внутренние сотрудники реально “тыкают” в детали. А внешние пользователи часто дают фидбек скорее про то, подходит ли это для их пользовательского процесса — и поэтому это обеспечивает совершенно другой уровень фидбека.

Границы пользователей: Cowork vs Claude Code

Peter Yang: Я знаю, что маркетинг Anthropic, product managers сейчас в основном все делают с помощью Claude Code, особенно после того, как он стал доступен внутри Cowork. Как ты смотришь на различия по типам сценариев использования? Или как люди используют Cowork и Claude Code?

Jenny:

Мы заметили, что общий круг применения Cowork постепенно расширяется, и его начали использовать в сценариях, похожих на те, которые ранее пробовали “продвинутые” пользователи, использующие Claude Code. Помнишь, когда мы только начали разрабатывать Cowork? Внутренняя sales-команда была нашим основным источником информации. Среди них были несколько глубоко продвинутых пользователей Claude Code, которые использовали его, чтобы генерировать списки потенциальных клиентов, писать скрипты для звонков и т. д. Когда я впервые увидела эти кейсы, я очень удивилась, потому что тогда я даже не думала, что Claude Code можно использовать для выполнения таких задач. А сейчас эти пользователи почти полностью перешли на Cowork, и даже их коллеги начали регулярно использовать Cowork.

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

Полный процесс: от инсайтов к исполнимым Artifact

Jenny:

Тут есть семь разных тем, и каждую неделю они разные. Я в основном могу прямо сказать: “Помоги мне создать этот документ X”, и он уже автоматически будет существовать в папке на моем компьютере. Я также могу запустить одновременно две параллельные задачи. Например, я могу сказать: “Эти инсайты классные. Но на их основе — какие реальные продуктовые функции мне следует построить?” Затем я могу параллельно сделать еще одну вещь — на основе только что сгенерированного инсайт-документа превратить это в презентацию, которую я смогу показать команде во время kick-off на этой неделе.

Но в итоге отсюда я могу начать проектировать процесс дальше — он даст мне разные варианты функций. Оттуда даже можно попросить Claude помочь создать для этих функций wireframe. Он может дать мне целую кучу разных вариантов, а я уже буду переносить их в Figma, чтобы действительно детально проработать; или перенесу их в Claude Code, чтобы, используя наши реальные компоненты дизайн-системы, превратить в “настоящие” вещи. И дальше я буду двигаться от этой точки.

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

Peter Yang: Все дело в итерациях, все дело в итерациях. Сейчас я тоже стал ленивее: я всегда позволяю AI сделать первую версию, а потом я реагирую.

Jenny:

Да. Поэтому если ты действительно хочешь, чтобы я с нуля整理(собрала) эти инсайты в какой-то приоритизированный список функций, то сейчас на это уйдет гораздо больше времени, чем раньше.

Я делаю так же. Например, вот ты прислал мне эти заметки к подкасту: у меня есть личная папка заметок — там есть содержимое 1:1 встреч, случайные мысли и т. п. И я просто говорю: “Прочитай мои личные заметки, помоги мне продумать ключевые пункты для выступления по этому подкасту и помоги мне понять, что именно я хочу здесь сказать”. Конечно, я не буду зачитывать все слово в слово, но оно действительно помогает мне открыть мыслительный процесс, помогает мне эволюционировать свои размышления, а не застревать.

Skills и личная база знаний

Peter Yang: Какие skills ты используешь? Или есть ли у тебя personal-only skills для создания этих документов и слайдов?

Jenny:

Внутри у нас есть несколько skill, которые специально предназначены для документов и презентаций, потому что они помогают нам сохранять единый стиль бренда. У меня, честно говоря, нет собственной коллекции personal skill: в большинстве случаев я просто беру внутренние готовые skill и использую их для разных целей.

Peter Yang: Например, у меня есть writing skill, и он говорит AI не использовать вот эти AI slop-слова.

Jenny:

Но на самом деле я обнаружила, что сейчас, когда я использую папки Cowork — туда складываются все мои личные заметки и т. п. — он понимает меня именно через эти папки, и для меня это уже оказалось очень полезным. Я даже чувствую, что мне все меньше и меньше нужны memory и skills, потому что у него уже есть база знаний обо мне. Конечно, я все еще считаю, что skills имеют подходящие сценарии, но в моем текущем использовании мне лично потребность в них кажется гораздо меньше.

Peter Yang: Потому что он каждый день автоматически обновляет память по твоим разговорам?

Jenny:

Да, в основном это и есть memory, которую я поддерживаю сама, потому что я все время делаю там заметки.

Узлы командного взаимодействия

Peter Yang: То есть в процессе целиком — когда ты подключаешь команду? Или ты делаешь итерации с AI, а потом итерации с командой в обратную сторону и так туда-сюда, или как это устроено?

Jenny:

В моем понимании вещи вроде реальных UXR-интервью я сама не делаю — этим занимаются либо product manager, либо исследователи в команде, либо другие люди из команды. А затем, через это, ты напрямую делишься artifact, подключаешь их — и это фактически становится основой того, как работает команда.

Наша команда как минимум довольно bottom-up и демократичная. Поэтому мы делаем так: даем всем инсайты и цели, и дальше каждый делает свои прототипы, пробует разные вещи — идеи приходят со всех сторон. Это не так, что “все решения придумывает дизайнер”; скорее: “Эй, вот инсайты. Вот цель, к которой мы должны прийти в этом месяце. Как нам вместе этого достичь?”

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

Peter Yang: Когда люди обсуждают в интернете вкус и способность к суждениям, мне кажется, что методы формирования этих навыков — это именно постоянное получение большого количества product feedback изнутри и снаружи. В этом процессе у тебя постепенно появляется интуиция — способность замечать, где что-то пошло не так, где нужно поправить. Потому что каждый день ты слушаешь и обрабатываешь эти фидбеки, и со временем у тебя появляется особая чувствительность к проблемам.

Jenny:

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

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

Реальная история появления Cowork

Peter Yang: Давай поговорим о том, как появился Cowork. Снаружи много историй о том, что он был сделан за 10 дней, но до этого же уже были итерации, верно?

Jenny:

Эта фраза “они сделали за 10 дней” — на самом деле вырезана из какого-то интервью или медийного материала; вокруг нее потом долго спорили. Но реальность такова: в направлении Cowork мы уже начали продумывать это еще тогда, когда я присоединилась к Anthropic год назад. Мы постоянно размышляли о том, как создать “партнера по мышлению” (thinking partner) для всех универсальных специалистов по интеллектуальной работе. Хотя Claude Code уже умеет хорошо решать задачи, связанные с кодом, наша цель — охватить все сценарии работы со знаниями. И я думаю, ключевой вызов был в следующем: как реализовать эту идею? Какая архитектура будет наиболее подходящей? Какой UX (пользовательский опыт) будет правильным?

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

Когда мы решили выпускать этот продукт, весь процесс был очень быстрым: от “нам нужно выпускать” до того, что продукт уже в онлайне — всего 10 дней. Это в основном потому, что во время каникул, когда все работали с Claude Code, мы увидели его потенциал. В отпуске у многих людей наконец нашлось время попробовать Claude Code, и даже некоторые не-технические пользователи начали пользоваться им: например, чтобы разбирать транскрипты подкастов или проводить сложный анализ данных и т. п. Мы обнаружили, что AI-агентная архитектура Claude Code начала демонстрировать раннее product-market fit даже у не-технических пользователей. На самом деле внутри у нас уже был рабочий прототип, но изначально планировали выпускать чуть позже. Однако эти фидбеки заставили нас понять: “сейчас — лучшее время”. И тогда мы решили воспользоваться шансом — именно так и появились те безумные 10 дней.

Peter Yang: Если я правильно понял, в течение прошлого года вы делились в своей внутренней Slack множеством прототипов, собирали много фидбека и в итоге определились с рабочим прототипом. Затем, увидев, что рынку это нужно, вы быстро сделали спринт и вывели продукт.

Jenny:

Да, примерно так и было. Мы изначально планировали запуститься через несколько недель, но тогда мы почувствовали: “сейчас — лучшее время”. Это также заставило нас сузить область продукта до более реального и реализуемого уровня в условиях нехватки времени — и вложить всю энергию и ресурсы. В итоге выпуск удался.

Ранние итерации дизайна: от workflow-инструмента к минималистичному чату

Peter Yang: Можешь поделиться некоторыми знаниями о ранних итерациях или показать то, что вы разрабатываете прямо сейчас?

Jenny:

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

Раннее в этом году у нас был ранний прототип, сделанный мной совместно с другим дизайнером. Тогда мы пытались сделать этот инструмент более task-oriented или workflow-oriented. Потому что нам очень не хотелось рисковать тем, что пользователи не поймут, смогут ли они с помощью Cowork решать какие-то конкретные задачи или получать четкие результаты (outcome), например создавать дашборд (dashboard) или объединять данные из разных источников. Поэтому тогда мы спроектировали интерфейс максимально структурированным — почти как workflow-инструмент: например “добавьте вот это, это inputs; вот это outputs”. А чат-функцию мы поставили на второе место.

Но казалось, что нужно пройти слишком много шагов, чтобы что-то сделать. И в эпоху 2025 года — почему мы делаем все так сложно? Разве не проще просто дать Claude все обработать?

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

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

И выпущенная несколько недель назад версия — это то, как сейчас все выглядит. Мы пробовали UX почти в стиле “wizard-like”: пользователи нажимают, и перед ними появляется подсказка типа “создай документ, длиной в три–пять страниц” и т. д.

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

То, что ты видишь сейчас, интерфейс стал существенно проще. Мы убрали тяжелые боковые панели (sidebars), чтобы он был ближе к традиционному чату, но на главной странице мы внесли некоторые изменения: теперь он выглядит скорее как “to-do list”, который мы с Claude делим, а не как чат-инструмент, полный сложных рекомендаций и инструкций.

Peter Yang: Возможно, в будущем он сможет поддерживать несколько агентов (agent) и перетаскиванием задач управлять workflow.

Jenny:

Возможно, такое действительно будет. Но я хочу подчеркнуть: UI-дизайн примерно 4–5 недель назад был совсем другим. Мы все время учимся, исследуем, какой дизайн работает лучше, а какой — хуже, и продолжаем искать лучший способ представить эту технологию пользователям.

Различия позиционирования Cowork и Claude Code

Peter Yang: Во время использования Claude Code я часто делюсь фидбеком в Twitter. Там встроено много slash commands, и пользователям приходится понемногу их учить. Этот опыт немного напоминает “поиск сокровищ” (treasure hunt) в Costco: ты никогда не знаешь, что откроешь — какие новые функции там окажутся.

Но для новичков это не очень дружелюбно. Это скорее игра, где со временем, по мере того как ты пользуешься, ты постепенно знакомишься и осваиваешь ее. Я ощущаю, что Cowork, возможно, пытается найти “середину” между обычным чат-инструментом и Claude Code. Он не прячет все функции полностью, но при этом каким-то образом помогает пользователям использовать их более эффективно.

Jenny:

Да. В Cowork по-прежнему поддерживаются slash commands, но они не являются основным способом взаимодействия. Я лично думаю, что Cowork — это, по крайней мере, инструмент для профессионалов. Мы заметили, что многие пользователи уже используют его очень “продвинутым” образом, и в сообществе уже появились некоторые power users. Обычно они готовы выделять время на освоение более сложных функций, например на создание skills для себя, на обмен этими навыками с командой или на использование shorthand commands.

Но наша цель — сделать эти функции способом взаимодействия “второго уровня”, а не тем, чему пользователя принудительно нужно учиться. То есть даже если пользователь не знает все команды, он все равно должен легко пользоваться Cowork. Мы хотим, чтобы взаимодействие пользователя с Claude было естественным и интуитивным, а не требовало запоминания целого набора команд, чтобы что-то сделать.

Планирование процесса и видение

Peter Yang: Как выглядит ваш планировочный процесс в Anthropic? Вы делаете годовое планирование и постановку целей? Или больше полагаетесь на прототипирование и постоянные эксперименты?

Jenny:

Наш подход к планированию каждый раз немного разный. В моей команде мы делаем помесячное планирование. У нас есть электронная таблица: по крайней мере в части, касающейся Cowork, там максимум около 12 задач — это наши наивысшие приоритеты (P0). У каждой задачи есть ответственный (DRI), и каждую неделю мы проверяем: все ли еще мы на правильном пути? Мы также делаем некоторые квартальные или полугодовые планы, обычно с указанием одного ответственного человека: “Я думаю, нам нужно двигаться в этом направлении, и вот на что стоит обратить внимание”. Но эти планы не настолько строгие, чтобы “обязательно выполнить конкретные проекты”. Больше это дает команде общий ориентир, поэтому это довольно гибко.

Peter Yang: Относительно гибко, верно? Забавно, что я заметил: самые инновационные компании часто меньше делают годовые планы, а больше — через постоянные итерации и обучение на том, что узнают от пользователей. Делала ли ты в своей карьере что-то в духе North Star deck? И, как ты думаешь, это полезно?

Jenny:

Да, я делала. В прошлом году я делала North Star vision deck. Я считаю, что видение действительно ценно: оно показывает команде направление и помогает сохранять ясность в том, что именно мы собираемся делать дальше. Но поскольку технологическая сфера меняется крайне быстро, появляются новые модели, а темпы обновлений только ускоряются. Поэтому для нас годичное видение не слишком реалистично, не говоря уже о видении на два–пять лет — слишком много неизвестных.

Тем не менее, реальная роль видения — помогать людям двигаться в одном направлении, особенно в среде, где каждый может свободно создавать любые проекты. Поэтому сейчас я думаю, что временной горизонт видения — максимум три–шесть месяцев, и его можно представить в виде документа. Я думаю, когда видение визуализировано, оно оказывает более сильное влияние. И это большая ценность дизайна — уметь собрать разные элементы вместе и рассказать связную историю в рамках определенного периода. При этом видение также может быть не только статичным deck, но и прототипом. Оно может помочь синхронизировать работу между командами, особенно когда у нас есть пять команд, которые занимаются очень похожими или потенциально конфликтующими проектами. Дизайн может помочь этим идеям совпасть через кураторство: показать команде единое согласованное направление и проложить путь к желаемому пользовательскому опыту, а не распылять впечатления.

Peter Yang: Тогда у вас есть product manager review, или review для связанных сотрудников? Эти ревью формальные или они тоже участвуют в прототипировании?

Jenny:

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

Советы для дизайнеров: как найти свое место в эпоху AI

Peter Yang: Тогда что бы ты посоветовала дизайнерам, которые чувствуют, что их профессиональная среда быстро меняется? Стоит ли им начинать учиться отправлять код (PR)? Или дизайнерам нужно приспосабливаться другими способами?

Jenny:

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

Каждый раз, когда я чувствую, что моей профессии брошен вызов, у меня появляется легкая тревога — например: “Боже, моя работа сильно меняется, и, возможно, люди больше не будут ценить ее так, как раньше”. Но в такие моменты я думаю о моих коллегах-инженерах. Их работа уже давно прошла через огромные изменения, но они не только адаптировались — они еще и с невероятной смелостью и скромностью принимали вызовы и в итоге добивались более эффективных и более качественных результатов. Они — мой источник вдохновения. Я говорю себе: если мои очень уважаемые коллеги смогли это сделать, значит и я обязательно смогу. Они — пример того, как адаптироваться к изменениям.

Peter Yang: В некотором смысле эти изменения избавляют дизайнеров от множества рутинной повторяющейся работы — например, от того, чтобы тратить время на подгонку всяких рамочек — так что можно вкладывать больше усилий в размышления более высокого уровня и в креатив, да?

Jenny:

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