Curso de DDD (Decision Driven Design) para tu equipo técnico

Entender Decision Driven Design como un enfoque que coloca las decisiones en el centro del diseño de productos, procesos y sistemas.

Diferenciarlo de Domain-Driven Design, Data Driven Development, diseño UX tradicional, discovery de producto y modelado de procesos.

Reconocer que una solución digital aporta valor cuando ayuda a decidir, actuar, automatizar o reducir incertidumbre.

Identificar decisiones explícitas, implícitas, humanas, automatizadas, asistidas por IA y distribuidas entre varios equipos.

Separar decisiones estratégicas, tácticas, operativas, técnicas, regulatorias y de producto.

Analizar por qué muchos proyectos fallan al diseñar pantallas, funcionalidades o dashboards sin entender la decisión que deben soportar.

Revisar ejemplos: scoring de leads, gestión de incidencias, priorización de mantenimiento, concesión de permisos, rutas operativas o recomendaciones.

Entender la relación entre decisión, contexto, información, criterio, consecuencia y feedback.

Establecer cuándo una decisión debe automatizarse, cuándo asistirse y cuándo mantenerse bajo control humano.

Crear una definición práctica de Decision Driven Design adaptada a proyectos empresariales.

Tratar cada decisión relevante como un objeto de diseño con dueño, propósito, entrada, salida, criterios y consecuencias.

Describir la decisión con una pregunta concreta que pueda responderse mediante opciones.

Identificar el punto del proceso donde la decisión aparece y qué ocurre antes y después.

Definir qué nivel de autonomía tiene la persona, equipo, sistema o algoritmo que decide.

Separar decisiones únicas, recurrentes, secuenciales, reversibles, irreversibles, automatizables y críticas.

Analizar coste de una mala decisión: económico, operativo, reputacional, legal, técnico o de experiencia.

Representar relaciones entre decisiones dependientes o encadenadas.

Revisar qué decisiones se están tomando hoy de forma informal, manual, opaca o inconsistente.

Priorizar decisiones que merecen diseño explícito por impacto, frecuencia, riesgo o complejidad.

Crear un inventario inicial de decisiones del producto, proceso o sistema.

Mapear actores que participan en una decisión: usuario final, operador, manager, técnico, cliente, sistema, IA, auditor o proveedor.

Identificar quién decide, quién recomienda, quién valida, quién ejecuta, quién revisa y quién recibe el impacto.

Representar decisiones dentro de un flujo de trabajo completo.

Detectar puntos donde varias áreas toman decisiones contradictorias con información distinta.

Localizar decisiones ocultas dentro de emails, hojas de cálculo, reuniones, tickets o conocimiento informal.

Analizar dependencias entre decisiones de negocio, decisiones técnicas y decisiones operativas.

Visualizar qué decisiones son manuales, semiautomáticas o completamente automatizadas.

Revisar qué decisiones carecen de responsable claro.

Detectar decisiones duplicadas que generan inconsistencias o retrabajo.

Crear un mapa de decisión que sirva como base para rediseñar procesos, sistemas o productos.

Convertir problemas vagos en preguntas de decisión claras y accionables.

Diferenciar preguntas de diagnóstico, preguntas de selección, preguntas de aprobación, preguntas de priorización y preguntas de predicción.

Evitar preguntas demasiado amplias como “¿qué hacemos?” y transformarlas en alternativas concretas.

Formular decisiones con estructura: contexto, opción, criterio, consecuencia y plazo.

Identificar cuándo una pregunta no puede resolverse por falta de datos, falta de criterio o falta de autoridad.

Separar preguntas que deben responder personas de preguntas que puede responder un sistema.

Crear preguntas que ayuden a diseñar pantallas, dashboards, alertas, reglas o automatizaciones.

Revisar si una pregunta está sesgada hacia una alternativa ya preferida.

Preparar preguntas de decisión para reuniones, discovery, documentación y análisis técnico.

Construir una biblioteca de preguntas recurrentes para producto, operaciones, negocio y arquitectura.

