“Lixo entra, joia sai”: O principal designer da Anthropic fala sobre a filosofia do produto do Cowork e a verdade por trás do lançamento em 10 dias

Organizar & Compilar: Deep潮TechFlow

Convidada: Jenny Wen, responsável pelo design na Cowork

Apresentador: Peter Yang

Fonte do podcast: Peter Yang

Título original: Claude Cowork Tutorial from Cowork s Design Lead (40 Min) | Jenny Wen

Data de emissão: 29 de março de 2026

Resumo dos pontos-chave

A Jenny é a responsável pelo design na Cowork. Ela levou-me a perceber a fundo o funcionamento interno da Anthropic, incluindo como usa o design e o desenvolvimento na Cowork para construir produtos e a história real por trás do surgimento da Cowork. A Anthropic lança novas funcionalidades quase todos os dias, e ver o modo como trabalham deixou-me verdadeiramente impressionado.

Resumo de ideias em destaque

Sobre a forma de trabalhar no dia a dia

A maior parte das coisas que passo tempo a fazer é levar os produtos para o exterior. Mas acho que isto pode não ser exatamente igual ao que parecia há um ou dois anos. Em grande parte, trata-se de fazer “jam” (colaboração improvisada) com engenheiros, pessoas de produto, etc., de um modo pouco formal. Normalmente, o grupo vê em conjunto um protótipo e, depois, aponta e pensa de que forma é que ele pode evoluir.

Sobre a filosofia de “lixo entra, tesouros saem”

Acho que o que mais me surpreende na Cowork é a sua capacidade de organizar informação. Gosto de lhe chamar “lixo entra, tesouros sai”. Ela consegue recolher informação a partir de várias fontes diferentes, encontrar rapidamente os pontos-chave, extrair conteúdo valioso e transformá-lo em resultados com utilidade prática e produtividade.

Sobre a diferença entre Cowork e Claude Code

Para além de um trabalho de produção muito detalhado (production code), agora quase tudo o que faço é feito com a Cowork. Se for necessário focar em alguns pormenores específicos de código, eu ainda uso o Claude Code. Mas, para a comunicação e colaboração do dia a dia, agora dependo totalmente da Cowork.

Sobre a história do nascimento da Cowork

A frase “eles fizeram em 10 dias” foi, na verdade, recortada a partir de uma entrevista ou de uma reportagem da imprensa. Mas o facto é que, em relação à direção Cowork, nós começámos a pensar nisso desde quando eu entrei na Anthropic, há um ano. Estivemos sempre a considerar como construir um “parceiro de pensamento” (thinking partner) que ajudasse todos os trabalhadores do conhecimento em geral.

Embora o Claude Code já consiga lidar muito bem com tarefas relacionadas com código, o nosso objetivo é abranger cenários de conhecimento em todas as dimensões. E eu acho que o verdadeiro desafio está nisto: como executamos essa ideia? Que tipo de arquitetura é a mais adequada? Que tipo de experiência de utilizador (UX) é a correta?

Sobre a evolução do processo de design

Eu ainda faço Figma. Mas agora não fazemos tão frequentemente documentos de especificação e, normalmente, também não são tão detalhados. Ainda fazemos, sim, ordenação de prioridades — continua a existir como um documento, mas geralmente são apenas alguns bullet points, não aquelas tabelas bonitas de design excessivo.

Sobre planeamento e visão

O nosso setor tecnológico muda extremamente depressa: surgem novos modelos continuamente e a velocidade das atualizações tem vindo a aumentar cada vez mais. Por isso, para nós, estabelecer uma visão para um ano é pouco realista, quanto mais uma visão para dois a cinco anos, porque há demasiado desconhecido.

Sobre o futuro dos designers

Se achas que o chão sob os teus pés está a mexer, é porque de facto está a mudar. Temos de reconhecer isso, aprender a adaptar-nos e, ao mesmo tempo, com uma mentalidade aberta, reavaliar novamente a forma como fazemos o nosso trabalho.

