Portfolio Personal

La mayoría de portfolios de Product Designer fallan de dos formas: demasiadas pantallas sin razonamiento, o demasiado razonamiento sin ejecución visible. Este sitio resuelve esa tensión siendo las dos cosas a la vez — el caso de estudio y el artefacto estudiado.

Es el mismo proceso que aplico en producto — definir principios, construir un sistema, auditar con criterio — aplicado al artefacto con el que me presento. Cada decisión de sistema fue tomada pensando en quien revisa: que pueda entender el razonamiento sin necesitar contexto previo, y verificar la ejecución sin pedirme que se las explique.

El Desafío

Quien revisa este portfolio — reclutador, lead de producto, par técnico — tiene un trabajo concreto: decidir en pocos minutos si el perfil Product Designer + Developer es real o superficial en alguna de las dos dimensiones. Sin haber trabajado junto a la persona. Sin contexto del equipo ni del proceso interno.

Los portfolios genéricos no resuelven eso: obligan al lector a hacer un leap of faith — confiar en que las capacidades existen porque alguien lo dice, no porque pueda verificarlo. Este portfolio apuesta a eliminar ese leap of faith dando evidencia directa en el mismo artefacto.

El problema estructural era que soy el Product Designer y el Frontend Developer del mismo producto. Sin equipo que valide las decisiones de color ni desarrollador que cuestione la implementación, la única garantía de coherencia es el sistema — no la revisión. Cada decisión visual tiene que sostenerse técnicamente y cada decisión técnica tiene que sentirse bien como usuario.

El portfolio no podía ser un escaparate. Tenía que ser la evidencia del proceso.

La apuesta

Antes de construir, tres hipótesis guiaron las decisiones:

H1 — Credibilidad por coherencia: un portfolio construido con las mismas prácticas que un producto real (tokens semánticos, auditoría de sistema, documentación de decisiones) genera más confianza que uno que solo habla de esas prácticas. El lector puede verificar si la ejecución coincide con el discurso.

H2 — Razonamiento visible: mostrar el porqué de cada decisión — no solo el resultado — permite al lector evaluar el proceso sin haber estado en el proyecto. Los casos de estudio como evidencia de pensamiento, no como galería de outputs.

H3 — Calidad técnica como señal: un portfolio que carga rápido, tiene contraste correcto y funciona en cualquier dispositivo no erosiona la credibilidad antes de que el lector llegue al contenido. La fricción técnica es el primer filtro que el lector aplica, conscientemente o no.

El Enfoque

La estrategia tuvo tres ejes: una identidad visual que comunique el tono del diseñador desde los primeros segundos, un sistema técnico que no requiera intervención manual para escalar, y accesibilidad integrada desde la base para no producir fricción a ningún lector.

Identidad y dirección visual

El lector necesita calibrar el tono del diseñador antes de leer una línea de texto. Para eso, cada elemento visual tiene que comunicar con intención — no con decoración. Tres palabras como filtro de decisión: moderno, accesible, limpio. Cada vez que una decisión visual parecía dudosa, pasaba por ese filtro antes de continuar.

