«Сміття входить, скарби виходять»: Головний дизайнер 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 майже щодня випускає нові функції, і спостерігати за їхнім способом роботи для мене було справді дуже вражаюче.

Огляд влучних думок

Про те, як виглядає робота щодня

Більшість того, що я витрачаю свій час, — це виведення продукту назовні. Але я думаю, що, можливо, це виглядає інакше, ніж рік-два тому. І значна частина цього насправді — це коли ми разом j am (імпровізаційна співпраця) у доволі неформальний спосіб: з інженерами, людьми з продукту тощо. Зазвичай усі разом дивляться на прототип, а потім вказують і міркують, як він може еволюціонувати.

Про філософію використання “сміття — вхід, коштовність — вихід”

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

Про різницю між Cowork та Claude Code

Крім дуже ретельної роботи над виробничим кодом (production code), майже все, що я роблю зараз, я виконую за допомогою Cowork. Якщо є сценарій, де потрібно сфокусуватися на певних деталях коду, я все ще використовую Claude Code. Але для щоденної комунікації та співпраці я зараз повністю покладаюся на Cowork.

Про реальну історію створення Cowork

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

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

Про еволюцію дизайнерського процесу

Я все ще роблю Figma. Але тепер ми не так часто створюємо специфікації, і зазвичай вони не такі детальні. Ми все одно робимо пріоритизацію — це все ще існує як документ, але зазвичай це лише кілька bullet points, а не ті красиві таблиці з надмірним дизайном.

Про планування та бачення

Технологічна сфера, в якій ми працюємо, змінюється надзвичайно швидко: з’являються нові моделі, і швидкість оновлень теж дедалі більша. Тому для нас формувати бачення на рік — не надто реально, не кажучи вже про бачення на два-п’ять років, адже існує забагато невідомих факторів.

Про майбутнє для дизайнерів

Якщо тобі здається, що під ногами земля рухається — це тому, що так і є: вона змінюється. Нам потрібно це визнати, навчитися адаптуватися, а також відкритим розумом заново подивитися на те, як ми зараз працюємо.

Кожного разу, коли я відчуваю, що моя професія під загрозою, я думаю про моїх колег-інженерів. Їхня робота вже давно пережила величезні зміни, але вони не лише адаптувалися до них — вони ще й із великою сміливістю та скромністю зустрічали виклики, а в підсумку отримували більш ефективні й якісніші результати роботи. Вони — джерело моєї натхненності: я кажу собі, що якщо мої колеги, яких я дуже поважаю, змогли це зробити, то я теж обов’язково зможу. Вони — мій приклад того, як адаптуватися до змін.

Початок

Peter Yang: Всім привіт, сьогодні я дуже радий(а) вітати керівницю дизайну Anthropic, Jenny. Jenny покаже нам, як вона використовує Claude Cowork і Claude Code, щоб проєктувати та випускати продукти, а також поділиться внутрішньою історією Cowork. Можливо, поговоримо ще й про те, яким буде наступний крок у розвитку її продукту.

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

Jenny:

Я не знаю, чи є таке “типове типове” для одного дня, але більшість часу, який я витрачаю, — це запуск/виведення продукту в світ. Але я думаю, що це, можливо, виглядає інакше, ніж рік-два тому. Значна частина цього насправді — коли ми разом j am (імпровізаційна співпраця) у доволі неформальний спосіб з інженерами, людьми з продукту тощо. Зазвичай усі разом дивляться на прототип, а потім вказують і міркують, як він може еволюціонувати. Іноді це просто обговорення того, як має проявлятися функціональність, іноді — я сама реалізую деякі речі. Я відчуваю, що й досі значна частина мого часу — це те, що я сама проєктую, роблю прототипи тощо. Але зараз спосіб організації дизайнерської роботи відчувається більш розслабленим.