Sempre que sinto que a minha carreira está a ser posta à prova, penso nos meus colegas engenheiros. O trabalho deles já passou por grandes transformações há muito tempo. Mas eles não só se adaptaram a essas mudanças como também enfrentaram os desafios com muita coragem e humildade, acabando por alcançar resultados de trabalho mais eficientes e melhores. Eles são a minha fonte de inspiração — digo-me a mim própria: se esses colegas que eu respeito tanto conseguiram, eu também consigo. São um exemplo de como se adapta à mudança.

Abertura

Peter Yang: Olá a todos. Hoje estou muito entusiasmado por receber a responsável pelo design da Anthropic, Jenny. A Jenny vai mostrar-nos como usa o Claude Cowork e o Claude Code para desenhar e lançar produtos e, ao mesmo tempo, partilhar connosco as histórias internas da Cowork. Talvez também fale sobre os próximos passos do desenvolvimento do seu produto.

Jenny, como é um dia típico do teu trabalho? Que tarefas ocupam a maior parte do teu tempo?

Jenny:

Não sei se existe um dia típico e sequer “o” dia típico. Mas a maior parte do tempo que passo a fazer é levar os produtos para o exterior. Contudo, acho que isto pode não ser exatamente igual ao que parecia há um ou dois anos. Em grande parte, trata-se de fazer “jam” (colaboração improvisada) com engenheiros, pessoas de produto, etc., de um modo pouco formal. Normalmente, vemos todos juntos um protótipo e, depois, apontamos e pensamos de que forma pode evoluir. Por vezes, é só discutir o desempenho de uma funcionalidade; outras vezes, sou eu a implementar algumas coisas. Eu sinto que ainda há uma grande parte do meu tempo a ser eu a desenhar e a fazer protótipos. Mas agora, a forma como se faz trabalho de design parece bem mais solta.

Peter Yang: Basicamente, tu gera vários protótipos com coisas como o Claude e depois fazes jam com engenheiros, dás feedback, e usas prompts para o AI melhorar, certo?

Jenny:

Na verdade, muitas vezes nem são protótipos — são protótipos de trabalho que já estão construídos internamente e a correr em instâncias do Claude ou da Cowork. Eu normalmente gasto tempo a usar essa funcionalidade, a fazer push dessa funcionalidade, a ver a capacidade dela e a formar opiniões. E o passo seguinte de iteração costuma ser eu sentar-me com um engenheiro e dizer: “Ei, eu estou a pensar assim. Estes são os pontos onde acho que devia haver mudanças.” Eu acho mesmo que ainda é muito, muito importante ter tempo para iterar, afinar e refinar dentro das ferramentas de design. Por isso, essa parte não desapareceu. Só que, como estou a lidar com mais projetos ao mesmo tempo, sinto que a forma mais eficiente é fazê-lo de maneira muito casual, muito informal.

Peter Yang: Para mim, como gestor de produto ou designer, essa sempre foi a parte que eu mais gostei: juntar designers e engenheiros, e ver o produto a iterar em conjunto. Então agora vocês não fazem tanto aquele tipo de planeamento com documentos de especificação, ficheiros Figma e coisas desse género? Ou vocês simplesmente iteram protótipos diretamente no código?

Jenny:

Eu continuo a fazer Figma. Mas agora não fazemos tão frequentemente documentos de especificação, e geralmente também não são tão detalhados. Sim. Nós ainda fazemos ordenação de prioridades — e isso continua a existir como documento. Na verdade, isso ajuda muito quando entregamos a segurança ou a equipas jurídicas: eles conseguem compreender o que vai ser publicado, mas normalmente são apenas alguns bullet points. Não é aquelas tabelas bonitas com design excessivo. Acho que os nossos ficheiros Figma são igualmente assim.

Demonstração prática do Cowork

Peter Yang: Podes mostrar-nos como é que usas esses produtos, ou para que é que usas cada um separadamente?

Jenny:

Claro. Vou explicar como é que eu uso a Cowork. Na verdade, tenho um segredo pequeno: para além do trabalho de produção de código (production code) muito detalhado, neste momento quase tudo o que faço é com a Cowork. Se houver cenários em que precise de focar nalguns pormenores do código, eu ainda uso o Claude Code. Mas, para a comunicação e colaboração do dia a dia, agora dependo totalmente da Cowork.

