Primer diamante: Descubrir y Definir

El primer diamante transforma un encargo en un problema bien planteado. Entra un brief inicial, casi siempre incompleto o formulado como solución, y sale un design brief que el equipo, los stakeholders y los usuarios reconocen como la descripción correcta del desafío.

Este capítulo trabaja ambas fases con un caso continuo: una municipalidad que quiere mejorar el trámite de permisos de construcción. El mismo caso continúa en el capítulo 09.

Brief inicial y design brief: dos documentos distintos

Aspecto	Brief inicial	Design brief
Quién lo escribe	Quien encarga el proyecto	El equipo de diseño con los stakeholders
Cuándo existe	Antes de Descubrir	Al cierre de Definir
Forma habitual	Una solución o una queja	Un problema con alcance, público y criterios de éxito
Base de evidencia	Supuestos, presión política o comercial	Investigación realizada en Descubrir
Función	Dar permiso para empezar	Servir de contrato para el segundo diamante

En el caso de la municipalidad, el brief inicial que recibió el equipo decía: “Necesitamos una plataforma digital para que la gente pida su permiso de construcción en línea, porque hay demasiadas filas en la Dirección de Obras”. Contiene una solución (plataforma digital), un síntoma (filas) y ninguna evidencia sobre las causas.

flowchart LR
    BI[Brief inicial: una plataforma para pedir permisos en línea] --> D[Descubrir]
    D --> H[Hallazgos e insights]
    H --> DEF[Definir]
    DEF --> DB[Design brief: problema, público, criterios de éxito]
    DB --> S[Segundo diamante]

Descubrir: abrir el campo con intención

Descubrir es divergente, pero no caótico. La divergencia es deliberada: el equipo decide qué fuentes consultar, con quién hablar y qué supuestos del brief inicial pondrá a prueba.

Preparación: supuestos a verificar

Antes de investigar conviene listar lo que el brief da por sentado.

Supuesto del brief inicial	Cómo verificarlo
Las filas se deben a que el trámite es presencial	Observación en la Dirección de Obras, análisis de motivos de visita
Los vecinos quieren hacer el trámite en línea	Entrevistas con solicitantes recientes
El problema está en la solicitud y no en la revisión	Mapeo del proceso completo con funcionarios
Una plataforma reduciría las visitas	Benchmarking con municipios que ya la tienen

Investigación con usuarios

Es la fuente principal del primer diamante. En el caso, los usuarios no son un grupo homogéneo: hay propietarios que construyen una vez en la vida, arquitectos y constructoras que tramitan decenas de permisos al año, y funcionarios que revisan expedientes.

Técnica	Qué aporta	Aplicación en el caso
Entrevistas en profundidad	Motivaciones, frustraciones, lenguaje propio	8 propietarios, 6 arquitectos, 4 revisores
Observación en contexto	Lo que la gente hace, no lo que dice	Dos jornadas en el mesón de atención
Safari de servicio	Vivir el trámite como usuario	Un integrante del equipo inicia una solicitud real
Diario de uso	Seguimiento de un proceso largo	Tres solicitantes registran cada contacto durante un mes
Análisis de reclamos	Patrones de fallos a escala	14 meses de reclamos de la oficina de partes

Investigación de mercado y de escritorio

Complementa la voz del usuario con datos y referencias externas: normativa vigente, estadísticas de permisos otorgados y rechazados, tiempos de tramitación, informes de contraloría, estudios de otras municipalidades y soluciones disponibles en el mercado.

Tendencias y benchmarking

El benchmarking responde qué han hecho otros y con qué resultado. En el caso, el equipo revisó tres municipios con plataforma en línea y descubrió que dos de ellos no redujeron las visitas presenciales porque los expedientes seguían siendo rechazados por documentación incompleta. Ese dato reorientó la investigación hacia las causas de rechazo.

Entrevistas con stakeholders

Los stakeholders internos tienen información y poder de veto. Entrevistarlos temprano evita sorpresas en Entregar.

Stakeholder	Interés principal	Riesgo si no se incluye
Director de Obras	Cumplir la normativa sin exponerse a sanciones	Bloqueo por riesgo legal
Alcaldía	Reducir reclamos visibles antes del próximo período	Presión por una solución rápida y vistosa
Jefatura de informática	Mantener lo que se construya	Rechazo técnico tardío
Oficina de partes	Trazabilidad de los ingresos	Duplicidad de registros
Colegio de arquitectos local	Previsibilidad de criterios de revisión	Desconfianza y mala prensa

Organizar lo descubierto

La divergencia produce volumen: notas, grabaciones, fotos, cifras. Conviene registrarlo en un formato uniforme desde el primer día. Una plantilla mínima por hallazgo:

Campo	Contenido
Fuente	Entrevista, observación, dato, documento
Cita o evidencia	Textual, sin interpretar
Observación del equipo	Qué llamó la atención
Tema preliminar	Etiqueta provisoria para agrupar después

