Proyecto propio · Portfolio y sistema de publicación

Publicar un caso de estudio tenía que costar un archivo, no una tarde

Diseño y desarrollo de mi propio sitio, tratado como un producto: un sistema de componentes, una canalización de imágenes que genera dieciocho versiones de cada captura sin que yo toque nada, y un contenido que vive en el mismo repositorio que el código.

UX/UI Design
Sistema de diseño
Front-end
Rendimiento

Portada del sitio con la afirmación de apertura y un único enlace de entrada

La portada no vende nada: una afirmación, la hora de Valencia corriendo y una sola puerta. 3,8 KB de HTML, cero imágenes y cero fuentes web.

Mi rol: Todo: estrategia de contenido, diseño, sistema visual, maquetación, desarrollo, canalización de imágenes y despliegue. No hay nadie más en el proyecto.
Duración: En marcha desde julio de 2024, con 494 commits. Dos etapas: la estructura y el sistema de imágenes en 2024, y el rediseño editorial y la plantilla de casos de estudio en 2026.
Plataforma: Next.js 16 con Pages Router y exportación estática, React 19 y CSS puro. Sin CMS, sin base de datos y sin servidor: el sitio entero son archivos.
Alcance: 13 páginas, 31 componentes, 3.634 líneas de CSS con 51 variables, 163 imágenes originales y 2.496 variantes generadas automáticamente.
Herramientas: Next, React, Sharp para el procesado de imágenes y Embla para los carruseles. Sin Tailwind, sin preprocesadores y sin una sola fuente web.
Mantenimiento: Un caso de estudio nuevo es un archivo .js y sus imágenes. Se publica haciendo merge a la rama principal; el despliegue es automático.

01 — El desafío

El portfolio de un diseñador de producto es, también, una prueba

El problema de casi todos los portfolios no es el diseño: es el coste de actualizarlos. Cada caso nuevo obliga a pelearse con una plantilla ajena, a recortar imágenes a mano y a decidir otra vez cosas que ya se decidieron. Así que no se actualizan. El mío llevaba meses enseñando proyectos con imágenes de relleno porque publicar uno de verdad costaba una tarde entera.

Y hay un segundo problema, más incómodo. Si me dedico a diseñar productos complejos y a defender decisiones técnicas, el sitio donde lo cuento no puede ser una plantilla comprada que tarda en cargar. La página es parte del argumento.

El encargo que me hice fue concreto: que añadir un caso de estudio consistiera en escribir un archivo y soltar unas imágenes en una carpeta, y que todo lo demás —las versiones responsive, los formatos, el SEO, la navegación entre proyectos— ocurriera solo.

18 versiones por imagen

se generan solas: tres anchos, tres formatos y dos densidades. Llevan 2.496 variantes creadas sin abrir un editor de imagen.

Lo que tenía que resolver

Que publicar un proyecto no dependiera de acordarme de veinte pasos.
Que el sitio cargara rápido de verdad, no rápido según una herramienta.
Que el contenido y el código vivieran juntos y con historial.

02 — Restricciones y alcance

Sin equipo, sin presupuesto y sin nadie que revise

Un proyecto propio no tiene cliente que ponga límites, y eso es justo el peligro: puede crecer para siempre. Las restricciones me las puse yo, y son las que explican casi todas las decisiones técnicas.

De contexto

Soy diseñador y desarrollador a la vez. Nadie me va a implementar lo que dibuje, así que cada decisión visual tenía que ser una que yo pudiera construir y mantener solo.
El tiempo es el que sobra. Se trabaja entre encargos, a ratos. Un sistema que hay que recordar cómo funciona cada vez que se vuelve, no sirve.
Nadie revisa. No hay QA ni segunda opinión, así que el sistema tenía que hacer difícil equivocarse: pocas piezas, muy repetidas.
Coste de operación cero. Sin servidor que pagar ni CMS que mantener: si el proyecto se queda parado seis meses, no se cae ni caduca nada.

Técnicas

Todo estático. El sitio se exporta como archivos y se despliega al mergear a la rama principal. Sin base de datos: el contenido son archivos con su historial en git.
Sin fuentes web. Tres pilas del sistema —sans, monoespaciada y Georgia para las cursivas— en lugar de tipografías descargadas. Ni una petición de red para pintar texto.
CSS a mano. Una hoja global de 3.634 líneas con 51 variables y tipografía fluida con clamp(). Sin Tailwind ni preprocesadores.
Las imágenes son el peso. Capturas de interfaces densas que hay que poder leer. De ahí la canalización propia: el problema no era el CSS, eran los megas.

