“Basura entra, tesoro sale”: El diseñador principal de Anthropic habla de la filosofía del producto de Cowork y la verdad detrás de su lanzamiento en 10 días

Organización y compilación: Deep潮TechFlow

Invitada: Jenny Wen, responsable de diseño de Cowork

Presentador: Peter Yang

Fuente del podcast: Peter Yang

Título original: Tutorial de Claude Cowork del líder de diseño de Cowork (40 min) | Jenny Wen

Fecha de emisión: 29 de marzo de 2026

Resumen de puntos clave

Jenny es la responsable de diseño de Cowork. Ella me llevó a conocer en profundidad el funcionamiento interno de Anthropic, incluyendo cómo usa Cowork para diseñar y desarrollar productos, y la historia real detrás del surgimiento de Cowork. Anthropic lanza nuevas funciones casi a diario, y ver su forma de trabajar me dejó muy impactado.

Resumen de ideas destacadas

Sobre la forma de trabajar diaria

La mayor parte de las cosas que dedico a hacer es sacar el producto adelante. Pero creo que quizá no se ve exactamente igual que hace uno o dos años. En gran parte consiste, en realidad, en colaborar en tiempo real (jam), de una manera bastante informal, junto con ingenieros, gente de producto, etc. Normalmente, todos miran un prototipo, señalan y piensan cómo podría evolucionar.

Sobre la filosofía del “basura entra, tesoros salen”

Creo que lo que más me sorprende de Cowork es su capacidad para organizar información. Me gusta llamarlo “basura entra, tesoros salen”. Puede recopilar información de una variedad de fuentes, encontrar rápidamente los puntos clave, extraer contenido valioso y convertirlo en resultados con productividad real.

Sobre las diferencias entre Cowork y Claude Code

Además del trabajo de código de producción (production code) muy meticuloso, ahora casi todo lo que hago lo hago con Cowork. Si se trata de un escenario en el que necesito concentrarme en ciertos detalles del código, todavía usaría Claude Code. Pero para la comunicación y la colaboración cotidianas, ahora dependo por completo de Cowork.

Sobre la historia de nacimiento de Cowork

La frase de “ellos lo hicieron en 10 días” en realidad se recorta de alguna entrevista o cobertura mediática. Pero la situación real es que, con respecto a la dirección de Cowork, en realidad ya llevábamos tiempo dándole forma desde que yo me incorporé a Anthropic hace un año. Siempre nos preguntábamos cómo construir un “compañero de pensamiento” (thinking partner) que pudiera ayudar a todos los trabajadores del conocimiento de propósito general.

Aunque Claude Code ya puede manejar muy bien tareas relacionadas con código, nuestro objetivo era cubrir todo tipo de escenarios de trabajo con conocimiento. Siento que el verdadero desafío era: ¿cómo ejecutamos esta idea? ¿Qué tipo de arquitectura es la más adecuada? ¿Qué tipo de experiencia de usuario (UX) es la correcta?

Sobre la evolución del proceso de diseño

Sigo haciendo Figma. Pero ahora no elaboramos documentos de especificaciones con tanta frecuencia, y normalmente tampoco tan detallados. Seguimos haciendo priorización; sigue existiendo como documento, pero por lo general son solo algunos bullet points, no una tabla bonita y de diseño excesivo.

Sobre la planificación y visión

En nuestro campo técnico los cambios son extremadamente rápidos: surgen nuevos modelos sin parar y la velocidad de actualización también va en aumento. Por eso, para nosotros no es realista establecer una visión de un año, y mucho menos una de dos a cinco años, porque hay demasiados factores desconocidos.

Sobre el futuro de los diseñadores

Si crees que el suelo bajo tus pies se mueve, es porque de hecho está cambiando. Tenemos que aceptarlo y aprender a adaptarnos, y también con una mentalidad abierta volver a examinar la forma en que trabajamos ahora.