Peter Yang: Тобто, по суті, ти генеруєш купу прототипів за допомогою Claude чи чогось подібного, і потім працюєш з інженерами в режимі j am, даєш зворотний зв’язок, а далі підказками налаштовуєш 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, спілкуємося безпосередньо з користувачами, а також використовуємо внутрішній спосіб “для себе”, наприклад, у нас є окремий Slack-канал, спеціально призначений для збору фідбеку. Крім того, ми звертаємо увагу на обговорення в соціальних мережах і прислухаємося до думок дуже зацікавлених користувачів. Саме тому, що ми постійно тримаємося дуже близько до користувачів і можемо швидко ітерувати продукт, ми можемо постійно вдосконалюватися й досягати результатів, які маємо сьогодні.

Отже, що я роблю зараз: я кажу Claude: “Гей, у мене є папка з інтерв’ю. Але нехай Claude також подивиться в соціальні мережі, Reddit та інші відгуки клієнтів Cowork і скаже мені, які найбільші інсайти”. Це може зайняти трохи часу, бо він реально обробляє стільки даних і їх переробляє. Але він зробить певні речі: наприклад, інколи може породжувати підагентів для паралельної обробки, і він також витратить час на онлайн-пошук.

Peter Yang: У твоїй практичній роботі у вас є щось на кшталт щотижневих звітів з інсайтами? Тобто воно автоматично підсумовує все й відправляє тобі та команді?

Jenny:

Насправді це вже можна зробити безпосередньо через Cowork. Я думаю, що наші дослідники мають сесію/зустріч, де вони випускають це, і в нас є ще версія, яку вони ping-а для нас у Slack. Ми також напряму слухаємо внутрішні Slack-канали. Ми дуже покладаємося на внутрішніх людей і на найсильніших користувачів, які дають нам такий передовий фідбек. Бо внутрішні люди справді готові сказати тобі чесно. Вони зазвичай штовхають функції до найкращих меж — і за ними найпростіше стежити.

Peter Yang: Я думаю, що так і має відбуватися, і я відчуваю, що в більшості компаній команди занадто відокремлені одна від одної. Але в Anthropic це зовсім не так.

Jenny:

Я думаю, що це також важлива частина успіху Claude Code — це вміння слухати користувачів “на передовій”. І це також те, що ми робимо дуже багато, коли працюємо у Figma: багато внутрішнього dogfooding. Тому що, особливо коли справа стосується інтеракційного дизайну й полірування, внутрішні люди реально “ткнуть” у ті деталі, а зовнішні користувачі зазвичай дають фідбек більше про те, чи це підходить під їхні user flow. І тому це надає зовсім інший рівень зворотного зв’язку.

Границі користування: Cowork vs Claude Code

Peter Yang: Я знаю, що зараз маркетинг Anthropic та product manager-и фактично вже працюють за допомогою Claude Code, особливо після того, як він став доступним у межах Cowork. Як ти бачиш різні типи сценаріїв використання? Або як люди використовують Cowork і Claude Code?

Jenny:

Ми помітили, що загальний діапазон застосування Cowork поступово розширюється, і його почали використовувати в деяких сценаріях, які раніше намагалися робити “передові” користувачі, як у випадку Claude Code. Пам’ятаєш, коли ми тільки почали розробляти Cowork, нашим основним джерелом інформації був внутрішній відділ продажів. Декілька з них були глибокими користувачами Claude Code: вони використовували його для генерації списків потенційних лідів, написання телефонних скриптів тощо. Коли я вперше побачила ці use case, я була дуже здивована, бо на той момент я навіть не уявляла, що Claude Code може бути використаний для таких задач. А зараз ці користувачі майже повністю перейшли на Cowork, і навіть їхні колеги почали часто використовувати Cowork.

Це, мабуть, тому, що тепер є гарний UI. Я думаю, саме цього й бракувало. І є ще одна причина: це дуже близько до іншої роботи, яку вони вже роблять. Вони ж і так користуються чат-функціями, і з цього desktop-додатку вони також можуть продовжувати використовувати Claude Code. Тож мені здається, що це краще відповідає їхньому поточному робочому процесу, ніж відкривати командний рядок.

Повний процес: від інсайтів до виконуваних Artifact