Definir criterios explícitos para comparar alternativas: valor, coste, riesgo, urgencia, esfuerzo, cumplimiento, impacto y experiencia.

Diferenciar criterios obligatorios, deseables, ponderables, cualitativos y cuantitativos.

Identificar restricciones no negociables: normativa, presupuesto, plazo, seguridad, capacidad técnica o contrato.

Representar trade-offs entre velocidad, calidad, coste, escalabilidad, simplicidad, flexibilidad y control.

Evitar decisiones basadas en un único criterio dominante cuando el problema requiere equilibrio.

Crear matrices de decisión para ordenar alternativas de forma transparente.

Documentar por qué una alternativa se descarta aunque parezca atractiva.

Revisar sesgos que alteran la ponderación de criterios.

Ajustar criterios según tipo de decisión: producto, arquitectura, inversión, proceso, IA o compliance.

Convertir trade-offs en conocimiento reutilizable para futuras decisiones.

Generar alternativas reales antes de decidir, evitando elegir entre una opción preparada y no hacer nada.

Separar opción preferida, opción mínima, opción conservadora, opción exploratoria y opción de alto riesgo.

Diseñar escenarios de decisión con diferentes condiciones de contexto.

Evaluar alternativas según resultados esperados y consecuencias no deseadas.

Analizar coste de oportunidad de cada opción.

Comparar opciones reversibles e irreversibles para definir nivel de análisis requerido.

Diseñar pruebas rápidas para reducir incertidumbre antes de elegir.

Evitar falsas dicotomías cuando existen combinaciones o soluciones intermedias.

Documentar supuestos de cada alternativa.

Crear una práctica de exploración suficiente antes de cerrar decisiones importantes.

Entender DMN como una forma estructurada de representar decisiones, entradas, reglas y resultados.

Crear tablas de decisión para reglas de negocio repetibles y evaluables.

Diferenciar decisión, input data, knowledge source, business knowledge model y resultado.

Modelar reglas de aprobación, clasificación, scoring, asignación, priorización o cálculo.

Usar tablas de decisión para hacer visibles reglas que antes estaban ocultas en código, hojas de cálculo o personas.

Revisar consistencia, cobertura, solapamientos y contradicciones en reglas.

Identificar cuándo DMN aporta claridad y cuándo una matriz simple es suficiente.

Conectar DMN con procesos BPMN, APIs, formularios o motores de reglas.

Versionar reglas de decisión como parte del ciclo de vida del producto.

Crear documentación legible para negocio, desarrollo, QA y auditoría.

Diseñar árboles de decisión para problemas con ramificaciones secuenciales.

Representar criterios de avance, condiciones, excepciones, salidas y rutas alternativas.

Comparar árboles de decisión con tablas de decisión, flujos BPMN y lógica imperativa en código.

Evitar árboles demasiado profundos que se vuelven difíciles de mantener.

Detectar condiciones redundantes, inalcanzables o contradictorias.

Transformar lógica condicional dispersa en un modelo comprensible.

Identificar nodos que requieren datos no disponibles o interpretación humana.

Diseñar árboles para soporte, diagnóstico, elegibilidad, clasificación o recomendación.

Preparar pruebas de cobertura sobre caminos principales y excepciones.

Documentar cómo el árbol debe evolucionar cuando cambian reglas, criterios o datos.

Crear decision records para capturar decisiones importantes de producto, proceso, datos, UX o arquitectura.

Diferenciar ADRs técnicos de registros de decisión de negocio, producto o proceso.

Documentar contexto, opciones evaluadas, decisión tomada, motivos, consecuencias y fecha de revisión.

Evitar documentos largos que nadie consulta y crear registros breves pero accionables.

Usar decision records para reducir debates repetidos y pérdida de conocimiento.

Conectar decisiones con tickets, requisitos, modelos, código, dashboards o releases.

Registrar decisiones reversibles, temporales, experimentales y definitivas con estado claro.

Incorporar revisión de decisiones cuando cambian supuestos.

Crear una plantilla corporativa de decision record.