03 — Proceso y decisiones clave

El cuello de botella no era diseñar: era publicar

Cuando miré por qué el sitio llevaba meses sin tocarse, la respuesta no tenía que ver con el diseño. Tenía que ver con la fricción de cada publicación: exportar la imagen a tres tamaños, convertirla a tres formatos, renombrarla, escribir las etiquetas de SEO, acordarme de enlazar el proyecto siguiente. Ninguna de esas tareas es difícil; juntas son suficientes para no empezar.

Así que el rediseño no empezó por la tipografía, empezó por el script de imágenes. Dejo el original en una carpeta con el sufijo _full o _fixed y, al arrancar el proyecto, Sharp genera las dieciocho versiones que necesitan los componentes. Un <FullImage> escribe después el <picture> con sus media queries y sus formatos. Yo no vuelvo a pensar en una imagen.

Lo mismo con el contenido. Cada caso es un archivo que exporta su slug y sus metas, y un único Layout construye a partir de ahí el título, la descripción, el canonical y las etiquetas sociales. No hay ninguna página que escriba su propio <head>: si mañana cambia una convención de SEO, se cambia en un sitio.

Trade-offs

Contenido como código, no como base de datos

Descartado: un CMS sin cabeza con su panel de administración.
Por qué: escribir un caso es maquetarlo. Los bloques no son texto plano, son componentes con datos; en un editor genérico habría que domarlos con campos que nunca encajan.
Coste asumido: no puedo publicar desde el móvil y hay que tocar código para corregir una coma. A cambio, cada cambio tiene autor, fecha y un diff.

Tipografías del sistema, no fuentes web

Descartado: una pareja de fuentes de marca cargadas desde un servicio externo.
Por qué: el titular es lo primero que se ve y no puede esperar a una descarga. Las pilas del sistema pintan al instante y en cada plataforma se ven nativas.
Coste asumido: el sitio no tiene una tipografía propia y reconocible. La personalidad la ponen el tamaño, el contraste y la cursiva de Georgia en la palabra que importa.

CSS a mano, no un framework de utilidades

Descartado: Tailwind, que era la opción rápida y la que más gente conoce.
Por qué: quería un sistema de tokens que yo entendiera del todo y que se leyera como un sistema de diseño, no como una cadena de clases en el marcado.
Coste asumido: 3.634 líneas que solo mantengo yo, y el riesgo de que crezcan sin orden. Se contiene obligando a que todo color, espacio y tamaño salga de una variable.

Dos plantillas, no una página a medida por proyecto

Descartado: maquetar cada caso de estudio como una pieza única, que es lo apetecible.
Por qué: lo único que hace que un portfolio siga vivo es que el siguiente caso sea barato. Una plantilla por defecto y otra de proyecto cubren las trece páginas.
Coste asumido: todos los casos se parecen entre sí. Lo compensan el contenido y las imágenes anotadas, que sí son distintas en cada uno.

Evolución del proyecto

Julio de 2024 · Estructura. Arranque con Pages Router y exportación estática, el Layout con el SEO centralizado y las primeras páginas.
Otoño de 2024 · La canalización de imágenes. El script con Sharp y los componentes FullImage y FixedImage. Es la pieza que más veces se ha usado y la que menos ha cambiado.
2025 · Parón. Tres commits en todo el año. La prueba de que el problema no era el diseño, era el coste de publicar.
2026 · Rediseño editorial. Barra superior con navegación, tema claro y oscuro, acento configurable, y un tono más directo: afirmaciones en lugar de descripciones.
2026 · La plantilla de casos. ProjectFacts, AnnotatedImage, TwoBlocks y ProjectFooter: el sistema con el que están escritos los casos que estás leyendo, este incluido.

04 — Solución final

El sistema, visto desde dentro

Lo que sigue son capturas del sitio en el que estás. La página que lees ahora mismo usa los mismos componentes que aparecen en las imágenes.

Primera pantalla de la página de inicio con la barra superior y el titular editorial — Página de inicio: la barra superior con navegación y controles, y un titular que ocupa el ancho de la columna.

Cabecera de una página de proyecto con su imagen principal y su ficha técnica — La plantilla de caso de estudio: barra contextual, hero, imagen a ancho completo con su pie y la ficha técnica en rejilla.

Carrusel de proyectos con sus tarjetas y sus controles — Listado de proyectos: tarjetas con antetítulo, titular, resumen y etiquetas, en un carrusel con control manual.