Jenny:

Тут є сім різних тем, і кожного тижня вони інші. Я можу майже напряму сказати йому: “Сформуй цей документ X”, і він уже автоматично буде існувати у папці на моєму комп’ютері. Я також можу одночасно запустити два паралельні завдання. Наприклад, я можу сказати: “Ці інсайти класні, але за їхніми результатами — які конкретні функції продукту я маю реально побудувати?” А тоді я паралельно можу зробити ще одну річ: перетворити цей документ з інсайтами на презентацію, яку я зможу показати команді під час kickoff цього тижня.

Але зрештою звідти я вже можу починати дизайнерський процес — він запропонує мені купу варіантів функцій. З того місця я навіть можу попросити Claude допомогти мені створити для цих функцій wireframe. Він може накидати мені купу різних варіантів, і я можу перенести їх у Figma, щоб реально деталізувати, або перенести в Claude Code — щоб зробити з них реальні речі, використовуючи наші справжні компоненти дизайн-системи. А вже потім можна починати звідти.

Ще я можу зробити так, щоб ці два процеси перетворилися на заплановані задачі. Тобто я приблизно налаштую, щоб він допоміг розкласти це завдання так, щоб воно запускалося автоматично кожного понеділка о 10 ранку. Тоді кожного понеділка о 10 я вже починатиму роботу з цією презентацією, маючи з собою три-чотири різні ідеї продукту — і це слугуватиме kickoff для тижня. Він дуже сильно стискає ітераційний цикл від фідбеку до tangible речей або ідей, які команда зможе бачити. Це допомагає нам швидко ітерувати продукт і швидко доводити його до кращого стану.

Peter Yang: Усе про ітерацію, усе про ітерацію. Я зараз теж трохи лінивий: я завжди прошу AI зробити першу версію, а потім я реагую.

Jenny:

Так. Тому якщо ти справді хочеш, щоб я з нуля зібрала ці інсайти в певний пріоритетний порядок функцій, то часу на це піде набагато більше, ніж раніше.

Я так і роблю. Наприклад, візьми цей подкаст, нотатки, які ти мені скинула: у мене є особиста папка з нотатками, де є матеріали з 1:1 зустрічей, випадкові думки тощо. І я просто кажу: “Прочитай мої особисті нотатки, допоможи придумати ключові тези для виступу цього подкасту й допоможи мені продумати, що саме я хочу тут сказати”. Я, звісно, не буду читати слово в слово. Але це реально допомагає мені розкрити думки, допомагає еволюціонувати моє мислення, а не застрягати десь.

Навички та персональна база знань

Peter Yang: Які навички (skills) ти використовуєш? Або чи є в тебе персональні skills, які призначені спеціально для тебе, щоб робити ці документи та слайди?

Jenny:

У нас всередині є кілька skill-ів, спеціально для документів і презентацій, тому що вони допомагають нам зберігати узгодженість бренду. Насправді в мене немає власної персональної бази skill-ів: у більшості випадків я беру внутрішні готові skill-и й використовую їх для різних задач.

Peter Yang: Наприклад, в мене є writing skill, який каже AI не використовувати той AI slop-словник.

Jenny:

Але насправді я помітила, що зараз, коли я використовую папки Cowork — в мене туди складаються всі мої особисті нотатки тощо — він уже знає, як я мислю, завдяки цим папкам. І для мене це вже дуже корисно. Натомість я відчуваю, що мені все менше потрібні memory та skills, бо в нього вже є база знань про мене. Звісно, я думаю, що skills мають свій релевантний сценарій застосування, але за моїм поточним use case мені особисто здається, що потреба в цьому не така вже й велика.

Peter Yang: Це тому, що він щодня автоматично оновлює пам’ять за твоїми розмовами?

Jenny:

Так. Він по суті — це memory, яке підтримую я сама, бо я постійно роблю там нотатки.

Точки залучення команди