Convertir la memoria de decisiones en un activo de gobierno y aprendizaje.

Diseñar interfaces alrededor de la decisión que debe tomar el usuario.

Identificar qué información es necesaria, qué información sobra y qué información debe destacarse.

Reducir carga cognitiva mostrando opciones, consecuencias, riesgos y recomendaciones con claridad.

Diseñar estados vacíos, alertas, explicaciones, comparativas y confirmaciones orientadas a decidir.

Evitar dashboards decorativos que informan mucho pero no ayudan a actuar.

Crear journeys donde cada paso reduce incertidumbre o prepara una decisión.

Usar microcopy para explicar criterios, límites, avisos y consecuencias.

Diseñar confirmaciones para decisiones irreversibles o de alto impacto.

Incorporar accesibilidad y claridad en decisiones bajo presión operativa.

Validar interfaces observando si los usuarios toman mejores decisiones, no solo si completan tareas.

Diseñar dashboards partiendo de decisiones concretas y no de disponibilidad de datos.

Definir para cada gráfico qué pregunta responde y qué acción podría activar.

Separar indicadores de salud, diagnóstico, comparación, alerta y seguimiento.

Evitar métricas vanidosas que no cambian ninguna decisión.

Incorporar umbrales, tendencias, segmentos, contexto y explicación de anomalías.

Diseñar vistas para roles distintos: dirección, operación, soporte, producto, ventas, mantenimiento o seguridad.

Añadir señales de confianza: fecha de actualización, fuente, calidad del dato y definición de métrica.

Crear dashboards que ayuden a priorizar, aprobar, escalar, investigar o corregir.

Medir si el dashboard reduce tiempo de decisión o mejora calidad de actuación.

Establecer revisión periódica para retirar gráficos que ya no apoyan ninguna decisión.

Identificar qué datos son imprescindibles, cuáles son útiles y cuáles solo añaden ruido.

Mapear fuentes de datos: sistemas transaccionales, eventos, formularios, sensores, logs, encuestas, CRM, ERP o data warehouse.

Evaluar calidad, actualidad, granularidad, cobertura y sesgos de cada fuente.

Detectar decisiones que hoy se toman con datos incompletos o poco fiables.

Diseñar eventos y métricas pensando en decisiones futuras.

Evitar capturar datos personales o sensibles si no son necesarios.

Crear un diccionario de datos vinculado a decisiones críticas.

Definir owners de datos para que cada decisión tenga fuentes mantenidas.

Diseñar indicadores de confianza en la información mostrada.

Conectar calidad de datos con calidad de decisión.

Entender la relación entre Decision Driven Design, decision intelligence e IA aplicada a decisiones.

Diferenciar automatización de decisión, recomendación asistida, predicción y análisis explicativo.

Diseñar sistemas donde la IA propone, pero la persona conserva control cuando el riesgo lo exige.

Identificar decisiones candidatas a IA por volumen, datos disponibles, patrón repetible y valor esperado.

Definir entradas, salidas, límites y explicaciones mínimas de una recomendación.

Evitar modelos opacos en decisiones de alto impacto sin validación ni supervisión.

Diseñar feedback loops para mejorar recomendaciones con resultados reales.

Documentar supuestos, datos de entrenamiento, sesgos, métricas y límites del sistema.

Integrar IA en interfaces de decisión sin convertirla en autoridad incuestionable.

Crear criterios para decidir cuándo usar reglas, analítica, IA generativa, machine learning o decisión humana.

Clasificar decisiones según grado de automatización aceptable.

Identificar decisiones que pueden automatizarse por ser frecuentes, simples y de bajo riesgo.

Mantener revisión humana en decisiones ambiguas, excepcionales, sensibles o de alto impacto.

Diseñar umbrales de confianza para que el sistema decida, recomiende o escale.

Crear mecanismos de override, revisión, auditoría y explicación.

Evitar automatizaciones rígidas que no gestionan excepciones reales.

Diseñar procesos de escalado cuando la decisión supera reglas previstas.

Medir falsos positivos, falsos negativos, errores, tiempo ahorrado y satisfacción de usuarios.

