OperacionesdeDiseño.
El sistema operativo del equipo. Lo que separa al Senior que construye al Lead que opera.
Elcuellodebotelladelequipoerestú.
Construye un buen Design System.
Se asegura de que el equipo lo usa sin necesidad de preguntarle.
Figma operado
La estructura que uso en cada proyecto.
Cada página con su emoji al principio + prefijo de estado en corchetes durante el proceso ([WIP], [Review], [UX Test], [Ready]). El equipo navega sin preguntar.
Cada capa describe función, no forma.
Test del ciego
Borra mentalmente colores y formas. ¿Alguien podría reconstruir el componente leyendo solo el árbol? Si sí, naming senior.
Orden visual = orden de capas
Si el icono va a la izquierda del label, en el panel va antes. La IA genera código en el orden que lee.
ElnombredelaSectioneslaprimeralíneaqueleelaIA.
Section 452Sin contexto. La IA improvisa la lógica.
[PROD-123] Checkout-Payment-MethodsID del ticket + lógica de negocio. La IA entiende contexto antes de ver componentes.
Y usa el estado nativo: Draft · Ready for Dev · Done.
Agrupa por dimensión semántica. No por booleanos sueltos.
No comunica que son estados del mismo concepto. La IA deduce. Deducir = equivocarse.
Una propiedad con valores múltiples = grupo lógico claro.
Mutuamente excluyentes → agrupa. Verdaderamente opcionales (showIcon) → booleano OK.
El Playbook
5 páginas que el equipo consulta. No 100 que nadie lee.
Criterios de decisión. «Mobile First sobre Desktop», no «hacemos cosas bonitas».
Herramientas, organización del Figma, convención de naming.
Critique, sync con dev, retro de ops. Cortos, con objetivo, liderados.
Anotaciones, estados de error, edge cases, link al componente. Nunca «una pantalla bonita».
La checklist que cierra el ciclo. Lo vemos al final.
Buscador, base de datos, fácil de editar. Revisión cada 3-6 meses.
La frase de Lead
«EstáenelPlaybook.»
Cuanto más uses esa frase, menos cuello de botella eres. Cuanto menos cuello de botella seas, más Lead te vuelves.
ADRs · memoria del producto
Unadecisiónsindocumentaresopinión.Documentada,esleydeproducto.
Refactor checkout
40% abandono en paso 2
Dropdown → calendario
Test: 40% no entiende MM/DD
Aceptado
Cómo blinda tus decisiones
«En el ADR-14 documentamos que el dropdown causó −40% de conversión. Si volvemos atrás, aceptamos ese riesgo en el KPI.» La discusión deja de ser gustos. Pasa a ser riesgos de negocio.
Definition of Done. Tu última línea de defensa.
- ▸Tokens semánticos exclusivos
- ▸Componentes vinculados a librería
- ▸Contraste WCAG
- ▸Estados error/carga/vacío
- ▸Copy real, validado
- ▸Inicio y fin del flujo claros
- ▸Auto Layout responsive
- ▸Interacciones documentadas
- ▸Animaciones con sticky notes
«Un dev que no te pregunta es un dev que defiende tu diseño en las reuniones donde tú no estás.»
Conviertetuarchivoensistemaoperativodelequipo.
Aplica todo lo del vídeo a un proyecto real o ficticio. No el manual completo: la versión 1 que tu equipo pueda consultar.
Reorganiza el Figma con las 12 páginas en 3 fases.
Contexto · Proceso (con prefijos [WIP] / [Review] / [UX Test] / [Ready]) · Soporte. Puedes partir de la plantilla descargable.
Renombra capas de 1 componente.
Convención semántica función-no-forma. Aplica el test del ciego.
Crea el Playbook v1 en Notion.
5 principios · taxonomía · 2 rituales con día+duración · Definition of Done.
Documenta 1 ADR real.
Título · contexto · decisión · justificación con datos · estado.
Módulo 03 · cerrado
HasconstruidoelsistemaoperativodeunLead.
Ya no solo sabes hacer cosas. Sabes cómo organizar el equipo para que las haga sin necesitarte.
Próximo módulo · 04