7.8 KiB

Raw Blame History

Brief de diseño para Nexo (dating demo)

Este documento es el input que paso a un diseñador IA (Claude Design u otra). Tiene tres trabajos: contar de qué va el producto, fijar las restricciones técnicas reales, y entregar la lista exacta de pantallas a diseñar para que la implementación posterior sea mecánica.

1. Producto en una frase

Nexo es una app demo de dating moderna y privacy-first. La uso para validar un ecosistema de runtime propio (Active framework). El diseño tiene que ser producto-grade, no slide deck. Si una pantalla parece un dashboard de devtools, no sirve.

2. Tono visual

Confianza, calma, claridad. Nada de marketing aspiracional.
Femenino-neutro suave; nada de iconografía estridente o emoji decorativos.
Mobile-first. El 80% de la interacción ocurre con un pulgar.
El componente más visto es la ProfileCard (Discover); el resto son superficies de soporte. Si la card no se siente magnética, todo lo demás da igual.
El segundo más visto es el chat. Tiene que sentirse como iMessage/Telegram, no como un panel de admin.
Modo oscuro tiene paridad — no es un afterthought.

3. Brand actual (referencia, no es ley)

Hay un acento rosa-frambuesa actualmente: #c44a78. Está bien como ancla pero el diseño puede mover la paleta. Lo que NO se puede mover:

El acento debe sobrevivir contraste WCAG AA sobre fondos de tema claro y oscuro.
La marca Nexo es palabra; no hay logo gráfico fijo. Wordmark sin decoración, optical-kerned, peso 600/700.

4. Stack y restricciones técnicas

SvelteKit 2 + Svelte 5 (runes). Estilos <style> por componente; :global() permitido cuando hace falta cruzar slots.
Sin Tailwind. CSS plano + color-mix(in srgb, …) y oklch(...) están disponibles.
Variables CSS en :root para los tokens (color, radio, sombra, espaciado). Nada de "design tokens" en JSON aparte por ahora.
Iconografía: SVG inline o un set por código (Lucide/Phosphor son aceptables si lo hacéis con <svg> directo, no librería runtime).
Tipografía: system stack por defecto (system-ui, -apple-system, ...). Si proponéis Inter o similar, dadme también la versión local variable WOFF2 + el bloque @font-face exacto.
Animaciones cortas (≤ 200 ms), respetando prefers-reduced-motion.

5. Lo que YA existe en código (no rediseñar desde cero)

Las rutas ya están cableadas con su lógica real (auth, redirect guards, fetch al servidor servers/dating, WebSocket realtime para chat, etc.). El diseño tiene que respetar esos contratos:

/dating → router puro a login/onboarding/discover.
/dating/login — email + password, footer con link a register/reset.
/dating/register — email, password con strength meter, confirmación adulta, aceptación de reglas.
/dating/reset — email, anti-enumeration (mismo mensaje haya o no cuenta).
/dating/onboarding — 4 pasos (Identidad → Sobre ti → Preferencias → Revisar). Stepper visible.
/dating/discover — feed de profiles con filtros (intent + min/max age). Like / Pass como acción central. Modal "¡Es match!" cuando procede.
/dating/matches — lista. Cada fila lleva avatar, nombre, timestamp relativo, snippet, badge de no-leído.
/dating/chat/[matchId] — header con counterpart, timeline de mensajes (mine vs theirs), composer fijo abajo. Burbujas con estado (sent / queued / failed + retry).
/dating/profile — editor de perfil + link al photo manager.
/dating/profile/photos — drop-zone, grid 3-col, primary badge, reorder, delete.
/dating/safety — bloqueo, reporte (pendiente de UI real).
/dating/admin — moderación (operator-style; aquí SÍ se ve la barra superior).
/dating/devtools — inspector de servicios (operator-style).

Componentes ya existentes que se pueden mejorar pero no eliminar: AuthLayout, Field, ProfileCard, AppNav, MessageToast.

6. Cómo quiero el entregable

Por cada pantalla quiero, en este orden:

Mockup visual (clean static, no Figma) en HTML/CSS standalone o en un .svelte aislado dentro de src/web/routes/dating/_design/. Tema claro y oscuro.
Tokens que la pantalla usa, con sus valores concretos (variables CSS).
Estados: idle, loading, empty, error, disabled, pressed, focus visible.
Responsive: 360 (móvil mínimo), 768 (tablet), 1024+ (desktop).
Notas breves de interacción: qué hace tap/hover, qué transiciones.

NO quiero:

Lorem ipsum. Usad copy real (puede ser placeholder pero tiene que encajar con el dominio dating).
Capturas tipo "design system marketing site". Esto es producto.
Componentes nuevos sin un sitio de uso. Si el set de tokens resultante no se aplica en al menos dos pantallas, sobra.

7. Pantallas prioritarias (en orden)

Discover — la card central, los botones like/pass, los filtros en sidebar/drawer, los estados empty/loading/match.
Chat — header, burbujas (mine, theirs, queued, failed), composer, typing indicator (placeholder: aún no hay realtime de typing pero el slot tiene que existir).
Onboarding — los 4 pasos con stepper, error inline, summary final.
Login + Register + Reset — un único sistema de auth-card reutilizable.
Matches — fila + badge + estados (vacío, con pendientes).
Profile + Photos — editor + drop-zone + grid + primary selector.
AppNav — bottom-tab móvil + sidebar desktop. Iconos consistentes con el resto.
MessageToast — flotante, branded, no se come la vista del bottom-tab.

Las pantallas de operador (admin, devtools) van después; usarán el header existente.

8. Sistema de tokens que espero

Mínimo:

:root {
	--nx-bg: ...;            /* surface base */
	--nx-bg-elevated: ...;   /* cards */
	--nx-fg: ...;            /* text */
	--nx-fg-muted: ...;      /* labels, captions */
	--nx-accent: ...;        /* brand action */
	--nx-accent-fg: ...;     /* foreground over accent */
	--nx-success: ...;
	--nx-warning: ...;
	--nx-danger: ...;
	--nx-border: ...;
	--nx-border-strong: ...;
	--nx-shadow-sm: ...;
	--nx-shadow-md: ...;
	--nx-radius-sm: 6px;
	--nx-radius-md: 10px;
	--nx-radius-lg: 14px;
	--nx-radius-pill: 999px;
	--nx-space-1: 0.25rem;
	--nx-space-2: 0.5rem;
	--nx-space-3: 0.75rem;
	--nx-space-4: 1rem;
	--nx-space-6: 1.5rem;
	--nx-space-8: 2rem;
	--nx-step-curve: cubic-bezier(0.2, 0.8, 0.2, 1);
}
@media (prefers-color-scheme: dark) { :root { ... } }

El cliente debe poder hacer data-theme="dark" o [data-theme="light"] en <html> para forzar el modo, y el sistema de prefs (existente) ya escribe ese atributo.

9. Accesibilidad mínima

Contraste AA en TODOS los textos sobre TODOS los fondos.
Focus visible siempre, no outline: none salvo si hay equivalente custom.
Botones con label aria cuando solo llevan icono.
Diálogos con focus trap (no es responsabilidad del diseño visual, pero el mockup tiene que asumir que existe el trap).
No comunicar estado solo por color (badges con texto + color).

10. Lo que devuelvo después

Cuando me devolváis el set, yo lo implemento sustituyendo:

los <style> por componente con los tokens y los layouts del mockup;
los componentes compartidos (AuthLayout, Field, ProfileCard, AppNav, MessageToast) con la versión nueva;
el :root global (probablemente en src/web/routes/dating/_design/tokens.css y un @import en el layout).

No tocaré:

la lógica de fetch/realtime/redirects;
la API client;
el contrato de tipos en _lib/types.ts.

11. Pista final

La app debería sentirse como Hinge en su mejor día: editorial, suave, con tipografía cuidada y un acento de color que respira; pero sin la pesadez visual. Si una pantalla no es algo que un usuario real querría enseñar a un amigo, falta trabajo.

7.8 KiB Raw Blame History