Documentar qué decisiones son automáticas y bajo qué condiciones.

Construir confianza progresiva antes de ampliar automatización.

Aplicar Decision Driven Design a decisiones de arquitectura, tecnología, integración y plataforma.

Formular decisiones técnicas como preguntas con alternativas y criterios.

Comparar opciones de arquitectura según escalabilidad, coste, complejidad, seguridad, resiliencia y mantenibilidad.

Usar ADRs para documentar decisiones técnicas relevantes.

Evitar decisiones arquitectónicas por moda tecnológica sin criterio explícito.

Relacionar decisiones de arquitectura con objetivos de negocio y restricciones operativas.

Diseñar modelos C4, diagramas de secuencia o matrices para explicar trade-offs.

Revisar decisiones técnicas cuando cambian volumen, equipo, coste, requisitos o riesgo.

Incorporar seguridad, observabilidad, despliegue y soporte como criterios desde el inicio.

Crear un proceso ligero de revisión arquitectónica basado en decisiones, no en comités pesados.

Convertir roadmap en una secuencia de decisiones sobre valor, oportunidad, riesgo y aprendizaje.

Priorizar problemas antes que soluciones cerradas.

Evaluar iniciativas con matrices de impacto, esfuerzo, evidencia, riesgo y alineación estratégica.

Diferenciar decisiones de discovery, decisiones de delivery y decisiones de go-to-market.

Evitar roadmap dominado por peticiones aisladas sin criterio común.

Diseñar experimentos para decidir si una funcionalidad merece inversión.

Registrar decisiones de priorización y motivos de descarte.

Revisar decisiones de producto tras medir adopción, impacto y aprendizaje.

Comunicar decisiones de roadmap con claridad a stakeholders.

Crear una cadencia de decisión donde producto evoluciona por evidencia y estrategia.

Rediseñar procesos identificando primero las decisiones que los gobiernan.

Separar tareas mecánicas de decisiones que requieren criterio.

Detectar cuellos de botella donde una decisión tarda demasiado o depende de información dispersa.

Modelar aprobaciones, excepciones, escalados, derivaciones y controles.

Comparar procesos actuales con procesos objetivo centrados en decisiones críticas.

Identificar decisiones que pueden convertirse en reglas, formularios, dashboards o automatizaciones.

Diseñar roles y responsabilidades para reducir ambigüedad.

Medir tiempos de decisión, retrabajo, errores y excepciones.

Documentar reglas de proceso como modelos de decisión mantenibles.

Crear procesos más simples eliminando pasos que no aportan información ni mejoran la decisión.

Diseñar APIs pensando en decisiones que consumirán aplicaciones, usuarios o sistemas externos.

Identificar qué información debe exponer una API para que otro sistema pueda decidir correctamente.

Evitar endpoints que devuelven datos abundantes pero no orientados a casos de decisión.

Modelar reglas de autorización, validación y respuesta como decisiones explícitas.

Diseñar errores de API que ayuden a corregir o decidir el siguiente paso.

Documentar decisiones de versionado, compatibilidad y deprecación.

Evaluar integraciones según criticidad de las decisiones que soportan.

Crear contratos que reflejen criterios, estados y consecuencias de negocio.

Diseñar plataformas internas que guíen a equipos hacia decisiones técnicas correctas por defecto.

Medir si las APIs reducen fricción, incertidumbre y soporte en equipos consumidores.

Reconocer decisiones con información incompleta, cambios rápidos o alta incertidumbre.

Diferenciar riesgo conocido, incertidumbre desconocida y ambigüedad.

Diseñar decisiones reversibles con menos análisis y decisiones irreversibles con más rigor.

Usar experimentos, prototipos, spikes y pilotos para reducir incertidumbre.

Definir umbrales de información suficiente para decidir sin caer en parálisis.

Preparar escenarios optimista, realista, pesimista y de fallo.

Documentar supuestos críticos que deben revisarse.

Diseñar planes de contingencia y señales tempranas de corrección.

Incorporar aprendizaje posterior como parte del diseño de decisión.