Cada vez que siento que mi carrera se ve desafiada, en esos momentos pienso en mis colegas ingenieros. Su trabajo ya pasó por transformaciones enormes hace tiempo. Pero no solo se adaptaron a esos cambios, sino que además recibieron los desafíos con gran valentía y humildad, logrando finalmente resultados de trabajo más eficientes y mejores. Ellos son mi fuente de inspiración: me digo a mí misma que, si estos colegas que respeto muchísimo pueden hacerlo, entonces yo también puedo. Son un ejemplo de cómo adaptarse a los cambios.

Apertura

Peter Yang: Hola a todos. Hoy estoy muy emocionado de dar la bienvenida a Jenny, responsable de diseño de Anthropic. Jenny nos mostrará cómo usa Claude Cowork y Claude Code para diseñar y lanzar productos, y también compartirá con nosotros la historia interna de Cowork. Tal vez incluso hablemos sobre el siguiente paso de su producto.

Jenny, ¿cómo es un día típico en tu trabajo? ¿Qué tareas ocupan la mayor parte de tu tiempo?

Jenny:

No sé si existe un día típico como tal, pero la mayor parte del tiempo que paso haciendo cosas es sacar el producto adelante. Sin embargo, creo que quizá no se ve igual que hace uno o dos años. En gran parte, en realidad, es colaborar en tiempo real (jam) de manera bastante informal con ingenieros, personal de producto, etc. Normalmente, todos miran un prototipo a la vez, señalan y piensan cómo podría evolucionar. A veces es solo discutir el desempeño de una función; otras veces, implemento yo misma algunas cosas. Siento que todavía una gran parte de mi tiempo la dedico al diseño y a hacer prototipos, pero ahora la forma de hacer el trabajo de diseño se siente más laxa.

Peter Yang: Básicamente, generas un montón de prototipos con algo como Claude, y luego te sientas con los ingenieros a hacer jam, das feedback, y luego usas prompts para que la IA lo mejore, ¿correcto?

Jenny:

En realidad, muchas veces ni siquiera son prototipos, sino prototipos de trabajo que ya están construidos internamente y que se ejecutan en instancias de Claude o Cowork. Normalmente paso tiempo usando esta funcionalidad, empujándola, viendo de lo que es capaz, formando opiniones. Y el siguiente ciclo de iteración suele ser que me siento con los ingenieros y les digo: “Oye, yo pienso que esto es lo que debería cambiar”. Entonces siento que todavía es muy, muy importante tener tiempo para iterar, pulir y refinar dentro de herramientas de diseño. Así que esa parte no desapareció. Solo que, como ahora manejo más proyectos al mismo tiempo, siento que la manera más efectiva es hacerlo de forma muy informal, muy no estructurada.

Peter Yang: Creo que esa siempre ha sido la parte que más disfruto como gerente de producto o como diseñador: reunir a diseñadores e ingenieros, mirar cómo el producto itera junto. Así que, ¿ahora ustedes ya no hacen ese tipo de planificación con documentos de especificaciones, archivos de Figma, etc.? ¿O simplemente iteran prototipos directamente en el código?

Jenny:

Sigo haciendo Figma. Pero ahora no solemos hacer documentos de especificaciones con frecuencia, y normalmente tampoco tan detallados. Sí. Seguimos haciendo priorización, y sigue existiendo como documento. En realidad, esto nos ayuda mucho a entregárselo al equipo de seguridad o de legal, para que entiendan qué se está publicando. Pero normalmente son solo algunos bullet points, no tablas bonitas de diseño excesivo. Creo que nuestros archivos de Figma son igual.

Demostración práctica de Cowork

Peter Yang: ¿Podrías mostrarnos cómo usas estos productos, o para qué usa cada producto por separado?

Jenny:

Claro. Voy a explicar cómo uso Cowork. En realidad tengo un pequeño secreto: además de un trabajo de código de producción (production code) muy meticuloso, ahora casi todo lo que hago lo hago con Cowork. Si hay escenarios en los que necesito enfocarme en ciertos detalles del código, todavía usaría Claude Code. Pero para la comunicación y colaboración cotidianas, ahora dependo por completo de Cowork.