Peter Yang: Тож у всьому цьому процесі — коли саме ти підключаєш команду? Тобто ти ітеруєш разом з AI, а потім назад із командою, туди-сюди? Чи як це відбувається?

Jenny:

Маю на увазі, що такі речі, як справжні UXR-інтерв’ю, — це я сама не роблю. Це або робить product manager, або дослідник у команді, або хтось інший у команді. А потім, через це, ти одразу можеш поділитися artifact, залучити їх — і це насправді стає основою для роботи команди.

Наша команда, принаймні, досить bottom-up і дуже демократична. Тож наш спосіб роботи такий: ми даємо всім інсайти та цілі, а далі кожен робить прототипи, пробує речі, а ідеї надходять звідусіль. Це не так, що як дизайнер я маю придумати всі варіанти. Це швидше: “Гей, ось тут є інсайти. Ось яка ціль на цей місяць, до чого ми всі маємо дійти. Як ми разом цього досягнемо?”

Я думаю, що й з цим ми все одно не віддаємо “усе” Claude. Ми все ще покладаємося на себе, щоб приймати багато рішень, і ми керуємо та визначаємо, що саме варто будувати й робити.

Peter Yang: Коли люди в інтернеті обговорюють смак і здатність оцінювати, я думаю, що методи формування цих навичок полягають у тому, що ти постійно отримуєш багато фідбеку на продукт і зсередини, і ззовні. У цьому процесі ти поступово формуєш інтуїцію — здатність помічати, де щось іде не так і що треба виправити. Бо ти щодня слухаєш і обробляєш фідбек, і з часом у тебе з’являється дуже точне відчуття того, як визначати проблему.

Jenny:

Щодо дизайну: одна з функцій Claude — він може генерувати схожі на wireframe ескізи та давати різні варіанти дизайну. Як дизайнер, мені дуже подобається цей підхід. Навіть якщо деталізація в цих ескізах не така висока, вони дають мені змогу наочно побачити різні можливості, не покладаючись повністю на власну уяву. Цей спосіб допомагає мені швидше вирішувати, куди рухатися далі в дизайні.

Тому я думаю, що якщо Claude напряму генерує ці попередні варіанти, це економить мій час і зусилля на ручне створення ескізів. Із цих варіантів я обираю напрям, починаю ітерувати в невеликому масштабі. Далі я можу використати код, щоб зробити з цього напряму початковий прототип, а на основі цього продовжувати оптимізувати й доводити дизайн.

Реальна історія народження Cowork

Peter Yang: Давай поговоримо про те, як народився Cowork. Зовні є багато історій про те, що “його зробили за 10 днів”. Але насправді перед цим, мабуть, вже було багато ітерацій, так?

Jenny:

Фраза “вони зробили це за 10 днів” — насправді вирізана з якоїсь інтерв’ю чи медійної публікації, і саме навколо цього люди постійно й сперечалися. Але реальна ситуація така: у напрямку Cowork ми фактично почали думати ще коли я приєдналася до Anthropic рік тому. Ми весь час міркували, як створити “мисленнєвого партнера” (thinking partner), який допоможе всім працівникам загального профілю з когнітивної роботи. Хоча Claude Code вже дуже добре справляється з задачами, пов’язаними з кодом, наша мета — охопити всі сценарії роботи з знаннями. Я думаю, справжній виклик полягав у тому: як нам реалізувати цю ідею? Яка архітектура найкраще підходить? Який UX (UX) буде правильним?

За останній рік ми пробували багато різних прототипів, і деякі ідеї навіть були більш масштабними, ніж теперішня ціль. Ми також провели багато технічних експериментів, тестуючи різні фреймворки для AI-агентів, але деякі спроби не спрацювали. Зрештою, ми поступово визначили напрямок, який є зараз. Ми брали до уваги прототипи, які розробляла команда в лабораторії, а також вивчали прототипи, які створювала наша продуктова команда. І врешті-решт вирішальними стали час і спроможність виконати все — ніби блискавка влучила точно в ціль.