Acho que o que mais me impressiona na Cowork é a sua capacidade de organização de informação. Gosto de lhe chamar “lixo entra, tesouros sai”. Ela consegue recolher informação a partir de várias fontes diferentes, encontrar rapidamente os pontos-chave, extrair conteúdo valioso e transformá-lo em resultados com produtividade prática.

Vou dar um exemplo. Neste momento, conectei uma pasta com alguns registos de entrevistas a utilizadores. A nossa equipa Cowork dá muito valor à ligação estreita com os utilizadores; isso é uma das chaves do nosso sucesso. Fazemos isso através de pesquisa tradicional de experiência do utilizador (UXR), falando diretamente com os utilizadores. Ao mesmo tempo, também usamos formas internas para uso próprio — por exemplo, temos um canal Slack dedicado à recolha de feedback. Além disso, acompanhamos também as discussões nas redes sociais e ouvimos as opiniões de utilizadores muito entusiasmados. E é exatamente por mantermos sempre essa ligação estreita com os utilizadores e conseguirmos iterar o produto rapidamente que conseguimos melhorar continuamente e obter os resultados de hoje.

Portanto, o que eu faço agora é: eu digo ao Claude: “Ei, eu tenho esta pasta com entrevistas.” Mas também peço ao Claude para ver em redes sociais, Reddit e outras avaliações/casOS de clientes da Cowork, e dizer-me quais são as maiores perceções. Pode demorar um pouco, porque ele precisa mesmo de processar tantos dados e transformá-los. Mas ele faz algumas coisas: às vezes gera agentes filhos para trabalhar em paralelo, e também passa tempo a pesquisar na internet.

Peter Yang: No teu trabalho real, vocês têm aquele tipo de relatório semanal com perceções? Ou é algo que agrega automaticamente todo o conteúdo e te envia a ti e à equipa?

Jenny:

Na verdade, nós já conseguimos fazê-lo diretamente com a Cowork. Eu acho que os nossos investigadores têm um ciclo que é publicado; além disso, há uma versão que nos vai “pingando” no Slack. Nós também ouvimos diretamente os canais Slack internos. Nós dependemos muito dos utilizadores mais fortes e internos para nos darem esse feedback mais avançado, porque as pessoas internas estão realmente dispostas a serem honestas consigo — e normalmente empurram as funcionalidades até ao limite e também são as que mais facilmente acompanham.

Peter Yang: Eu acho que isso é exatamente o que deveria acontecer, e sinto que a maioria das empresas tem equipas demasiado separadas entre si. Mas a Anthropic não parece ser assim.

Jenny:

Eu acho que essa é também uma parte importante do sucesso do Claude Code: ouvir utilizadores da linha da frente. E é algo que nós fizemos muito quando estávamos a usar Figma — muito dogfooding interno. Porque, sobretudo quando se trata de design de interações e afinação desses detalhes, as pessoas internas realmente vão mexer nesses pormenores; já os utilizadores externos tendem a dar mais feedback sobre se “é adequado para o fluxo do utilizador deles”, o que fornece um nível de feedback completamente diferente.

Fronteiras de utilizador: Cowork vs Claude Code

Peter Yang: Eu sei que atualmente o marketing e os gestores de produto na Anthropic, basicamente, estão a usar o Claude Code para fazer as coisas, especialmente depois de estar disponível internamente na Cowork. O que é que achas sobre diferentes tipos de cenários de utilização? Ou como é que as pessoas usam Cowork e Claude Code?

Jenny:

Nós notámos que a aplicação geral da Cowork está a expandir-se progressivamente e começou a ser usada em alguns cenários que são parecidos com aqueles em que antes o Claude Code era testado por utilizadores avançados. Lembras-te quando começámos a desenvolver a Cowork? A equipa de vendas interna era a principal fonte de informação. Alguns deles eram utilizadores avançados do Claude Code, usando-o para gerar listas de potenciais clientes, escrever scripts de chamadas, etc. Quando eu vi esses casos de uso pela primeira vez, fiquei muito surpreendida, porque na altura eu nem tinha pensado que o Claude Code pudesse ser usado para completar essas tarefas. Mas agora, esses utilizadores quase já mudaram totalmente para a Cowork, e até os colegas deles começaram a usar a Cowork com muita frequência.