Crear una cultura donde decidir con incertidumbre no significa decidir sin método.

Construir matrices de priorización adaptadas al tipo de problema.

Usar criterios ponderados para comparar iniciativas, features, riesgos, proveedores o arquitecturas.

Aplicar modelos como RICE, WSJF, ICE, impacto-esfuerzo o scorecards personalizados con sentido crítico.

Evitar que las puntuaciones parezcan objetivas cuando se basan en estimaciones débiles.

Combinar datos cuantitativos con juicio experto documentado.

Revisar sensibilidad: qué ocurre si cambia el peso de un criterio.

Preparar visualizaciones para explicar decisiones de priorización.

Documentar opciones descartadas y condiciones que podrían reabrirlas.

Crear una práctica de priorización transparente para stakeholders.

Revisar resultados pasados para mejorar criterios futuros.

Identificar sesgos que afectan al diseño: confirmación, anclaje, disponibilidad, autoridad, exceso de confianza y aversión a la pérdida.

Detectar decisiones tomadas para justificar trabajo ya realizado.

Diseñar dinámicas que obliguen a considerar alternativas reales.

Usar pre-mortems para anticipar fallos antes de comprometerse.

Separar evidencia de opinión y opinión de preferencia política.

Crear espacios donde perfiles junior o minoritarios puedan cuestionar decisiones.

Evitar que el dato aparente neutralidad cuando está sesgado.

Revisar decisiones importantes con checklist de sesgos.

Incorporar diversidad de perspectivas en decisiones de alto impacto.

Crear hábitos de retrospectiva para aprender de malas decisiones sin culpabilizar.

Clasificar decisiones según impacto en personas, clientes, empleados, proveedores o ciudadanía.

Identificar decisiones sensibles: acceso, precio, elegibilidad, riesgo, selección, evaluación, seguridad o cumplimiento.

Diseñar transparencia y explicación adecuada para decisiones asistidas o automatizadas.

Aplicar principios de minimización de datos y proporcionalidad.

Evaluar riesgo de discriminación, exclusión, manipulación o daño reputacional.

Definir responsables de decisión, revisión, auditoría y reclamación.

Documentar criterios, reglas y excepciones en decisiones reguladas.

Diseñar mecanismos para corregir decisiones erróneas.

Evitar automatizaciones opacas en decisiones con impacto significativo.

Integrar ética y compliance desde el diseño, no al final del proyecto.

Diseñar experimentos para elegir entre alternativas, no solo para mejorar una métrica.

Formular hipótesis, métrica principal, métricas de control y criterio de decisión antes del experimento.

Definir población, duración, tamaño de muestra y riesgos.

Comparar prototipos, mensajes, flujos, reglas, recomendaciones o modelos.

Usar feature flags, pilotos o despliegues progresivos para aprender con menor riesgo.

Evitar experimentar con cambios simultáneos que impiden interpretar resultados.

Analizar efectos por segmento y consecuencias no deseadas.

Documentar aprendizaje y decisión tomada tras el experimento.

Desactivar experimentos que no generan aprendizaje útil.

Convertir experimentación en motor de mejora de decisiones.

Definir qué significa que una decisión fue buena: resultado, coste, tiempo, calidad, riesgo o aprendizaje.

Crear métricas de calidad de decisión: acierto, tiempo, confianza, reversibilidad, satisfacción, errores y retrabajo.

Medir antes y después de rediseñar una decisión.

Separar calidad del proceso de decisión y calidad del resultado, porque a veces una buena decisión puede tener mal resultado por azar.

Evaluar impacto en usuario, negocio, operación, soporte y tecnología.

Crear feedback loops para actualizar reglas, criterios, dashboards o interfaces.

Identificar decisiones que mejoran una métrica pero empeoran otra.

Preparar revisiones periódicas de decisiones críticas.

Construir histórico de decisiones para detectar patrones de error.

Usar medición para mejorar el sistema de decisión, no para buscar culpables.

Definir qué decisiones requieren aprobación, revisión, registro o auditoría.