Página de currículum con sus pestañas y las entradas plegadas — Currículum: tres pestañas, las entradas plegadas por defecto y la descarga del CV en la barra.

Sección de tres tarjetas oscuras con acción de giro — Tres tarjetas que se giran para enseñar el reverso, en la sección que explica las capas de un producto digital.

Detalle de los controles de la barra superior con el menú de contacto desplegado

Selector de acento, conmutador de tema y menú de contacto. El contacto no es un formulario que hay que rellenar: son tres canales directos, en el sitio donde vive la acción principal.

La misma página de inicio en tema oscuro

El tema oscuro no es una inversión automática: cada variable de color tiene su pareja. El acento se mantiene y el peso de los titulares se ajusta, porque el texto claro sobre oscuro engorda.

Sección de problemas reales citados como frases de usuario

Cada síntoma se escribe como lo diría un cliente, en monoespaciada y entre comillas, con su categoría al margen. Es la sección que más conversaciones ha abierto: la gente se reconoce en una frase, no en una lista de servicios.

Lista de diagnóstico inicial plegada en acordeón

Los diez puntos de un diagnóstico, plegados. Enseñar la lista completa desplegada convertía la sección en un muro; plegada se lee como un índice de lo que se revisa.

Bloque oscuro con retrato y marquesina de especialidades en movimiento

El único bloque del sitio con una foto grande. Debajo, una marquesina que repite las especialidades: es el recurso más llamativo de la página y por eso solo aparece una vez, aquí.

Carrusel de testimonios con foto, cargo y enlace a LinkedIn

Los testimonios se muestran completos, sin recortar ni entresacar frases sueltas, y cada uno enlaza al perfil de quien lo firma. Un elogio sin nombre verificable no vale nada.

Tres pantallas del sitio en móvil, una al lado de otra

En móvil la barra cambia de forma: menú en la portada y flecha de volver dentro de un proyecto. Las mismas piezas, reordenadas, sin una hoja de estilos aparte.

05 — Resultados y aprendizajes

Lo que se puede medir de un proyecto propio

Aquí no hay métricas de negocio ni pruebas con usuarios: hay un repositorio, un build y un historial. Estas cifras salen de ahí.

3,8 KB

pesa el HTML de la portada, sin imágenes y sin fuentes web. Un caso de estudio completo, con sus veinte anotaciones, son 47 KB.

2.496

variantes de imagen generadas automáticamente a partir de 163 originales. Ninguna se ha recortado ni convertido a mano.

0

peticiones a servicios externos para pintar la página: ni tipografías, ni iconos, ni hojas de estilo de terceros.

31 componentes

cubren las 13 páginas con solo dos plantillas. El caso más reciente se montó sin escribir una línea de CSS nueva.

Lo que cambió en la práctica

Publicar un caso pasó de una tarde a escribir un archivo y dejar las imágenes en una carpeta.
El sitio volvió a moverse: 112 commits en lo que va de 2026, frente a 3 en todo 2025.
Las decisiones dejaron de repetirse. Un componente nuevo se define una vez y aparece igual en las trece páginas.
Los casos de estudio se pueden reescribir enteros sin miedo, porque el diseño no está en el texto: está en los componentes.

Retrospectiva

Automatizar antes que rediseñar. El parón de 2025 no se arregló con una tipografía nueva, sino con el script de imágenes. El cuello de botella casi nunca está donde apetece mirar.
Un proyecto propio necesita restricciones inventadas. Sin cliente que diga que no, lo único que frena el rediseño infinito es haber escrito de antemano qué no se va a tocar.
La deuda también se escribe. Hay una página publicada sin contenido y con sus etiquetas de SEO puestas, el repositorio arrastra 208 MB de imágenes, y la documentación interna describe una versión del proyecto que ya no existe. Están en la lista, no escondidas.
Lo que falta. Una auditoría de accesibilidad de verdad: contraste en tema oscuro, foco visible en los carruseles y estados anunciados en los acordeones. Es la siguiente tarea, y no un adorno.
Lo siguiente. Que las tarjetas del listado salgan del mismo sitio que la cabecera de cada caso, para que no se puedan desincronizar. Hoy se escriben dos veces, y ya se ha notado.

Un sitio que se mantiene porque cuesta poco mantenerlo

El valor de este proyecto no está en cómo se ve, sino en que sigue creciendo: un sistema de treinta y un componentes, una canalización que convierte una captura en dieciocho archivos y un contenido que vive con el código y su historial. La prueba es esta misma página, escrita con las piezas que acaba de enseñar.