E é porque agora há uma UI bonita. Acho que é isto que realmente precisa. E há ainda outra parte do motivo: está muito próxima do que eles já estavam a fazer. Eles já estavam a usar a funcionalidade de chat, e a partir dessa aplicação de desktop conseguem continuar a usar o Claude Code, por isso sinto que se encaixa melhor no fluxo de trabalho deles do que abrir a linha de comandos.

Do insight até ao artefacto executável: o processo completo

Jenny:

Há sete temas diferentes aqui e, todas as semanas, muda. Eu basicamente consigo dizer-lhe diretamente: “Ajuda-me a criar este documento X”, e ele já existe automaticamente numa pasta no meu computador. Eu também posso iniciar dois trabalhos em paralelo. Por exemplo: “Estas perceções são ótimas, mas com base nelas, que funcionalidades de produto eu devo realmente construir?” E depois posso fazer, em paralelo, outra coisa: transformar esses conteúdos da pasta de perceções que ele acabou de me ajudar a fazer numa apresentação que eu possa partilhar com a equipa no kickoff desta semana.

Mas, no fim, é daqui que eu começo a desenhar o processo: ele vai dar-me várias opções de funcionalidade. A partir daí, eu até consigo fazer com que o Claude me ajude a criar alguns wireframes para essas funcionalidades. Ele pode dar-me um monte de opções diferentes, que eu posso levar para o Figma para refinar mesmo, ou levar para o Claude Code e, com os componentes reais do nosso sistema de design, transformá-las em coisas reais. E então seguir a partir daí.

Além disso, eu também posso transformar estes dois trabalhos em tarefas agendadas. Em geral, eu faço com que ele agende esta tarefa para executar automaticamente todas as segundas-feiras às 10 da manhã. Assim, toda segunda-feira às 10 eu começo o trabalho já com esta apresentação e com três ou quatro ideias diferentes de produto para arrancar a semana. Ele comprime muito bem o ciclo de iteração — desde o feedback até fazer coisas tangíveis ou ideias que a equipa consiga ver — ajudando-nos a iterar rapidamente o produto e a melhorá-lo também rapidamente.

Peter Yang: Tudo é sobre iterar, tudo é sobre iterar. Neste momento eu até estou a ficar mais preguiçoso; eu deixo sempre o AI fazer a primeira versão e depois é que eu respondo.

Jenny:

Sim. Portanto, se realmente quiseres que eu organize estas perceções desde zero e as transforme numa priorização de funcionalidades, ele vai demorar bem mais tempo do que antes.

Eu faço exatamente assim. Por exemplo, estas notas do podcast que me enviaste: eu tenho uma pasta de notas pessoal com conteúdo de reuniões 1:1, ideias aleatórias e assim. E eu digo diretamente: “Lê as minhas notas pessoais; ajuda-me a pensar nos pontos de fala deste podcast e ajuda-me a pensar no que eu quero dizer aqui.” Obviamente que eu não vou lê-las palavra por palavra, mas isso abre mesmo a minha cabeça e ajuda-me a evoluir o meu pensamento, em vez de ficar preso nele.

Skills e base de conhecimento pessoal

Peter Yang: Que skills usas? Ou tens alguma skill dedicada só para ti para fazer esses documentos e apresentações?

Jenny:

Nós temos internamente algumas skills dedicadas a fazer documentos e apresentações, porque isso ajuda-nos a manter consistência de marca. Eu, na verdade, não tenho uma coleção pessoal de skills. Na maior parte do tempo, eu reutilizo skills que já existem internamente e aplico-as em diferentes propósitos.

Peter Yang: Por exemplo, eu tenho uma writing skill, e ela diz ao AI para não usar aquelas expressões inúteis do AI.

Jenny:

Mas, na verdade, eu descobri que, ao usar as pastas do Cowork — eu tenho lá todas as minhas notas pessoais e assim — elas aprendem sobre mim através dessas pastas, e para mim isto já é muito útil. Pelo contrário, sinto cada vez menos necessidade de memory e de skills, porque já existe uma base de conhecimento sobre mim. Claro que eu ainda acho que as skills têm os seus casos de utilização. Mas, para o meu uso atual, sinto que a necessidade não é tão grande.

Peter Yang: É porque ele atualiza a memória automaticamente todos os dias com base nas tuas conversas?

Jenny:

Sim. No essencial, é uma memory que eu própria mantenho, porque eu escrevo notas lá dentro.

Nodos de colaboração da equipa

Peter Yang: Então, em que momento do processo é que tu trazes a equipa? Ou quer dizer, tu iteras com o AI e depois alternas de volta com a equipa para iterar, ou como funciona?

Jenny:

O que eu quero dizer é que, em coisas como entrevistas UXR reais, eu não faço isso sozinha — ou é o gestor de produto, ou são investigadores da equipa, ou outras pessoas da equipa que fazem. Depois, com isso, tu partilhas diretamente o artefacto e puxas essas pessoas para o processo; na prática, isso acaba por se tornar a base de como a equipa funciona.

Pelo menos, a nossa equipa é bastante bottom-up e democrática. A nossa forma de operar é que nós damos às pessoas as perceções e os objetivos, e cada pessoa cria protótipos, tenta coisas. As ideias vêm de todos os lados. Não é “sou eu, como designer, que tenho de pensar em todas as soluções”. É mais “ei, aqui estão as perceções. Este é o objetivo que queremos alcançar este mês. Como é que todos juntos chegamos lá?”

Com isso, nós ainda não entregamos tudo diretamente ao Claude para fazer. Nós continuamos a depender das nossas próprias decisões, e da nossa capacidade de gerir e decidir o que realmente deve ser construído e o que fazer.

Peter Yang: Quando as pessoas falam, online, sobre gosto e capacidade de julgamento, eu sinto que a forma de desenvolver essas capacidades é, na prática, através de recolher continuamente muito feedback de produto, tanto de dentro como de fora. Nesse processo, vais gradualmente formando uma intuição para detetar onde algo está a falhar e precisa de ser corrigido. Como tu ouves e processas feedback todos os dias, ao fim de muito tempo tu crias uma capacidade de julgamento muito aguçada para problemas.

Jenny:

Quanto ao design, uma das funcionalidades do Claude é gerar esboços tipo wireframe e fornecer múltiplas opções de design. Como designer, eu adoro esse modo. Mesmo que a precisão desses esboços não seja muito alta, eles permitem-me ver de forma intuitiva diferentes possibilidades sem ter de depender totalmente da minha imaginação. Esse método ajuda-me a decidir mais rapidamente a direção do próximo design.

Por isso, eu acho que deixar o Claude gerar diretamente essas opções iniciais poupa o meu tempo e energia de fazer esboços manualmente. Entre essas opções, eu escolho uma direção e começo a iterar numa escala menor. Em seguida, talvez eu use código para construir, a partir dessa direção, um protótipo inicial e, com base nisso, continuar a otimizar e a refinar o design.

História real do surgimento da Cowork

Peter Yang: Vamos falar sobre como a Cowork nasceu. Lá fora há muitas histórias sobre ela ter sido feita em 10 dias, mas na verdade já deve haver muitas iterações antes disso, certo?

Jenny:

A frase “eles fizeram em 10 dias” foi, na verdade, recortada de uma entrevista ou de uma reportagem da imprensa. As pessoas continuam a discutir em torno desse ponto. Mas a realidade é que, sobre a direção Cowork, nós já começámos a pensar nisso desde que eu entrei na Anthropic, há um ano. Nós sempre estivemos a pensar como construir um “parceiro de pensamento” (thinking partner) que ajudasse todos os trabalhadores do conhecimento em geral. Embora o Claude Code já conseguisse lidar bem com tarefas relacionadas com código, o nosso objetivo era abranger cenários de trabalho de conhecimento em todas as dimensões. Eu acho que o verdadeiro desafio era isto: como executar essa ideia? Que tipo de arquitetura é a mais adequada? Que tipo de experiência de utilizador (UX) é a correta?

No último ano, testámos muitos protótipos diferentes. Algumas das ideias eram até mais ambiciosas do que o objetivo atual. Também fizemos muitos testes técnicos, explorando várias estruturas de agentes de AI, mas algumas tentativas não tiveram sucesso. No final, só fomos encontrando gradualmente a direção certa. Não nos limitámos a usar protótipos desenvolvidos pela equipa de laboratório; também analisámos protótipos que a nossa equipa de produto construiu. E, no fim, o timing e a capacidade de execução tornaram-se a chave, como um raio que acerta exatamente no alvo.