Definir: convergir hacia el problema correcto

Definir toma el material de Descubrir y lo reduce a una decisión: qué problema vamos a resolver y qué dejaremos fuera.

flowchart TD
    H[Hallazgos crudos] --> C[Clustering por temas]
    C --> I[Insights]
    I --> MO[Mapa de oportunidades]
    MO --> CR[Criterios de decisión]
    CR --> EP[Enunciado del problema]
    EP --> AL[Alcance y restricciones]
    AL --> DB[Design brief]

Síntesis y clustering

El equipo agrupa los hallazgos por afinidad hasta que emergen temas. En el caso, los más de 200 hallazgos se agruparon en seis temas:

1. Los solicitantes no saben qué documentos necesitan hasta que son rechazados.
2. Los criterios de revisión varían según el revisor.
3. Las visitas presenciales sirven sobre todo para preguntar por el estado del expediente.
4. Los arquitectos frecuentes ya tienen flujos propios y rechazan cualquier formulario nuevo.
5. La normativa cambió dos veces en tres años y los instructivos no se actualizaron.
6. El personal de mesón absorbe consultas que corresponderían a los revisores.

De tema a insight

Un tema describe; un insight explica y abre una oportunidad. Una forma útil de redactarlo: observación + porque + consecuencia.

Tema	Insight
Documentos desconocidos	Los solicitantes llegan incompletos porque la lista de requisitos depende del tipo de obra y nadie la traduce a su caso; el resultado es un 62 por ciento de rechazos en primera revisión.
Visitas para consultar estado	Las filas se forman porque no existe otra forma de saber en qué etapa está el expediente; digitalizar la solicitud sin informar el estado no reduciría las visitas.

Mapa de oportunidades

Cada insight se reformula como una pregunta abierta del tipo “¿cómo podríamos…?” y se ubica en un mapa según impacto esperado y esfuerzo estimado.

quadrantChart
    title Oportunidades del trámite de permisos
    x-axis Bajo esfuerzo --> Alto esfuerzo
    y-axis Bajo impacto --> Alto impacto
    quadrant-1 Candidatas principales
    quadrant-2 Victorias rápidas
    quadrant-3 Descartar por ahora
    quadrant-4 Evaluar con cuidado
    Lista de requisitos por tipo de obra: [0.25, 0.85]
    Consulta de estado del expediente: [0.35, 0.80]
    Unificar criterios de revision: [0.75, 0.90]
    Plataforma completa en linea: [0.90, 0.55]
    Capacitar al meson: [0.20, 0.35]

Criterios de decisión

Para converger sin arbitrariedad, el equipo acuerda criterios antes de elegir. Ejemplo del caso:

Criterio	Peso	Pregunta
Impacto en rechazos	30 por ciento	¿Reduce los rechazos en primera revisión?
Impacto en visitas	25 por ciento	¿Elimina motivos de visita presencial?
Viabilidad normativa	20 por ciento	¿Puede hacerse sin cambiar ordenanzas?
Capacidad interna	15 por ciento	¿Informática puede sostenerlo?
Tiempo a primer resultado	10 por ciento	¿Muestra resultados en menos de seis meses?

Enunciado del problema

El enunciado debe ser específico, centrado en personas y libre de soluciones. Una estructura probada:

[Público] necesita [necesidad] porque [insight]. Hoy [situación actual], lo que provoca [consecuencia].

Aplicada al caso:

Las personas que solicitan un permiso de construcción por primera vez necesitan saber con certeza qué documentos presentar y en qué estado está su expediente, porque la lista de requisitos depende del tipo de obra y no existe un canal para consultar avances. Hoy descubren los requisitos al ser rechazadas y visitan la Dirección de Obras solo para preguntar, lo que genera un 62 por ciento de rechazos iniciales y filas diarias.

Nótese que la plataforma en línea desapareció del enunciado. Podrá ser parte de la solución, pero ya no es el problema.

Alcance y restricciones

Definir también dice qué queda fuera. En el caso, el equipo dejó fuera a los arquitectos frecuentes para una segunda etapa y declaró como restricción que no se modificarían ordenanzas durante el proyecto.

Cómo escribir un design brief

El design brief es la salida formal del primer diamante y el contrato de entrada al segundo. Plantilla:

Sección	Contenido	Ejemplo del caso
Contexto	Por qué existe el proyecto y qué se descubrió	Investigación con 18 personas, 14 meses de reclamos, benchmarking de 3 municipios
Problema	El enunciado acordado	El redactado en la sección anterior
Objetivos	Qué cambio se busca, en términos de resultado	Reducir rechazos iniciales y visitas presenciales de consulta
Público	Para quién se diseña y para quién no, por ahora	Solicitantes primerizos; arquitectos frecuentes en etapa 2
Criterios de éxito	Cómo se sabrá que funcionó	Rechazos iniciales bajo 30 por ciento; visitas de consulta reducidas a la mitad en 6 meses
Restricciones	Límites normativos, técnicos, presupuestarios y de plazo	Sin cambio de ordenanzas; sistemas actuales de informática; presupuesto anual vigente
Entregables	Qué se espera del segundo diamante	Conceptos evaluados, prototipo probado, plan de piloto
Riesgos conocidos	Lo que podría frustrar el proyecto	Variación de criterios entre revisores; resistencia del mesón

El brief se firma con los stakeholders entrevistados. Esa firma no es burocracia: es el momento en que la organización acepta que el problema es ese y no la solución que pidió originalmente.

Errores frecuentes en el primer diamante

Error	Síntoma	Corrección
Investigar para confirmar el brief	Solo se entrevista a quienes apoyan la solución inicial	Listar supuestos y buscar evidencia en contra
Descubrir sin cierre	Semanas de entrevistas sin síntesis	Fijar fecha de cierre y sesión de clustering desde el inicio
Enunciado con solución incrustada	”Necesitamos una app que…”	Reescribir en términos de necesidad y consecuencia
Saltarse a los stakeholders internos	Veto en Entregar	Entrevistar y firmar el brief con ellos
Convergir por jerarquía	Se elige la oportunidad preferida por el jefe	Criterios ponderados acordados antes de decidir

Ejercicio práctico

Trabaja con el caso de la municipalidad o con un trámite de tu propia organización.

1. Toma el brief inicial y separa en tres columnas: solución propuesta, síntoma observado y supuestos implícitos.
2. Diseña un plan de Descubrir de dos semanas: define qué técnicas usarás, con cuántas personas y qué supuesto verifica cada actividad.
3. Redacta una guía de entrevista de ocho preguntas abiertas para solicitantes primerizos. Ninguna debe mencionar tecnología.
4. Simula veinte hallazgos plausibles y agrúpalos en temas. Convierte al menos tres temas en insights con la estructura observación, porque, consecuencia.
5. Construye un mapa de oportunidades en Mermaid quadrantChart con cinco oportunidades.
6. Acuerda cinco criterios de decisión con pesos y aplícalos a las oportunidades.
7. Escribe el enunciado del problema y el design brief completo usando la plantilla del capítulo. Indica explícitamente qué queda fuera de alcance.

Autoevaluación

1. ¿Cuál es la diferencia principal entre el brief inicial y el design brief?

• A. El brief inicial lo escribe el equipo de diseño y el design brief lo escribe quien encarga.
• B. El brief inicial suele traer una solución o un síntoma; el design brief describe un problema con público, criterios de éxito y alcance basado en evidencia.
• C. Son el mismo documento en dos momentos del proyecto.
• D. El design brief contiene la solución final y el brief inicial solo el presupuesto.

2. ¿Qué descubrió el benchmarking en el caso de la municipalidad?

• A. Que ninguna municipalidad tenía plataforma en línea.
• B. Que las plataformas reducían los rechazos a cero.
• C. Que los solicitantes preferían el trámite presencial.
• D. Que dos municipios con plataforma no redujeron las visitas porque los expedientes seguían siendo rechazados por documentación incompleta.

3. ¿Qué estructura se recomienda para redactar un insight?

• A. Observación, porque, consecuencia.
• B. Problema, solución, beneficio.
• C. Usuario, tecnología, costo.
• D. Objetivo, método, resultado.

4. ¿Por qué deben acordarse los criterios de decisión antes de elegir una oportunidad?

• A. Porque lo exige la normativa de compras públicas.
• B. Porque permite elegir la oportunidad que prefiere la jefatura.
• C. Para converger con reglas explícitas y evitar que la decisión dependa de la jerarquía o de la preferencia del momento.
• D. Porque los criterios reemplazan la investigación con usuarios.

Respuestas

1. B. El design brief es la salida de Definir y se basa en lo descubierto; el brief inicial es el punto de partida, normalmente sin evidencia.
2. D. Ese hallazgo reorientó la investigación hacia las causas de rechazo.
3. A. Un insight explica y abre una oportunidad; esa estructura obliga a incluir la causa y el efecto.
4. C. Los criterios ponderados hacen la convergencia defendible y transparente.

Checklist

• Separé solución, síntoma y supuestos del brief inicial antes de investigar.
• Mi plan de Descubrir combina usuarios, stakeholders, datos y benchmarking.
• Registré los hallazgos con una plantilla uniforme desde el primer día.
• Convertí temas en insights con causa y consecuencia.
• Acordé criterios de decisión con pesos antes de elegir la oportunidad.
• El design brief tiene problema, público, criterios de éxito, restricciones y alcance, y está firmado por los stakeholders.