Establecer niveles de decisión según impacto, riesgo, coste, reversibilidad y sensibilidad.

Crear ownership claro para decisiones de producto, arquitectura, datos, IA, procesos y negocio.

Diseñar comités ligeros solo para decisiones que lo justifican.

Evitar gobernanza excesiva que ralentiza decisiones de bajo riesgo.

Crear plantillas de decision record, matriz de criterios y mapa de decisión.

Integrar decision governance con gestión de cambios, arquitectura, seguridad y compliance.

Establecer cadencias de revisión para decisiones vivas.

Definir cómo se comunican decisiones y cómo se pueden cuestionar.

Crear un sistema organizativo donde decidir mejor sea repetible y no dependa de heroicidades individuales.

Utilizar Miro, FigJam, Lucidchart o Draw.io para mapas de decisión, matrices y flujos colaborativos.

Aplicar Confluence, Notion, SharePoint o Markdown para decision records y documentación viva.

Usar Jira, Linear, Azure Boards o Trello para conectar decisiones con iniciativas, tickets y releases.

Modelar reglas con DMN, tablas de decisión, BPMN o herramientas equivalentes.

Conectar dashboards de Power BI, Looker, Metabase, Tableau o Grafana con decisiones operativas.

Usar herramientas de feature flags y experimentación para validar alternativas.

Integrar ADRs en repositorios Git para decisiones técnicas.

Aprovechar IA generativa como apoyo para sintetizar opciones, riesgos y criterios.

Evitar dependencia excesiva de herramientas si no existe una práctica clara.

Diseñar un kit mínimo de herramientas para empezar sin crear fricción.

Diseñar pantallas antes de entender qué decisión deben facilitar.

Crear dashboards llenos de métricas que no activan ninguna acción.

Documentar decisiones después de tomarlas solo para justificar la opción elegida.

Automatizar decisiones complejas sin revisión humana ni explicación.

Confundir datos con decisión y asumir que una métrica habla por sí sola.

Elegir criterios de priorización que favorecen siempre a un área concreta.

Convertir todas las decisiones en procesos lentos y burocráticos.

Ignorar sesgos, ética y consecuencias de decisiones automatizadas.

Mantener decision records que nadie revisa ni actualiza.

Diseñar sistemas que informan mucho, pero no ayudan a actuar.

Evaluar madurez actual del equipo: cómo decide, quién decide, con qué información y cómo documenta.

Elegir un primer caso de uso con decisiones frecuentes, visibles y de impacto claro.

Crear un mapa de decisiones del proceso o producto elegido.

Seleccionar una decisión prioritaria por impacto, riesgo o frecuencia.

Rediseñar información, criterios, interfaz, proceso o automatización alrededor de esa decisión.

Definir métricas de mejora: tiempo, calidad, reducción de errores, satisfacción o coste.

Crear plantillas ligeras para mapas, matrices y registros de decisión.

Formar al equipo en sesgos, criterios, trade-offs, documentación y medición.

Revisar resultados del piloto y ajustar la práctica.

Escalar gradualmente a producto, arquitectura, procesos, datos, IA y gobernanza.

Seleccionar un caso de negocio, producto, proceso, dashboard, plataforma o sistema interno con decisiones relevantes.

Crear un mapa de actores, decisiones, información, criterios, restricciones y consecuencias.

Elegir una decisión crítica y formularla como pregunta accionable.

Diseñar alternativas, criterios ponderados, matriz de evaluación y riesgos asociados.

Modelar la decisión con tabla, árbol, DMN, flujo o decision record según corresponda.

Diseñar una interfaz, dashboard, proceso, API o recomendación que ayude a tomar esa decisión.

Incorporar datos necesarios, reglas, excepciones, permisos y puntos de control.

Definir métricas para evaluar si el rediseño mejora calidad, velocidad o consistencia de la decisión.

Preparar documentación de decisión, trade-offs, límites, gobierno y plan de revisión.

Presentar la solución final defendiendo cómo Decision Driven Design mejora el sistema frente al enfoque anterior.