Creo que lo que más me sorprende de Cowork es su capacidad para organizar información. Me gusta llamarlo “basura entra, tesoros salen”. Puede recopilar información de varias fuentes, encontrar rápidamente los puntos clave, extraer contenido valioso y convertirlo en resultados con productividad real.

Por ejemplo, ahora conecté una carpeta donde se guardan algunas transcripciones de entrevistas a usuarios. Nuestro equipo de Cowork pone mucho énfasis en mantener una conexión estrecha con los usuarios, y eso es una de las claves de nuestro cierto éxito. Hacemos investigación tradicional de experiencia de usuario (UXR) y hablamos directamente con los usuarios. Al mismo tiempo, también lo hacemos con métodos internos para uso propio, por ejemplo, tenemos un canal de Slack dedicado para recopilar feedback. Además, también prestamos atención a las discusiones en redes sociales y escuchamos las opiniones de esos usuarios entusiastas. Justamente porque mantenemos siempre una conexión estrecha con los usuarios y podemos iterar el producto rápidamente, podemos seguir mejorándolo y logrando los resultados de hoy.

Entonces, lo que voy a hacer ahora es decirle a Claude: “Oye, tengo esta carpeta de entrevistas”. Pero también voy a hacer que Claude revise redes sociales, Reddit y otras reseñas de clientes de Cowork, para decirme cuáles son las mayores ideas. Podría tardar un poco porque realmente tiene que procesar tantos datos y convertirlos. Pero hará cosas, como a veces generar sub-agentes en paralelo para procesar, y también se tomará tiempo para buscar en la web.

Peter Yang: En tu trabajo real, ¿ustedes tienen algo como un informe semanal de ideas, donde automáticamente se resume todo y se lo envían a ti y al equipo?

Jenny:

En realidad, ya podemos hacerlo directamente con Cowork. Creo que hay investigadores que generan algo que se publica, y también tenemos una versión que nos hace ping en Slack. También escuchamos directamente en los canales internos de Slack. Dependemos muchísimo de los usuarios más fuertes del interior para darnos ese tipo de feedback de vanguardia, porque la gente interna realmente está dispuesta a ser honesta contigo; a menudo empujan las funciones hasta el límite y, además, suelen ser los más fáciles para dar seguimiento.

Peter Yang: Creo que eso es exactamente lo que debería pasar, y además siento que en la mayoría de las empresas los equipos están demasiado desconectados entre sí. Pero en Anthropic parece que no es así.

Jenny:

Creo que esta también es una parte importante del éxito de Claude Code: escuchar a los usuarios de primera línea. Y también es algo que hacemos muchísimo cuando trabajamos en Figma: hacemos mucho dogfooding interno. Porque, especialmente cuando se trata de diseño de interacción y de pulirlo, la gente interna realmente se meterá en esos detalles. Mientras que los usuarios externos, por lo general, el feedback que dan es más sobre si encaja en el flujo de trabajo de sus usuarios. Eso ofrece un nivel totalmente diferente de feedback.

Límites de usuarios entre Cowork y Claude Code

Peter Yang: Sé que ahora la gente de marketing y los product managers de Anthropic básicamente ya están usando Claude Code para hacer cosas, sobre todo después de que estuviera disponible dentro de Cowork. ¿Qué opinas sobre los diferentes tipos de escenarios de uso? ¿O cómo usa la gente Cowork y Claude Code?

Jenny:

Hemos notado que el alcance de aplicación de Cowork está ampliándose gradualmente, y que ya está empezando a usarse en escenarios parecidos a aquellos que antes intentaban los usuarios más avanzados de Claude Code. ¿Recuerdas cuando empezamos a desarrollar Cowork? El equipo de ventas interno era nuestra principal fuente de información. Algunas de esas personas eran usuarios avanzados de Claude Code, lo usaban para generar listas de prospectos, para escribir guiones de llamadas, etc. Cuando vi por primera vez estos casos de uso, me sorprendió mucho porque en ese momento ni siquiera se me había ocurrido que Claude Code pudiera usarse para hacer esas tareas. Pero ahora esos usuarios casi ya se cambiaron por completo a Cowork, e incluso sus compañeros empezaron a usar Cowork con mucha frecuencia.

