De Framer a Next.js: construir mi propio portfolio con IA

• ·Portfolio propio, sin dependencia de herramientas de terceros
• ·Sistema de diseño auditado con Impeccable: WCAG AA, tipografía consolidada, tema adaptado al sistema del visitante
• ·6 casos de estudio con narrativa y proceso documentado
• ·Medición de comportamiento real con Clarity, sobre un flujo de deploys verificados

01

Decisiones de diseño antes del código

Antes de escribir una línea, definí todo: sistema de colores, tipografía, arquitectura de páginas, referentes visuales, jerarquía de contenido. El desafío central fue reducir la carga cognitiva (decir más con menos). Cada decisión pasó por una validación visual antes de implementarse.

02

Construcción iterativa con Claude Code

Trabajé en ciclos cortos: prompt, componente, validación visual, siguiente paso. Cada prompt fue una decisión de diseño traducida a instrucciones técnicas. Cuando algo no funcionaba, lo revertía antes de seguir. El criterio de diseñador guió cada decisión técnica.

03

Contenido y narrativa

Seleccioné los proyectos con criterio editorial (no todos, solo los que cuentan algo). Escribí el UX copy en español e inglés, armé la estructura de casos de estudio en MDX y definí qué mostrar y qué dejar afuera. El portfolio como producto tiene punto de vista.

04

Decisiones técnicas con criterio de producto

Dark/light mode que sigue la preferencia del sistema del visitante, bilingüe ES/EN, protección NDA con password, responsive con bottom navigation en mobile, deploy en Vercel con dominio propio. Cada decisión técnica resolvía un problema de experiencia, no de ingeniería.

05

Auditoría de diseño y refinamiento continuo

El portfolio no terminó en el deploy inicial. Semanas después, lo sometí a una auditoría sistemática con Impeccable, un skill de diseño para agentes de IA que corre 41 reglas determinísticas contra patrones típicos de interfaces generadas por IA (gradientes genéricos, cards anidadas, tipografía sobreusada) más chequeos reales de WCAG — no una opinión de un modelo, sino contraste medido en números. El resultado inicial fue 12/20: un solo problema dominaba el resto. El acento verde del sitio, usado como texto en links, CTAs y en el número de resultado de cada caso, medía 1.97:1 de contraste contra el fondo — muy por debajo del 4.5:1 que exige WCAG AA. Invisible a simple vista, real en los números. Lo resolví calibrando una familia de variantes del mismo acento en vez de un solo valor plano, según cada contexto de uso. En el camino aparecieron otros hallazgos: un botón sin label accesible, headings semánticamente rotos, y un bug real donde el sitio arrancaba en modo oscuro para cualquier visitante nuevo, sin importar lo que decía la documentación. También consolidé una escala tipográfica que se había desordenado con el tiempo — de 15 valores sueltos a 7 roles deliberados. Auditoría final: 20/20, sin hallazgos sin explicar. Cada cambio pasó por el mismo pipeline antes de llegar a producción: typecheck, build real, chequeo visual en claro/oscuro y mobile, recién ahí commit y push. No es un solo deploy, es una disciplina que se repite en cada iteración.

06

Medición con datos reales

Sumar analítica no fue un afterthought de marketing — fue dejar de asumir cómo se usa el sitio y empezar a mirarlo. Incorporé Microsoft Clarity: grabaciones de sesión, mapas de calor, comportamiento de scroll y click, sin fricción de configuración pesada. Con esto puedo ver si el toggle de idioma se usa, dónde se cae la atención dentro de un caso de estudio, qué recorridos hace la gente antes de llegar a contacto. La misma lógica que aplico en mis proyectos de cliente — research, validación, decisión con evidencia — ahora corre sobre mi propio sitio.