Quando decidimos lançar este produto, todo o processo foi muito rápido — de “devíamos lançar” até “o produto já está no ar” — em apenas 10 dias. Isto aconteceu principalmente porque vimos o potencial do Claude Code durante as férias. Durante essas férias, muita gente finalmente teve tempo para experimentar o Claude Code. Até utilizadores não técnicos começaram a usá-lo: por exemplo, para analisar transcrições de podcasts ou para fazer análises complexas de dados. Descobrimos que as estruturas de agentes do Claude Code também começaram a mostrar um encaixe inicial entre produto e mercado junto de utilizadores não técnicos. Na verdade, nessa altura já tínhamos um protótipo que funcionava internamente, e o lançamento estava previsto para mais tarde. Mas esses feedbacks fizeram-nos perceber que “agora é mesmo o melhor momento”. Então decidimos aproveitar essa oportunidade. E foi assim que chegámos a esses 10 dias malucos.

Peter Yang: Se eu não estiver a interpretar mal, ao longo do ano passado vocês partilharam muitos protótipos no Slack interno, recolheram bastante feedback e, no fim, determinaram um protótipo viável. E depois, ao verem a procura do mercado, vocês fizeram um sprint rápido e lançaram o produto.

Jenny:

Sim, mais ou menos é isso. Nós tínhamos planeado lançar dentro de algumas semanas, mas na altura sentimos “agora é mesmo o melhor momento”. E isso também levou-nos, perante a pressão de tempo, a reduzir o âmbito do produto para algo mais realista e executável, investindo todo o esforço e recursos. No fim, conseguimos lançar com sucesso.

Iteração de design inicial: de ferramenta de workflow para Chat minimalista

Peter Yang: Podes partilhar algumas experiências sobre as iterações iniciais, ou mostrar algo que esteja ainda em desenvolvimento?

Jenny:

Claro. Eu organizei, de propósito, alguns screenshots de fases iniciais para mostrar a nossa linha de pensamento e o processo de iteração.

No início deste ano, tivemos um protótipo inicial feito em colaboração entre mim e outro designer. Naquela altura, tentámos orientar a ferramenta para ser mais “task-oriented” (orientada a tarefas) ou “workflow-oriented” (orientada a fluxos de trabalho). Porque tínhamos receio de que os utilizadores não conseguissem entender como usar um produto como o Cowork para cumprir tarefas específicas ou alcançar resultados claros (outcome). Por exemplo, criar um dashboard ou integrar dados vindos de diferentes fontes. Por isso, desenhámos a interface do utilizador de forma muito estruturada — quase como uma ferramenta de workflow. Por exemplo: “adiciona estes conteúdos; isto são inputs (entradas); isto são outputs (saídas)”. E a funcionalidade de chat foi colocada como secundária.

Mas parecia que era preciso fazer muitos passos para concluir. E no contexto de 2025, porque é que ainda temos de fazer algo tão complexo? Não era mais simples deixar o Claude tratar disso?

Essa foi uma das direções iniciais. Mas depois decidimos mudar a abordagem para ficar mais simples, como uma caixa de chat (chat box). Tentámos orientar o utilizador a alcançar objetivos mais específicos através desse formato, como análise ou geração de documentos. Também desenhámos um protótipo funcional: quando o utilizador clica, consegue ver várias opções, e cada opção tem botões para ajustar, por exemplo, o tamanho/comprimento do documento, ou escolher o tipo de documento, como memorando ou apresentação. Mas, no fim, esse desenho fez o utilizador sentir que estava demasiado complexo e até opressivo.

Por isso, após várias explorações e tentativas, estivemos sempre a tentar encontrar um equilíbrio: definimos claramente os cenários de utilização ou mantemos uma forma mais livre, como a do chat box?

A versão que lançámos há algumas semanas é já o aspeto atual. Antes, tentámos uma experiência quase “wizard-like” (tipo assistente), em que o utilizador clica e aparece um aviso, por exemplo: “cria um documento, com três a cinco páginas”, etc.