Creo que es porque ahora tiene una UI que se ve bien. Así que pienso que esa es la razón real por la que lo necesitaban. Además, hay otra parte del motivo: está muy cerca de otras cosas en las que ellos ya están trabajando. Ellos ya usan funciones de chat; y desde esta aplicación de escritorio también pueden seguir usando Claude Code. Por eso siento que se ajusta más a su flujo de trabajo actual que abrir la línea de comandos.

Del descubrimiento a un Artifact ejecutable: el flujo completo

Jenny:

Aquí hay siete temas diferentes, y cada semana cambian. Básicamente puedo decirle directamente: “Ayúdame a crear este documento X”, y ya existe automáticamente en una carpeta en mi computadora. También puedo iniciar dos tareas en paralelo al mismo tiempo. Por ejemplo: puedo decir “Estas ideas están geniales, pero a partir de estas, ¿qué funciones de producto concretas debería construir?”. Luego también puedo hacer otra cosa en paralelo: convertir esos contenidos en una presentación que pueda compartir con el equipo cuando arranque esta semana (kickoff).

Pero al final, a partir de aquí ya puedo empezar el flujo de diseño: me dará varias opciones de funcionalidad. A partir de ahí, incluso puedo hacer que Claude me ayude a crear algunos wireframes para estas funciones. Puede que me dé un montón de opciones diferentes; yo puedo llevarlas a Figma para refinarlas de verdad, o llevarlas a Claude Code, y convertirlas en cosas reales con nuestros componentes reales del sistema de diseño. Y luego, a partir de ahí, seguir con el proceso.

Además, lo que también puedo hacer es convertir estas dos cosas en tareas programadas. Por ejemplo, haré que me ayude a programar la tarea para que se ejecute automáticamente todos los lunes a las 10 de la mañana. Entonces, cada lunes a las 10, ya estaré trabajando con esa presentación y con tres o cuatro ideas de producto diferentes para iniciar la semana. Comprime muchísimo el ciclo de iteración desde el feedback hasta convertirlo en algo tangible o en una idea que el equipo pueda ver. Nos ayuda a iterar rápido el producto y a mejorarlo rápidamente.

Peter Yang: Todo se trata de iterar. Todo se trata de iterar. Yo ahora también me vuelvo más perezoso: siempre dejo que la IA haga la primera versión y luego yo reacciono.

Jenny：

Sí. Así que si de verdad quieres que yo organice estas ideas desde cero en algún tipo de priorización de funciones, ahora tardaría mucho más que antes.

Yo también lo hago así. Por ejemplo, estas notas del podcast que me enviaste: tengo una carpeta personal de notas. Allí hay contenido de reuniones 1:1, ideas al azar, etc. Entonces simplemente digo: “Lee mis notas personales, ayúdame a pensar los puntos clave para hablar en este podcast, y también ayúdame a pensar qué quiero decir aquí”. Obviamente no lo leo palabra por palabra tal cual, pero de verdad me ayuda a abrir la mente, a evolucionar mi forma de pensar, en lugar de quedarme atascada.

Skills y base de conocimiento personal

Peter Yang：¿Qué skills usas? ¿O tienes skills dedicadas para ti para hacer estos documentos y diapositivas?

Jenny：

Tenemos varios skills internos dedicados para hacer documentos y diapositivas, porque nos ayudan a mantener la consistencia de marca. En realidad, no tengo un conjunto de skills personal: la mayor parte del tiempo tomo los skills que ya tenemos internamente y los uso con distintos propósitos.

Peter Yang：Por ejemplo, tengo un writing skill que le dirá a la IA que no use esas palabras basura de IA.

Jenny：