La paleta parte de un azul-gris frío (#2a4057 como primary). Oscuro suficiente para funcionar como texto sobre fondo claro y como acento sin ser estridente. Los tonos desaturados comunican seriedad técnica sin rigidez corporativa. El acento terracota (#c4704a) aparece con intención: marcadores de énfasis, borde de blockquote en casos de estudio, nunca como color decorativo.

Para tipografía la decisión fue un sistema de dos familias con roles separados: Plus Jakarta Sans (--font-sans) para UI y cuerpo — geométrica, legible en tamaños medianos, pesos 300–800 para cubrir toda la jerarquía de interfaz — y Sora (--font-display) para titulares — más expresiva en escalas grandes, tracking negativo, pesos 400–800. La regla es simple: font-sans por defecto en todo, font-display solo en H1–H4, títulos de cards y secciones de impacto. Sin excepciones. Esto garantiza coherencia aunque los componentes se escriban en momentos distintos.

El modo claro y oscuro responde a prefers-color-scheme automáticamente. No hay toggle manual — respeta la preferencia del sistema sin añadir fricción.

Design system propio

Para que H1 funcione — credibilidad por coherencia — el sistema tiene que poder auditarse, no solo describirse. Eso requiere que las reglas sean explícitas y verificables en código.

Los tokens semánticos son la fuente de verdad. Variables CSS en globals.css, expuestas a Tailwind vía tailwind.config.ts. Un token tiene un valor en claro y otro en oscuro — el cambio de tema no toca componentes. El sistema cubre fondos, texto, bordes, navegación, estados y componentes. Cada token tiene nombre de propósito, no de valor (text-primary, no text-slate-800).

Cómo se nombran los tokens

Hay dos capas que conviven: la paleta primitiva (--gray-*, --primary-*, --accent-warm, etc.) define valores reutilizables; los tokens semánticos (--text-primary, --bg-tertiary, --border-subtle) dicen para qué sirve el color en la interfaz, no qué hex es. En Tailwind, esas variables se agrupan por familia y se consumen como utilidades: prefijo de rol + nombre del token, por ejemplo text-text-primary (texto principal), bg-bg-secondary (superficie secundaria), border-border-focus (borde de foco).

La convención sigue prefijos por intención, no por pantalla:

• Superficie y texto: familias bg y text — bg-bg-tertiary, text-text-secondary, text-text-link / hover text-text-link-hover.
• Contorno: familia border — border-border-subtle, border-border-strong.
• Estados de mensaje: familia state — bg-state-info-bg, text-state-error-text, etc.
• Piezas de UI concretas: familias acotadas — nav (bg-nav-active-bg), badge (bg-badge-neutral-bg), btn, card, input.

El mismo nombre de variable CSS se mantiene al cambiar el tema: en :root y en [data-theme="dark"] solo cambian los valores asignados a --text-primary, --bg-primary, etc.; los componentes no renombran clases cuando pasa el modo oscuro.

Lo que el sistema evita es mezclar valor bruto con rol: usar en componentes algo como text-slate-800 o bg-zinc-100 rompe la auditoría, porque el nombre no dice si es texto principal, secundario o inverso. El propósito tiene que leerse en el identificador.

El contenido largo — casos de estudio en Markdown — presentaba un problema de ritmo: con múltiples archivos de estructura distinta, definir márgenes entre headings, párrafos y listas manualmente genera inconsistencia inevitable. La decisión fue usar @tailwindcss/typography como capa base del ritmo vertical. Con eso resuelto a nivel de plugin, los overrides en CSS cubren solo lo específico de marca: tipografía display en H2/H3 de casos, color de viñetas vía token, borde de blockquote en acento terracota.

Las cards de proyectos tenían un problema diferente: la tipografía era condicional según el tamaño del layout Bento, lo que producía títulos de distinto tamaño entre la home y el listado completo. La solución fue constantes de clase compartidas (PROJECT_CARD_TITLE_CLASS, PROJECT_CARD_DESCRIPTION_CLASS) que aplican la misma escala tipográfica en todas las cards, independientemente del layout. El trade-off es concreto: la card grande cede el salto hasta text-5xl en desktop; a cambio, cualquier card nueva hereda el estándar sin intervención.

Antes de considerar el sistema terminado, hice una auditoría de tokens. Encontré tokens de texto usados como fondo (bg-text-inverse donde correspondía bg-bg-inverse), colores hardcodeados (bg-black/70) y problemas de contraste en navegación activa. Un sistema bien documentado hace visible esa deuda técnica; no la oculta.

Arquitectura de contenido

Cada proyecto es un archivo Markdown con Front Matter. Metadata estructurada (título, descripción, categoría, rol, imágenes con posición relativa al contenido), versionable en Git, sin CMS ni base de datos. Agregar un proyecto nuevo es crear un .md y una carpeta de imágenes — la lógica de página no cambia.

Las páginas se generan en build time (SSG). Los grids usan container queries (@container) en lugar de media queries — los componentes responden al ancho de su contenedor, no del viewport. Cuando ProjectsGrid aparece en home o en el listado, el layout se adapta al espacio disponible sin lógica adicional.

Accesibilidad como principio

No es un ítem de checklist al final. Está en las decisiones base:

• Contraste: mínimo 4.5:1 en texto, 3:1 en interactivos. La auditoría de tokens buscó y corrigió violaciones específicas en navegación.
• Focus: focus-visible en todos los interactivos — anillo visible al navegar con teclado, sin ruido visual al hacer clic con mouse.
• Touch targets: mínimo 44×44px (WCAG 2.5.5) en botones, links y controles.
• Reduced motion: prefers-reduced-motion: reduce desactiva todas las animaciones. El portfolio funciona y se ve bien sin ellas.

Resultados

El sistema cumple los criterios con los que fue diseñado. Los aprendizajes más útiles vinieron de las fricciones.

La auditoría de tokens reveló que usar clases sin semántica (bg-black/70) no es un error menor — es el primer paso hacia un sistema que nadie puede auditar. Reemplazar cada valor hardcodeado con su token correspondiente tomó tiempo; ese tiempo es inversión en mantenibilidad, no perfeccionismo.

Usar @tailwindcss/typography como base para prose fue una decisión de escala, no de comodidad. Mantener márgenes entre headings y párrafos manualmente es manejable para un proyecto; se convierte en fuente de inconsistencia en cuanto hay múltiples archivos Markdown con estructuras distintas. El plugin añade algunos KB al bundle; a cambio, elimina todos los edge cases de ritmo vertical.

Unificar la tipografía de cards con constantes en lugar de condiciones isLarge clarificó algo sobre cómo pienso los sistemas: la coherencia es más valiosa que la expresividad local. Una card grande puede tener padding y sombra propios del layout Bento; su tipografía no debería ser un caso especial.

Cada uno de esos trade-offs tiene algo en común: priorizar la coherencia del sistema sobre el caso especial que se ve bien en el momento. Eso es lo que diferencia diseñar para escalar de diseñar para terminar.

Cómo se mide

Vercel Analytics + Speed Insights instrumentan el sitio desde el primer deploy. Lo que capturan hoy:

• Alcance: pageviews, visitantes únicos, páginas más visitadas, referrers y dispositivos. Permite saber de dónde llegan los lectores y qué páginas consumen.
• Calidad técnica (H3): Core Web Vitals por ruta — LCP, CLS, INP y TTFB. Si el portfolio produce fricción técnica antes de que el lector llegue al contenido, aparece aquí.

Lo que no se mide todavía — y es una limitación honesta:

• Profundidad de sesión: cuántos proyectos lee el mismo visitante en una sola visita.
• Scroll en casos de estudio: si el lector llega al final o abandona a mitad del relato.
• Conversión de CTA: si el portfolio genera una conversación concreta.

H1 y H2 — las hipótesis de credibilidad y razonamiento visible — no tienen métrica directa hoy. Son hipótesis cualitativas que se validan por conversación, no por dashboard. El siguiente paso de medición es implementar eventos personalizados para clicks en CTA y scroll depth en páginas de proyecto. Eso permitiría conectar la calidad del contenido con acción concreta.

El portfolio es el proceso, no el resultado. Quien lo revisa no está viendo un escaparate — está viendo cómo tomo decisiones cuando soy el único responsable de todas las capas.