Referencia Paper — MERIDIANA

Mapa del canvas (CRON §5.2)

Media real

assets/clinic/hero.jpg + assets/doctors/*.jpg vía paper-asset://

01 — Definición de producto — MERIDIANA

5.1 Identidad

5.2 Problema

Problema principal

Las personas del barrio no encuentran horarios, especialidades y forma de pedir cita de forma clara; el teléfono satura recepción y se pierden solicitudes.

Problemas secundarios

• Información desactualizada en carteles o redes.
• Desconocimiento del equipo médico (confianza).
• Dificultad para elegir motivo de consulta (orientación).
• Recepción sin cola digital de peticiones.

Quién lo experimenta

Pacientes y cuidadoras; recepción administrativa; médicos de familia (indirecto: menos llamadas mal encaminadas).

Cómo se resuelve hoy (suposición de mercado, no estudio de campo propio)

Teléfono en horario limitado, WhatsApp informal, desplazamiento al mostrador.

Deficiencias

Horario de llamada estrecho, sin rastro escrito de la petición, fricción para personas con poca disponibilidad laboral diurna.

Coste (hipótesis)

Horas de recepción en llamadas no resueltas; pacientes que posponen cuidados no urgentes; mala experiencia percibida del centro.

Oportunidad

Web de confianza + formulario de solicitud + bandeja para recepción = vertical slice útil sin EHR completo.

Tipos de afirmación

5.3 Objetivos

5.4 Métricas

Supuestos de diseño documentados

1. El centro confirma la cita por teléfono o SMS fuera de producto v1.
2. El motivo de consulta es texto libre no estructurado (no codificación CIE).
3. Un solo centro (no multi-tenant).

02 — Investigación UX y estrategia — MERIDIANA

Nota metodológica: No hay estudio de campo propio en esta ejecución. Personas, JTBD y journeys son artefactos de diseño basados en patrones conocidos de AP y decisiones del case, no en entrevistas reales.

Stakeholders

Personas (4)

P1 — Elena, 42, cuidadora y trabajadora

• Rol: Paciente/cuidadora que gestiona citas de su madre y las suyas.
• Digital: Media-alta (móvil).
• Motivaciones: Resolver sin perder la mañana al teléfono.
• Frustraciones: “Me ponen en espera y cuelgo en el trabajo.”
• Dispositivos: iPhone, a veces portátil por la noche.
• A11y: Ninguna severa; prefiere textos grandes.
• Cita: “Solo quiero dejar la petición y que me llamen.”
• Escenario: Solicita revisión de tensión para su madre un martes a las 22:10.

P2 — Don Antonio, 71, paciente crónico

• Digital: Baja; le ayuda un hijo a veces.
• Motivaciones: Confiar en “su” médico de siempre.
• Frustraciones: Webs con jerga y botones pequeños.
• A11y: Baja visión leve; necesita contraste y tipografía legible.
• Cita: “Que se entienda, como el folleto del centro.”
• Escenario: Mira el equipo y pide a su hijo que envíe la solicitud.

P3 — Laura, 28, recepción

• Digital: Alta.
• Motivaciones: Menos llamadas de “¿a qué hora abrís?”.
• Frustraciones: Notas en papeles y WhatsApps perdidos.
• Escenario: Por la mañana tria solicitudes NEW y llama para confirmar hueco.

P4 — Dr. Martín, 55, médico de familia

• Motivaciones: Pacientes con motivo claro; menos interrupciones.
• Frustraciones: Citas mal tipificadas.
• Uso del producto: Indirecto (beneficiario del filtrado).

JTBD

1. Funcional: Cuando necesito una cita no urgente, quiero enviar una solicitud con mis datos y motivo, para que recepción me contacte sin colas telefónicas.
2. Emocional: Cuando estoy preocupado por un familiar, quiero sentir que el centro es cercano y ordenado, para reducir ansiedad.
3. Social: Cuando cuido de mis padres, quiero demostrar que gestiono bien su salud, para coordinarme con hermanos.

Barreras: Miedo a “no me harán caso”; duda de si es cita confirmada; barreras de alfabetización digital.

User stories (épicas)

E1 — Información del centro (Must)

• Como visitante, quiero ver horarios y ubicación, para decidir si el centro me sirve.
• Como visitante, quiero ver servicios, para orientarme.
• AC: Home muestra horario, dirección, CTA “Solicitar cita”; servicios listados con descripción breve.

E2 — Equipo (Must)

• Como paciente, quiero ver fotos y roles del equipo, para generar confianza.
• AC: Al menos 4 profesionales seed; foto real; especialidad.

E3 — Solicitud de cita (Must)

• Como paciente/cuidador, quiero enviar nombre, teléfono, email opcional, preferencia de franja y motivo, para ser contactado.
• AC: Validación de teléfono ES; motivo 10–500 chars; mensaje de que no es confirmación inmediata; estados error red y validación.

E4 — Recepción (Must L1 mínimo)

• Como recepción, quiero listar solicitudes y marcar CONTACTED/CLOSED, para no perder peticiones.
• AC: Listado ordenado por fecha; cambio de estado; sin auth compleja en v1 (documentado riesgo; endurecer L2).

Should / Could / Won’t

Journey — Elena solicita cita para su madre

Service blueprint (simplificado)

03 — Arquitectura de información — MERIDIANA

Mapa del sitio

/                     Home
/servicios            Listado de servicios
/equipo               Profesionales
/cita                 Solicitar cita
/cita/enviada         Confirmación
/contacto             Horario, dirección, teléfono (o ancla en home)
/recepcion            Bandeja solicitudes (interno L1)

Navegación

• Principal: Inicio · Servicios · Equipo · Solicitar cita (CTA)
• Secundaria footer: Privacidad (resumen), Contacto
• Contextual: Desde tarjeta de servicio → CTA cita con motivo prefill (nice-to-have; v1 link genérico)

Inventario de contenido

Matriz de permisos L1

* En v1 la ruta /recepcion es accesible sin auth (riesgo aceptado y documentado; L2 = PIN/JWT staff).

04 — Flujos de usuario — MERIDIANA

F1 — Solicitar cita (principal)

1. Entrada: CTA global o desde Servicios/Equipo.
2. Usuario completa: nombre completo, teléfono, email (opc.), franja preferida (mañana/tarde), profesional preferido (opc. “cualquiera”), motivo.
3. Cliente valida; POST /api/appointments.
4. Éxito → /cita/enviada con referencia id corta.
5. Error red → pantalla/mensaje con reintento.
6. Error validación → inline.

Eventos analíticos (plan): cita_form_view, cita_submit_attempt, cita_submit_success, cita_submit_error.

F2 — Explorar equipo

Home/nav → Equipo → detalle implícito en cards (sin página individual L1).

F3 — Recepción

Abre /recepcion → lista NEW/CONTACTED/CLOSED → cambia estado.

Estados de producto

05 — Modelo de datos — MERIDIANA

Entidades

Service

• id, slug, name, summary, description, iconKey, sortOrder, active, createdAt, updatedAt

Doctor

• id, slug, fullName, roleTitle, bio, photoUrl, acceptsAppointments, sortOrder, active, createdAt, updatedAt

AppointmentRequest

• id, patientName, phone, email?, preferredSlot (MORNING|AFTERNOON|ANY), preferredDoctorId?, serviceId?, reason, status (NEW|CONTACTED|CLOSED), receptionNotes?, createdAt, updatedAt

Relaciones

• Doctor 1—N AppointmentRequest (preferred, opcional)
• Service 1—N AppointmentRequest (opcional)

Privacidad

• Motivo y datos de contacto = datos personales (y potencialmente de salud). Minimizar retención; acceso recepción solo. Ver 11-privacy-security.md.

ER simplificado

Service ||--o{ AppointmentRequest
Doctor  ||--o{ AppointmentRequest

06 — Stack tecnológico — MERIDIANA

No se elige otro stack pese a la frase genérica del brief de “no siempre el mismo stack”: en este monorepo manda CRON.md / memory.md.

07 — Dirección creativa — MERIDIANA

Concepto

“Calma clínica de barrio” — luz de mañana, materiales cálidos, nada de hospital frío ni tech startup neón.

Mood

• Madera clara, lino, cerámica, plantas, bata limpia sin frialdad.
• Fotografía real de profesionales y sala de espera luminosa.

Diferenciación vs recientes

Tipografía

• Display: Fraunces ya usado — NO. Usar Literata (serif humanista lectura).
• UI: Plus Jakarta Sans (no Karla, no IBM Plex).

Paleta

08 — Design system — MERIDIANA

Tokens (CSS vars)

Ver Paper artboard 00 Design System y tailwind.config de la app.

Componentes

• Button primary / secondary / ghost
• Input, Textarea, Select
• Card service, Card doctor
• Badge estado (NEW / CONTACTED / CLOSED)
• Alert error / success / info
• Nav + footer
• Skeleton

Spacing

Base 4; escala 8/12/16/24/32/48/64.

Radius

md 8px, lg 12px, full pills.

Motion

150–200ms ease-out en hover; sin motion esencial para a11y (prefers-reduced-motion).

09 — Guía de contenido — MERIDIANA

Tono

Cercano, claro, adulto, sin infantilizar ni medicalizar en exceso. Tú de usted solo en legales.

Microcopy crítico

• CTA: “Solicitar cita” (no “Reservar” ni “Confirmar hora”).
• Éxito: “Hemos recibido tu solicitud. El equipo de recepción te contactará para confirmar la hora.”
• Error: “No hemos podido enviar la solicitud. Comprueba la conexión e inténtalo de nuevo.”

Evitar

Jerga (HIS, CIE, “slot”); promesas de cita inmediata; stock photos de hospitales fríos.

10 — Accesibilidad — MERIDIANA

Objetivo: WCAG 2.2 AA.

• Contraste texto ink sobre cream ≥ 4.5:1.
• Focus visible en CTAs y campos.
• Labels explícitos en formulario (no solo placeholder).
• Orden de foco lógico; skip link a contenido.
• Imágenes de equipo con alt descriptivo (nombre + rol).
• Errores asociados con aria-describedby.
• Tamaño táctil ≥ 44px en mobile.

11 — Privacidad y seguridad — MERIDIANA

Datos

Solicitud incluye datos identificativos y motivo de consulta (posible dato de salud). Base legal típica: interés legítimo/ejecución de medidas precontractuales de asistencia — no es dictamen legal.

Medidas L1

• HTTPS en producción.
• Validación servidor.
• No logs de motivo en plain en cliente.
• .env no commiteado.
• Recepción sin auth = deuda de seguridad explícita para L2 (JWT staff o VPN).

Retención (propuesta)

Solicitudes CLOSED > 24 meses: borrado o anonimización (proceso operativo).

No afirmamos

Cumplimiento RGPD “certificado” ni ENS.

12 — Analítica — MERIDIANA

Sin PII en analytics. Consent banner L2 si se usa third-party.

13 — Plan de pruebas — MERIDIANA

Casos

1. Home carga servicios y CTAs.
2. Formulario rechaza teléfono inválido.
3. Submit OK crea fila NEW en API.
4. Confirmación muestra mensaje no-inmediato.
5. API caída → UI error + reintento.
6. Recepción lista y cambia estado.
7. A11y smoke: labels y focus en form.
8. Mobile 390px: nav y form usables.

14 — Handoff desarrollo — MERIDIANA

Repos

• Case: ux-projects/2026-08-02-meridiana
• App: meridiana-app (Angular web + Nest api)

API

Tokens

Mapear CSS vars Paper → Tailwind theme.

Assets

assets/doctors/* y hero clínica.

15 — Roadmap — MERIDIANA

16 — Interacciones — MERIDIANA

• CTA sticky mobile “Solicitar cita”.
• Form: disable submit mientras loading; toast no sustituye confirmación de página.
• Recepción: confirmación no necesaria al pasar a CONTACTED; confirm al CLOSED opcional.
• Hover cards elevación sutil 2px; reduced-motion: sin translate.

17 — Mapa de prototipo

El prototipo interactivo es la app Angular, no Paper (limitación MCP documentada en memory).

Flujo demo: Home → Equipo → Cita → Enviada → Recepción.

18 — Auditoría de completitud — MERIDIANA

Fecha: 2026-08-02 | Nivel: 1 | Barra calidad: completa (CRON §6.1)

§29 checklist

• Distinto de COMAL/ATRIO: sí (salud L1, teal/cream, Literata/Jakarta)
• Problema concreto: sí
• Alcance L1: sí (sin HCE)
• Flujos + estados: sí
• Contenido realista: sí
• Identidad propia: sí
• Componentes reutilizables: sí
• Responsive diseñado: sí
• AA objetivo documentado: sí
• Modelo datos soporta use cases: sí
• Stack justificado (cron fijo): sí
• Privacidad riesgos: sí (recepción sin auth)
• Métricas: sí
• Handoff: sí
• Paper hi-fi real: sí

19 — Backlog

Must (v1) — hechos en implementación

• Home, servicios, equipo
• Formulario cita + confirmación
• Estados error/validación/empty
• API + Neon + seed
• Bandeja recepción

Should

• Mapa embebido
• Prefill motivo desde servicio

Could

• Multi-idioma
• SMS confirmación

Won’t now

• HCE / teleconsulta

20 — Implementación

Ver README del case y meridiana-app/README.md.

Neon project: old-glitter-65201301. Stack: Angular + Nest + Prisma + Neon + Tailwind.