Pero en realidad descubrí que, como uso las carpetas de Cowork —donde guardo todas mis notas personales, etc.—, esto entiende cómo soy a través de esas carpetas. Y para mí ya es extremadamente útil. Más bien siento que cada vez necesito menos memory y skills, porque ya existe una base de conocimiento sobre mí. Claro que considero que los skills todavía tienen casos de uso adecuados, pero en mi caso actual, por cómo uso Cowork, siento que la necesidad no es tan grande.

Peter Yang：¿Es porque se actualiza la memoria automáticamente todos los días según tus conversaciones?

Jenny：

Sí. Básicamente es una memory que mantengo yo misma, porque siempre estoy tomando notas dentro de ella.

Nodos de colaboración del equipo

Peter Yang：Entonces, ¿en qué momento incorporas al equipo durante todo el proceso? ¿O alternas entre iterar con la IA y luego iterar con el equipo, de ida y vuelta, o cómo lo manejas?

Jenny：

Lo que quiero decir es que cosas como entrevistas reales de UXR, en realidad no las hago yo sola. Las hacen o bien un product manager, o un investigador dentro del equipo, o alguna otra persona del equipo. Luego, a través de esto, compartes directamente artifacts, involucrando a ellos, y en realidad eso se convierte en la base para el funcionamiento del equipo.

Nuestro equipo es al menos bastante bottom-up y democrático. Entonces, así es como operamos: damos a todos las ideas y los objetivos, y luego cada persona construye prototipos, prueba cosas, y las ideas vienen de todas direcciones. No es que yo como diseñadora tenga que inventarme todas las soluciones; es más bien: “Oigan, aquí están las ideas. Este es el objetivo que queremos alcanzar este mes. ¿Cómo lo logramos juntos?”

Con eso, tampoco entregamos directamente todo a Claude para que lo haga. Seguimos dependiendo de que nosotros tomemos muchas decisiones, y también de que gestionemos y decidamos qué vale la pena construir y qué vale la pena hacer.

Peter Yang：Cuando la gente habla en internet sobre el cultivo del buen gusto y el criterio, creo que los métodos para desarrollar esas capacidades se dan a través de obtener constantemente grandes cantidades de feedback de producto tanto desde dentro como desde fuera. En ese proceso, vas construyendo una intuición para detectar qué partes están fallando y necesitan reparación. Como escuchas y manejas esos feedback todos los días, con el tiempo desarrollas un sentido muy agudo de cuándo algo está mal.

Jenny：

En cuanto al diseño, una de las funciones de Claude es que puede generar bocetos tipo wireframe y ofrecer múltiples opciones de diseño. Como diseñadora, realmente me gusta este enfoque. Aunque la precisión de estos bocetos no sea tan alta, me permiten ver de forma intuitiva las diferentes posibilidades, sin depender completamente de mi imaginación. Este método me ayuda a decidir más rápido la dirección del diseño que sigue.

Así que creo que hacer que Claude genere directamente estas opciones iniciales me ahorra tiempo y esfuerzo en hacer bocetos manualmente. A partir de esas opciones, elijo una dirección e inicio iteraciones dentro de un alcance pequeño. Después, posiblemente use código para convertir esta dirección en un prototipo inicial, y luego continúe optimizando y perfeccionando el diseño sobre esa base.

Historia real del surgimiento de Cowork

Peter Yang：Hablemos de cómo surgió Cowork. Afuera hay muchas historias sobre que “lo hicieron en 10 días”, pero en realidad, antes de eso seguro ya había muchas iteraciones, ¿no?

Jenny：

La frase de “ellos lo hicieron en 10 días” en realidad se recorta de alguna entrevista o nota de medios; la gente siempre ha estado discutiendo alrededor de ese punto. Pero la situación real es que, sobre la dirección de Cowork, en realidad empezamos a planearlo desde que yo me uní a Anthropic hace un año. Estábamos pensando en cómo construir un “compañero de pensamiento” (thinking partner) que ayudara a todos los trabajadores del conocimiento de propósito general. Aunque Claude Code ya podía manejar muy bien tareas relacionadas con código, nuestro objetivo era abarcar todos los escenarios de trabajo con conocimiento. Siento que el desafío real era: ¿cómo ejecutamos esta idea? ¿Qué tipo de arquitectura es la más adecuada? ¿Qué tipo de experiencia de usuario (UX) es la correcta?

