Captura y comparte el conocimiento de diseño: los principios aprendidos, las decisiones documentadas y el sistema de gestión del conocimiento que acelera el aprendizaje de los diseñadores nuevos.
Cuándo usarlo: Construir la base de conocimiento del equipo de diseño
Herramienta recomendada: Claude
Eres un experto en gestión del conocimiento para equipos de diseño de producto y diseño gráfico. Quiero que me ayudes a construir el sistema que captura el aprendizaje colectivo del equipo y lo hace accesible para que los nuevos diseñadores no partan de cero y los seniors no tengan que repetir siempre las mismas explicaciones. Mi contexto: - Tipo de equipo de diseño: [producto, gráfico, UX research, brand, mix] - Tamaño del equipo: [número de personas y nivel de seniority] - Herramientas de diseño: [Figma, Sketch, Adobe XD, herramientas de prototipado] - Herramientas de documentación: [Notion, Confluence, Google Docs, Zeroheight, nada organizado] - Problema principal: [decisiones de diseño que se repiten, onboarding lento, falta de coherencia entre proyectos] Con esa información, quiero que me entregues: 1. EL DESIGN SYSTEM COMO BASE DE CONOCIMIENTO Explica cómo el design system es el artefacto principal de gestión del conocimiento de un equipo de diseño: no solo los componentes visuales sino también los principios que los guían, los patrones de interacción documentados y la lógica de las decisiones tomadas. Define qué debe documentarse más allá del componente en sí (el cuándo usarlo, el cuándo no, las alternativas descartadas) y cómo mantener la documentación sincronizada con la evolución del design system. 2. DESIGN DECISIONS RECORDS: DOCUMENTAR EL POR QUÉ EN DISEÑO Define un formato análogo a los ADRs de ingeniería para las decisiones de diseño importantes: el contexto del problema, la decisión tomada, los criterios de evaluación, las alternativas consideradas y las consecuencias conocidas. Dame una plantilla de Design Decision Record y un ejemplo concreto para una decisión de navegación o de componente complejo. Explica cómo integrar estos registros en el flujo de trabajo de diseño. 3. LIBRARY DE APRENDIZAJES Y RETROSPECTIVAS DE PROYECTO Diseña el formato de retrospectiva de proyecto de diseño que genera conocimiento reutilizable: qué preguntas hacer al final de cada proyecto para extraer los aprendizajes más valiosos, cómo capturarlos en un formato consultable y cómo etiquetarlos para que sean fáciles de encontrar cuando el equipo afronte un proyecto similar. Dame una plantilla de retrospectiva de diseño con las preguntas y la estructura del documento de aprendizajes. 4. ONBOARDING DE DISEÑADORES: LA INMERSIÓN EN EL CONOCIMIENTO DEL EQUIPO Diseña el plan de onboarding para un nuevo diseñador: los artefactos que debe revisar en la primera semana (design system, brand guidelines, decisiones pasadas, ejemplos del mejor trabajo del equipo), las conversaciones que debe tener con los seniors, los ejercicios de familiarización con el producto y el proceso de los primeros 30 días para que empiece a contribuir con criterio. Dame un template de onboarding de 30 días para un diseñador de producto. 5. RITUALES DE CONOCIMIENTO EN EL EQUIPO DE DISEÑO Define los rituales que convierten el equipo en una organización que aprende: el critique semanal como mecanismo de aprendizaje colectivo (cómo estructurarlo para que sea psicológicamente seguro y genere feedback accionable), el design review como momento de documentar decisiones y el design share mensual donde los miembros del equipo presentan aprendizajes de proyectos recientes. Explica cómo facilitar cada ritual para que genere conocimiento y no solo conversación. 6. HERRAMIENTAS Y ARQUITECTURA: DÓNDE VIVE EL CONOCIMIENTO DE DISEÑO Recomienda la arquitectura de herramientas para el conocimiento de diseño: cómo usar Figma no solo para diseñar sino para documentar (pages de documentación, componentes anotados, prototype flows explicados), cuándo usar una herramienta de wiki dedicada versus Figma para el conocimiento y cómo conectar la herramienta de diseño con la herramienta de documentación para que el desarrollador que implementa también acceda al conocimiento. Termina con un plan de 60 días: qué construir en el primer mes para cubrir los gaps más urgentes de conocimiento y qué rituales establecer en el segundo mes para que el sistema crezca de forma orgánica.