Naquela altura, também colocámos muitos elementos dentro da interface para tentar que parecesse diferente de um chat box normal. Mas depois descobrimos que esse design tornava a interface demasiado complexa e que a competição entre elementos visuais era demasiado intensa. Por isso, decidimos simplificar o design e remover a maior parte dos elementos desnecessários.

Agora, a interface do utilizador que vês está muito mais simplificada. Removemos as sidebars pesadas para ficar mais próxima de um chat box tradicional. Mas fizemos algumas alterações na página inicial para que pareça mais uma “lista de tarefas” (to-do list) partilhada entre mim e o Claude — em vez de ser uma ferramenta de chat cheia de sugestões e orientações complexas.

Peter Yang: Talvez no futuro possa suportar vários agentes (agent), e dar para arrastar tarefas para gerir o workflow.

Jenny:

Talvez no futuro seja possível. Mas quero salientar que o UI design era totalmente diferente há cerca de quatro ou cinco semanas. Nós estamos sempre a aprender, a explorar que tipo de design funciona melhor, que tipo de design não resulta, e ao mesmo tempo a esforçar-nos para encontrar a melhor forma de apresentar esta tecnologia ao utilizador.

Diferenciação entre Cowork e Claude Code

Peter Yang: Quando eu uso o Claude Code, eu costumo partilhar alguns feedbacks no Twitter. Ele tem muitos comandos de barra (slash commands) embutidos, e isso obriga o utilizador a aprender pouco a pouco. A experiência é um pouco como quando vais ao Costco fazer “caça ao tesouro” (treasure hunt): nunca sabes que funcionalidade nova vais descobrir.

Mas para iniciantes, isso não é muito amigável. É mais como um jogo: conforme usas ao longo do tempo, vais ficando mais familiarizado e a dominá-lo. Eu sinto que a Cowork está a tentar explorar o meio-termo entre uma ferramenta de chat normal e o Claude Code. Ela não esconde todas as funcionalidades — ao mesmo tempo, consegue guiar os utilizadores de alguma forma para usarem melhor.

Jenny:

Sim. A Cowork ainda suporta o uso de slash commands, mas eles não são o modo principal de interação. Na minha opinião pessoal, pelo menos a Cowork é uma ferramenta voltada para profissionais. Nós observámos que muitos utilizadores já a usam como utilizadores de nível avançado, e que já surgiram alguns utilizadores avançados na comunidade. Esses utilizadores normalmente estão dispostos a passar tempo a aprender funcionalidades mais complexas, como criar skills (skills) por conta própria, partilhar com a equipa ou usar comandos abreviados (shorthand commands).

Mas o nosso objetivo é fazer com que essas funcionalidades sejam uma forma secundária de interação, e não algo que o utilizador tenha de aprender de forma obrigatória. Ou seja, mesmo que os utilizadores não conheçam todos os comandos, conseguem usar a Cowork de forma fácil. Queremos que a interação do utilizador com o Claude seja natural e intuitiva, e não algo que exija que a pessoa memorize uma lista de comandos para conseguir fazer o que precisa.

Planeamento do processo e visão

Peter Yang: Como é o processo de planeamento da Anthropic? Vocês fazem planeamento anual e definição de objetivos? Ou dependem mais do desenvolvimento de protótipos e de ir tentando continuamente?

Jenny:

O nosso método de planeamento varia de cada vez. Na equipa onde eu estou, fazemos planeamento mensal. Temos uma folha de cálculo e, pelo menos na parte da Cowork, listamos cerca de 12 tarefas como máximo. Essas são as nossas prioridades mais altas (P0). Cada tarefa tem um responsável direto (DRI). Todas as semanas fazemos uma verificação: estamos ainda no caminho certo? Também fazemos planeamentos trimestrais ou semestrais, normalmente apontados por alguém: “Eu acho que devíamos seguir nesta direção; estes são os pontos que precisamos de focar.” Mas esses planeamentos não são tão rígidos a ponto de obrigarem a executar projetos específicos. É mais para dar à equipa um rumo global, e portanto é relativamente flexível.

Peter Yang: Relativamente flexível, certo? O curioso é que vejo que as empresas mais inovadoras tendem a fazer menos planeamento anual, e mais a iterar constantemente e a aprender com os utilizadores. Na tua carreira, fizeste coisas semelhantes a um North Star deck? Achas que isso é útil?

Jenny:

Eu realmente fiz. No ano passado fiz um North Star deck. Eu acho que a visão tem valor: ela indica a direção da equipa e ajuda-nos a manter a clareza no trabalho que está para vir. Mas, como o nosso domínio tecnológico muda extremamente depressa, com novos modelos a surgir continuamente e a velocidade de atualização a acelerar, para nós não é tão realista estabelecer uma visão anual, muito menos uma visão de dois a cinco anos, porque há demasiados fatores desconhecidos.

No entanto, o verdadeiro valor da visão é orientar as pessoas para seguirem na mesma direção, especialmente num ambiente em que cada um pode construir livremente vários projetos. Por isso, atualmente eu penso que a visão deve ter, no máximo, uma abrangência de três a seis meses, e pode ser apresentada na forma de documento. Eu acho que quando a visão é visualizada, tem mais impacto. E esse é um enorme valor do design: conseguir integrar vários elementos e contar uma história coerente dentro de um período de tempo específico. Claro que a visão pode também ser um protótipo, e não apenas um deck estático. Pode ajudar-nos a alinhar o trabalho entre equipas, sobretudo quando temos cinco equipas a tratar de projetos muito semelhantes ou potencialmente em conflito. O design pode ajudar a chegar a um consenso sobre estas ideias através de curadoria, e mostrar um caminho para a experiência de utilizador ideal — em vez de dispersar as experiências.

Peter Yang: Então vocês fazem revisões com gestor de produto, ou revisões direcionadas a pessoas relevantes? Essas revisões são formais, ou eles também participam no desenho de protótipos?

Jenny:

Sim, nós fazemos revisões. Mas não são como eu via em algumas empresas no passado, em que cada funcionalidade precisava passar por revisão. As nossas revisões são principalmente para projetos maiores e com maior prioridade. O objetivo das revisões não é desperdiçar muito tempo a preparar — é aumentar a visibilidade dos projetos e obter feedback. Se houver projetos importantes que cruzem equipas e que afetem a empresa, nós fazemos essas revisões.

Conselhos para designers: como encontrar o teu lugar na era da AI

Peter Yang: Então, para aqueles designers que sentem que o ambiente profissional deles está a mudar rapidamente, que conselhos tens? Eles deveriam começar a aprender a submeter código (PR)? Ou os designers deveriam adaptar-se de outras formas?

Jenny:

Se achas que o chão sob os teus pés está a mexer, é porque de facto está a mudar. Temos de reconhecer isso e aprender a adaptar-nos. Ao mesmo tempo, precisamos de uma mentalidade aberta para voltar a olhar para a forma como trabalhamos hoje. Eu sinto que a mudança atual afeta especialmente os designers, sobretudo porque estamos na segunda vaga desta onda. Outras funções já passaram por transformações semelhantes; e agora é a nossa vez. Ao mesmo tempo, as nossas ferramentas de design também estão a evoluir continuamente.

Sempre que eu sinto que a minha carreira está a ser posta à prova, fico com um leve desconforto, tipo: “Meu Deus, o meu trabalho está a sofrer uma grande mudança. As pessoas podem deixar de valorizar o meu trabalho como antes.” Nesses momentos, penso nos meus colegas engenheiros. O trabalho deles já passou por grandes transformações há muito tempo. Mas eles não só se adaptaram a essas mudanças como também enfrentaram os desafios com muita coragem e humildade, e no fim conseguiram resultados mais eficientes e melhores. Eles são a minha fonte de inspiração — digo-me: se esses colegas que eu respeito tanto conseguem, eu também consigo. Eles são um exemplo de como se adapta à mudança.

Peter Yang: De certa forma, essas mudanças tiram aos designers muitas tarefas repetitivas e aborrecidas, como não precisar mais de gastar tempo a ajustar todo o tipo de caixas, certo? Assim consegues dedicar mais energia a pensamento de nível superior e trabalho criativo.

Jenny:

Sim, ou melhor, essas mudanças permitem-nos fazer mais coisas. Por exemplo, quando vejo os meus colegas engenheiros a conseguirem completar uma funcionalidade completa em poucos dias — e antes isso poderia levar algumas semanas — eu fico verdadeiramente impressionada. Por isso, sim: a mudança também traz mais possibilidades.