Durante el año pasado, probamos muchos prototipos diferentes. Algunas ideas incluso eran más ambiciosas que el objetivo actual. También realizamos muchas experimentaciones técnicas para probar distintos marcos de agentes de IA, pero algunos intentos no funcionaron. Finalmente, poco a poco definimos la dirección que tenemos ahora. No solo nos basamos en prototipos desarrollados por equipos de laboratorio, sino que también estudiamos prototipos que construyó nuestro propio equipo de producto. Al final, el momento y la capacidad de ejecución fueron clave, como cuando el rayo cae justo en el blanco.

Cuando decidimos lanzar este producto, todo el proceso fue muy rápido: desde el “deberíamos publicarlo” hasta que el producto ya estaba en línea, tomó solo 10 días. Principalmente fue porque durante las vacaciones de Claude Code vimos su potencial. Durante las vacaciones, muchas personas por fin tuvieron tiempo de probar Claude Code, e incluso algunos usuarios que no eran técnicos empezaron a usarlo: por ejemplo, para analizar transcripciones de podcasts o para hacer análisis de datos complejos. Descubrimos que el marco de agentes de Claude Code también empezaba a mostrar encaje temprano producto-mercado entre usuarios no técnicos. En realidad, para ese momento ya teníamos un prototipo que funcionaba; inicialmente se planeaba publicar un poco más tarde. Pero esos feedback nos hicieron entender que “ahora es el mejor momento”. Entonces decidimos aprovechar esta oportunidad, y al final logramos esos locos 10 días.

Peter Yang: Si no lo entendí mal, durante el año pasado compartieron muchos prototipos en su Slack interno, recopilaron grandes cantidades de feedback y finalmente determinaron un prototipo viable. Luego, al ver la demanda del mercado, hicieron un sprint rápido y lo lanzaron.

Jenny：

Exactamente, más o menos así. En realidad, planeábamos lanzar en unas semanas más, pero en ese momento sentimos que “este es el mejor momento”. Esto también nos empujó a reducir el alcance del producto a algo más realista y alcanzable, dado que el tiempo era limitado, y a poner todo nuestro esfuerzo y recursos. Y finalmente logramos el lanzamiento.

Iteración temprana de diseño: de una herramienta de workflow a un chat minimalista

Peter Yang：¿Puedes compartir algunas experiencias sobre la iteración temprana, o mostrar contenido que se esté desarrollando?

Jenny：

Por supuesto. Preparé algunas capturas de pantalla tempranas para mostrar nuestras ideas de diseño y el proceso de iteración en ese momento.

A principios de este año, tuvimos un prototipo inicial que desarrollé junto con otro diseñador. En ese momento, intentamos orientar la herramienta más hacia tareas específicas (task-oriented) o hacia un enfoque de flujo de trabajo (workflow-oriented). Porque nos preocupaba mucho si los usuarios podrían entender cómo usar un producto como Cowork, si podrían completar tareas concretas o lograr resultados claros (outcome), como crear un dashboard o integrar datos de diferentes fuentes. Por eso, diseñamos la interfaz de forma muy estructurada, casi como una herramienta de flujo de trabajo: “agrega este contenido; estos son inputs, estos son outputs”. La función de chat quedó en segundo plano.

Pero parecía demasiado complejo, con muchos pasos para completar todo. En la era de 2025, ¿por qué hacer algo tan complicado? ¿No sería más simple dejar que Claude lo maneje directamente?

Esa fue una de nuestras primeras ideas, pero luego decidimos cambiar a un enfoque más simple, como un cuadro de chat (chat box). Intentamos guiar a los usuarios para que logren objetivos más específicos, como análisis o generación de documentos. También diseñamos un prototipo funcional: el usuario hace clic y puede ver varias opciones, cada una con botones para ajustar, por ejemplo, la longitud del documento o el tipo de contenido, como un memo o una presentación. Pero ese diseño resultó ser demasiado complejo y abrumador para los usuarios.