Коли ми вирішили випустити цей продукт, весь процес був дуже швидким: від “ми маємо випустити” до “продукт вже вийшов у продакшн” — зайняло лише 10 днів. Це в основному тому, що під час відпустки/канікул Claude Code ми побачили в ньому потенціал. У канікули багатьом людям нарешті вистачило часу спробувати Claude Code, і навіть деякі не-технічні користувачі почали ним користуватися: наприклад, аналізувати транскрипти подкастів або робити складний аналіз даних тощо. Ми виявили, що AI-агентний framework 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. Ми пробували таким способом вести користувача до більш конкретної цілі: наприклад, аналітика або генерація документа. Ми також спроєктували функціональний прототип: коли користувач натискає, він бачить різні опції; в кожній опції є кнопки, щоб налаштовувати, наприклад, довжину документу, або вибрати тип документа — блокнот чи презентація. Але цей дизайн в кінцевому підсумку робив враження, що це надто складно й надто тисне на користувача.

Тому в процесі кількох раундів дослідження та спроб ми постійно шукали точку балансу: ми маємо більш чітко визначити сценарії використання, чи зберегти свободу формату, як у chat box.

І версія, яку ми опублікували кілька тижнів тому, тепер і виглядає саме так. Ми пробували UX майже “як wizard”-режим: користувач натискає, а далі бачить підказки на кшталт “створіть документ, довжиною три-п’ять сторінок” тощо.

Тоді ми додали в інтерфейс багато елементів, сподіваючись, що він виглядатиме інакше, ніж звичайний chat box. Але потім виявилося, що цей дизайн робить інтерфейс надто складним: елементи візуально конкурують між собою надто агресивно. Тож ми вирішили спростити дизайн і прибрали більшість непотрібних елементів.

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

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

Jenny:

Можливо, у майбутньому це стане таким. Але я хочу підкреслити, що дизайн UI приблизно чотири-п’ять тижнів тому був зовсім інший. Ми весь час вчимося, досліджуємо, який дизайн працює найкраще, який дизайн працює не дуже, і паралельно шукаємо найкращий спосіб показати цю технологію користувачам.

Відмінності в позиціонуванні: Cowork і Claude Code

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

Але для новачка це не дуже дружній підхід. Це більше схоже на гру: з часом, коли ти ним користуєшся, ти поступово стаєш більш знайомим і починаєш його добре розуміти. Я відчуваю, що Cowork, можливо, намагається дослідити проміжну зону між звичайним чат-інструментом і Claude Code. Він не приховує всі функції, але водночас якимось чином підказує користувачу, як краще ними користуватися.

Jenny:

Так. У Cowork все ще підтримуються slash commands, але це не основний спосіб взаємодії. Я особисто вважаю, що Cowork — це, принаймні, інструмент для професіоналів. Ми помітили, що багато користувачів уже використовують його у дуже “просунутому” режимі, і в спільноті вже з’явилися певні просунуті користувачі. Ці люди зазвичай готові витратити час на навчання більш складних функцій: наприклад, самостійно створювати skills, ділитися ними з командою або використовувати скорочені команди (shorthand commands).

Але наша ціль — зробити ці функції не основним шляхом взаємодії, а вторинним. Тобто навіть якщо користувач не знає всіх команд, він все одно може легко використовувати Cowork. Ми хочемо, щоб взаємодія користувача з Claude була природною та інтуїтивною, а не вимагала запам’ятовування цілого набору команд.

Планування процесу та бачення

Peter Yang: Як виглядає планування в Anthropic? Ви робите щорічне планування та постановку цілей? Чи більше покладаєтеся на прототипування та постійні спроби?

Jenny:

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

Peter Yang: Тобто гнучко, так? Цікаво, що я бачу: найінноваційніші компанії часто роблять менше річного планування, а більше — через нескінченну ітерацію та навчання на основі того, що від користувачів. Чи робив ти в кар’єрі щось подібне до North Star deck? Ти вважаєш це корисним?

Jenny:

Так, я справді робила. Торік я зробила North Star deck. Я думаю, що бачення має цінність: воно задає напрямок команді та допомагає нам зберігати ясність у тому, що ми будемо робити найближчим часом. Але оскільки технологічна сфера, в якій ми працюємо, змінюється надзвичайно швидко: з’являються нові моделі, і швидкість оновлень теж зростає, формувати бачення на рік для нас не дуже реалістично. Не кажучи вже про бачення на два-п’ять років, бо є занадто багато невідомого.

Втім, справжня роль бачення — вести всіх в одному напрямку, особливо в середовищі, де кожен може вільно будувати різні проєкти. Тому я зараз думаю, що часовий горизонт бачення — максимум від трьох до шести місяців, і його можна подавати у вигляді документа. Я думаю, що коли бачення можна візуалізувати, воно має більший вплив. І це величезна цінність дизайну: об’єднати різні елементи й розповісти цілісну історію в межах конкретного періоду часу. Звісно, бачення може бути і прототипом, а не лише статичним deck. Воно може допомогти координувати роботу між командами, особливо коли в нас є п’ять команд, які працюють над дуже схожими або потенційно конфліктними проєктами. Дизайн може через кураторство допомагати узгоджувати ці ідеї та показувати шлях до ідеального user experience, а не розсипаний набір різних вражень.

Peter Yang: Тоді у вас є оцінка від product manager або рев’ю для відповідних людей? Це формально, чи вони також беруть участь у прототипуванні?

Jenny:

Рев’ю в нас є, але не так, як раніше в деяких компаніях: коли кожна функція потребує рев’ю. Наші рев’ю в основному для більших і більш пріоритетних проєктів. Мета рев’ю — не витрачати багато часу на підготовку, а підвищити видимість проєкту й отримати фідбек. Якщо є важливі проєкти, що перетинають команди й впливають на компанію, тоді ми проводимо такі рев’ю.

Порада дизайнерам: як знайти місце в епоху AI

Peter Yang: Тоді що б ти порадила дизайнерам, які відчувають, що їхнє професійне середовище стрімко змінюється? Чи їм варто почати вчитися подавати код (PR)? Чи дизайнери мають адаптуватися інакше?

Jenny:

Якщо ти відчуваєш, що під ногами рухається земля — це тому, що вона справді змінюється. Нам треба це визнати, навчитися адаптуватися, і водночас з відкритим розумом заново подивитися на те, як ми працювали раніше. Я думаю, що ці зміни особливо сильно впливають на дизайнерів зараз, тому що ми зараз у другій хвилі цього тренду. Інші професійні ролі вже переживали схожі трансформації, а тепер прийшла черга для нас. Паралельно наші інструменти дизайну також еволюціонують.

Кожного разу, коли я відчуваю, що моє професійне життя під викликом, у мене виникає легка тривога. Наприклад: “Боже, моя робота дуже сильно змінюється, і, можливо, люди більше не цінуватимуть мою роботу так, як раніше”. Але в такі моменти я думаю про моїх колег-інженерів. Їхня робота вже давно пройшла через величезні зміни, але вони не лише адаптувалися до них — вони ще й з великою відвагою та скромністю зустрічали виклики, а згодом досягали більш ефективних і якісніших результатів. Вони — моє джерело натхнення: я кажу собі, що якщо ці мої колеги, яких я дуже поважаю, змогли зробити це, то я теж обов’язково зможу. Вони — мій приклад того, як адаптуватися до змін.

Peter Yang: Якщо дивитися з певної перспективи, ці зміни відбирають у дизайнерів купу нудної повторюваної роботи — наприклад, не треба більше витрачати час на підгонку різних рамок, так? Тоді ти зможеш більше зосередитися на мисленні вищого рівня та творчій роботі.

Jenny:

Так. Або, скажімо, ці зміни дозволяють нам робити більше. Наприклад, коли я бачу, що мої інженерні колеги зараз можуть завершити повноцінну функцію всього за кілька днів, тоді як раніше це могло зайняти тижні, мені справді дуже вражаюче. Тож так — ці зміни також приносять більше можливостей.