Por eso, en varias exploraciones y pruebas, buscamos un equilibrio: ¿deberíamos definir claramente los escenarios de uso, o mantenerlo más abierto, como un chat libre?

La versión que lanzamos hace unas semanas es la que ves ahora. Probamos una experiencia casi como un “asistente guiado” (wizard-like): el usuario hace clic y recibe indicaciones como “crea un documento de tres a cinco páginas”, etc.

En ese momento también añadimos muchos elementos visuales para que pareciera diferente a un chat normal. Pero pronto descubrimos que ese diseño hacía que la interfaz fuera demasiado compleja, con demasiados elementos visuales compitiendo por la atención. Así que decidimos simplificar, eliminando la mayoría de los elementos innecesarios.

La interfaz actual está mucho más simplificada. Quitamos las barras laterales pesadas para que se parezca más a un chat tradicional, pero hicimos algunos cambios en la página principal para que parezca una “lista de tareas” (to-do list) compartida entre yo y Claude, en lugar de una herramienta llena de sugerencias y guías.

Peter Yang: Quizá en el futuro pueda soportar múltiples agentes (agent), y puedas arrastrar tareas para gestionar el flujo de trabajo.

Jenny:

Quizá sea posible. Pero quiero destacar que el diseño de la interfaz era completamente diferente hace unas cuatro o cinco semanas. Seguimos aprendiendo y explorando qué diseño funciona mejor, qué no funciona tan bien, y buscando la mejor forma de presentar esta tecnología a los usuarios.

Diferenciación entre Cowork y Claude Code

Peter Yang: En el uso de Claude Code, a menudo comparto feedback en Twitter. Tiene muchos slash commands integrados, y requiere que los usuarios aprendan poco a poco. La experiencia es como una “caza del tesoro” en Costco: nunca sabes qué función nueva vas a descubrir.

Pero para los principiantes, ese enfoque no es muy amigable. Es más como un juego. Con el uso, vas familiarizándote y dominándolo. Siento que Cowork intenta explorar un punto intermedio entre una herramienta de chat normal y Claude Code. No oculta todas las funciones, pero guía a los usuarios para que las usen mejor.

Jenny:

Sí. En Cowork todavía se admiten slash commands, pero no son la forma principal de interacción. Personalmente, creo que Cowork es al menos una herramienta para profesionales. Muchos ya lo usan como usuarios avanzados, y en la comunidad ya hay algunos usuarios expertos. Estos usuarios están dispuestos a dedicar tiempo a aprender funciones más complejas, como crear skills, compartir con el equipo o usar comandos abreviados.

Pero nuestro objetivo es que esas funciones sean una forma secundaria de interacción, no algo obligatorio. Incluso si los usuarios no conocen todos los comandos, pueden usar Cowork fácilmente. Queremos que la interacción con Claude sea natural e intuitiva, no que tengan que memorizar comandos para operar.

Proceso de planificación y visión

Peter Yang: ¿Cómo es el proceso de planificación en Anthropic? ¿Hacen planificación anual y establecimiento de metas? ¿O se basan más en prototipos y pruebas continuas?

Jenny:

Nuestro método de planificación varía. En mi equipo, hacemos planificación mensual. Tenemos una hoja de cálculo donde, al menos en la parte de Cowork, listamos unas 12 tareas principales, que son nuestras prioridades P0. Cada tarea tiene un responsable directo (DRI). Cada semana revisamos: ¿estamos en el camino correcto? También hacemos planificaciones trimestrales o semestrales, generalmente con un responsable que dice: “Creo que debemos avanzar en esta dirección. Estas son las cosas en las que debemos enfocarnos”. Pero esas planificaciones no son estrictas; más bien, sirven para dar una orientación general, y son bastante flexibles.

Peter Yang: Relativamente flexible, ¿verdad? Es interesante que las empresas más innovadoras suelen hacer menos planificación anual y más iteración y aprendizaje con los usuarios. ¿Has hecho algo similar a un deck de visión North Star en tu carrera? ¿Crees que son útiles?

Jenny:

Sí, hice uno el año pasado. Un deck de visión North Star. Creo que las visiones tienen valor: orientan al equipo y nos ayudan a mantener claridad en los objetivos. Pero en nuestro campo, que cambia tan rápido, surgen modelos nuevos constantemente y la velocidad de actualización también aumenta. Por eso, no es realista definir una visión de un año, y mucho menos de dos a cinco años, por la cantidad de factores desconocidos.

Pero la verdadera utilidad de una visión es guiar a todos en la misma dirección, especialmente en un entorno donde cada uno puede construir proyectos libremente. Por eso, ahora creo que la visión debería tener un horizonte de máximo tres a seis meses, y presentarse en forma de documento. Cuando la visión se puede visualizar, tiene más impacto. Esa es también la gran ventaja del diseño: integrar elementos, contar una historia coherente en un periodo determinado. La visión puede ser un prototipo, no solo un deck estático. Ayuda a coordinar el trabajo entre equipos, especialmente cuando hay cinco equipos trabajando en proyectos similares o potencialmente conflictivos. El diseño puede ayudar a alinear esas ideas mediante curaduría, y mostrarnos un camino hacia la experiencia de usuario ideal, en lugar de experiencias dispersas.

Peter Yang: Entonces, ¿tienen revisiones con los product managers? ¿O revisiones para las partes interesadas? ¿Son formales, o también participan en la fase de prototipado?

Jenny:

Sí, hacemos revisiones. Pero no como en algunas empresas donde cada función pasa por una revisión formal. Nuestras revisiones se centran en proyectos grandes y prioritarios. El objetivo no es gastar mucho tiempo preparándolas, sino aumentar la visibilidad y obtener feedback. Si hay proyectos importantes que cruzan equipos o impactan a toda la empresa, los revisamos.

Consejo para diseñadores: cómo encontrar tu lugar en la era de la IA

Peter Yang: Entonces, para los diseñadores que sienten que su entorno profesional cambia rápidamente, ¿qué consejos les darías? ¿Deberían empezar a aprender a hacer PR de código? ¿O los diseñadores deberían adoptar otras formas de adaptarse?

Jenny:

Si sientes que el suelo bajo tus pies se mueve, es porque de hecho está cambiando. Tenemos que aceptarlo, aprender a adaptarnos y también con una mentalidad abierta revisar cómo trabajamos ahora. Creo que estos cambios afectan mucho a los diseñadores, especialmente porque estamos en la segunda ola de esta tendencia. Otros roles ya han pasado por transiciones similares; ahora nos toca a nosotros. Además, nuestras herramientas de diseño también están en constante evolución.

Cada vez que siento que mi carrera se pone a prueba, me siento un poco inquieta, como: “Dios, mi trabajo está cambiando mucho y quizás ya no valoren tanto lo que hago”. Pero cuando eso pasa, pienso en mis colegas ingenieros. Ellos ya pasaron por cambios enormes hace tiempo, y no solo se adaptaron, sino que enfrentaron los desafíos con valentía y humildad, logrando resultados más eficientes y mejores. Son mi inspiración: me digo que si estos colegas que respeto mucho pueden hacerlo, yo también puedo. Son un ejemplo de cómo adaptarse a los cambios.

Peter Yang: En cierto modo, estos cambios liberan a los diseñadores de tareas repetitivas y tediosas, como ajustar marcos y cajas, ¿verdad? Así pueden dedicar más energía a pensar en niveles superiores y en trabajo creativo.

Jenny:

Exacto. O mejor dicho, estos cambios nos permiten hacer más trabajo. Por ejemplo, cuando veo que mis colegas ingenieros ahora pueden completar una funcionalidad completa en unos días, cuando antes tomaba semanas, me sorprende mucho. Así que sí, estos cambios también abren más posibilidades.