Portada del artículo sobre Roadmade y el proceso de un proyecto de diseño.

Roadmade: entender y estimar un proyecto de diseño antes de empezar

He diseñado webs durante años. También he trabajado en identidad visual.

Aun así, cuando decidí profundizar en UX/UI, me di cuenta de que conocer las partes no era lo mismo que entender el recorrido completo. Podía buscar qué era una entrevista, un user flow o un test de usabilidad. Lo difícil era saber qué venía antes, qué dependía de qué y cuándo podía dar una fase por terminada.

No necesitaba otra lista de tareas sueltas. Necesitaba entender el proceso.

De esa necesidad nació Roadmade, una aplicación de roadmaps explicados y editables para proyectos de diseño. Incluye dos disciplinas, UX/UI e identidad visual, y permite convertir un proceso amplio en decisiones concretas de trabajo.

Vista real de un proyecto de identidad visual dentro de Roadmade, con su estado, fases, tareas y horas.

Onepage de Roadmade mostrando la fase de briefing y preparación del roadmap UX/UI.

El problema no era encontrar información

Información hay mucha. Hay artículos sobre investigación, wireframes, sistemas de diseño, naming o manuales de identidad. El problema aparece cuando tienes que convertir todo eso en un proyecto real.

¿Qué tareas corresponden a este encargo? ¿Cuánto tiempo pueden llevar? ¿Qué puedes dejar fuera sin comprometer el resultado? ¿De dónde salen las horas que después incluyes en una propuesta?

En Roadmade el punto de partida es un proceso profesional estructurado. No pretende que todos los proyectos sean iguales. Es una referencia completa que puedes consultar y adaptar con criterio.

Aquí utilizo roadmap para hablar del recorrido de trabajo de un proyecto de diseño, no de un roadmap de producto destinado a priorizar funcionalidades durante meses. Roadmade no decide qué debe construir una empresa. Ayuda a ordenar el trabajo necesario para abordar un encargo de diseño.

Una tarea debería explicar algo más que su nombre

Una checklist puede decirte: «Detectar el problema real de marca».

Pero esa frase puede quedarse corta. ¿Qué significa exactamente? ¿Por qué importa? ¿Cómo sabes que la tarea está terminada?

Por eso cada tarea incorpora tres niveles de explicación:

  • Qué es, para situar la acción.
  • Por qué importa, para entender la decisión que hay detrás.
  • Hecho cuando, para reconocer un criterio de cierre.

También puedes editar el título y las horas, añadir una nota privada, completar la tarea o excluirla si no corresponde al encargo.

No se trata de marcar casillas. Se trata de saber qué estás aceptando, cambiando o dejando fuera.

Explicación de una tarea en Roadmade con qué es, por qué importa y cuándo está terminada.

UX/UI e identidad visual necesitan recorridos distintos

Las dos disciplinas comparten algunas preocupaciones —entender el encargo, investigar, definir el alcance, presentar y entregar—, pero no son el mismo proceso con etiquetas diferentes.

En UX/UI, el recorrido pasa por la definición, la investigación, la arquitectura, los flujos, la interfaz, las pruebas y el handoff. En identidad visual, avanza desde el briefing y el diagnóstico hasta la estrategia, la dirección visual, el sistema gráfico, sus aplicaciones y el manual.

Cada disciplina tiene sus propias fases, tareas y entregables. En ambos casos el recorrido se puede adaptar, porque un proyecto pequeño no necesita lo mismo que uno complejo y un rediseño no parte del mismo lugar que una marca nueva.

La guía muestra el mapa completo. La persona decide qué camino tiene sentido recorrer.

Ver el trabajo ayuda a estimarlo mejor

Muchas veces pensamos en el logotipo, las pantallas o el entregable final, pero dejamos fuera reuniones, investigación, revisiones, QA o preparación de la entrega. Si esas tareas no aparecen, tampoco entran en la estimación.

Roadmade asigna horas editables a tareas, bloques y fases. Cuando excluyes algo o ajustas su duración, la estimación cambia con el alcance. Después puedes calcular cada fase con tu tarifa, con otra tarifa si interviene otra persona o con un precio cerrado.

El resultado es una referencia interna antes de preparar el presupuesto. No es una factura ni un presupuesto contractual, y tampoco decide cuánto debes cobrar. El precio final sigue siendo una decisión profesional.

La IA puede proponer. La persona decide

La revisión con IA parte del brief y lo compara con el roadmap. Puede sugerir qué partes parecen necesarias y cuáles podrían quedar fuera, explicando el motivo.

Nada se aplica automáticamente. Puedes aceptar, rechazar o editar cada propuesta.

Para mí este límite es importante. La IA puede ayudar a detectar incoherencias, pero no conoce todos los matices del cliente, del equipo o del contexto. Una sugerencia necesita revisión, no obediencia.

¿A quién puede ayudar Roadmade?

Roadmade puede servir a quien está entrando en una disciplina y quiere comprenderla sin aprenderla a base de piezas sueltas. Pero también a profesionales, estudios o empresas que necesitan dimensionar un encargo antes de comprometer horas, fechas y precio.

Los usos son distintos, pero la necesidad es la misma: tener delante el proceso y convertirlo en decisiones reales.

No sustituye la experiencia. La hace más visible.

Lo que me llevo como diseñadora

Durante mucho tiempo asocié un proceso detallado con una forma rígida de trabajar. Construir Roadmade me ha hecho verlo de otra manera.

Tener el proceso delante no significa seguirlo sin pensar. Significa poder quitar una tarea sabiendo por qué no corresponde, ampliar una fase cuando el encargo lo exige y explicar mejor de dónde salen las horas.

Una guía no elimina el criterio. Te da una base más clara para utilizarlo.

En resumen

→ Roadmade reúne el proceso y la explicación en un mismo lugar.

→ Incluye recorridos específicos para UX/UI e identidad visual.

→ Permite adaptar tareas y horas al alcance real del encargo.

→ Convierte ese alcance en una estimación interna de tiempo y coste.

→ La IA propone cambios, pero la persona decide siempre.

Puedes empezar a utilizar Roadmade con hasta dos proyectos activos. Yo seguiré revisándola como reviso cualquier proyecto de diseño: usándola y detectando qué decisiones todavía pueden mejorar.

Portada del artículo sobre cómo se construyó Roadmade con Claude Code y Codex.

Cómo construí Roadmade: de Claude Code a Codex

Roadmade no nació de un prompt. Tampoco de un plan perfecto.

Nació de una necesidad que ya tenía antes de abrir ninguna herramienta de IA: quería comprender el proceso UX/UI completo. Venía del diseño web y la identidad visual, conocía muchas de sus partes, pero me faltaba verlas conectadas desde el briefing hasta la entrega.

La idea era sencilla de explicar y bastante menos sencilla de convertir en un producto: reunir un proceso profesional, explicarlo y permitir que cada persona lo adaptara a un proyecto real.

El curso «Crea tus propias apps reales con Claude Code», de tribUX, me dio el contexto para empezar a construir esa idea. El certificado acredita esa formación; no valida Roadmade ni convierte el resultado en algo terminado.

Onepage de Roadmade mostrando la fase de investigación y definición del roadmap UX/UI.

La necesidad vino antes que la aplicación

Podía haber creado una checklist rápida de UX/UI. Habría sido más fácil, pero no resolvía lo que yo necesitaba. Una lista dice qué hacer; no necesariamente explica por qué importa, cómo encaja con lo anterior o cuándo puedes considerar que has terminado.

También quería que el método no dependiera de lo que una IA decidiera generar cada vez. El contenido debía partir de prácticas profesionales conocidas y mantener una estructura estable. La IA podría ayudar a adaptar el recorrido, pero no inventarlo desde cero.

Esa decisión condicionó la arquitectura, la forma de presentar las tareas y el papel de la IA dentro de la aplicación.

La primera construcción con Claude Code

Empecé a desarrollar Roadmade durante el curso trabajando con Claude Code.

Yo no llegaba como desarrolladora experta. Llegaba como diseñadora con una necesidad concreta, experiencia en web y muchas decisiones de producto que tomar. No se trataba de pedir «hazme una app de UX».

Mientras la aplicación tomaba forma, fui decidiendo cómo representar las fases y las tareas, qué debía explicar cada una, cómo excluir trabajo sin borrarlo, cómo mostrar las horas y dónde podía ayudar la IA sin apropiarse del criterio.

También había que distinguir una estimación interna de lo que finalmente ve un cliente. El código era una parte. La definición del producto era otra.

La identidad también forma parte de la experiencia

En el proceso aparecieron el nombre, el logotipo y la identidad de Roadmade. Ayudaron a dar coherencia al proyecto, pero no solucionaron automáticamente la interfaz.

Hubo que ajustar jerarquías, iconos, mensajes y estados. Es una lección que conozco bien por el branding: la identidad no acaba en el logotipo. Si Roadmade prometía claridad, cada decisión de la interfaz debía demostrarla.

Probar un proyecto completo cambió más que otra pantalla

Una de las pruebas más útiles llegó al recorrer un proyecto de principio a fin.

En un formulario apareció un error y se borró lo que ya se había escrito. Técnicamente, la validación había detectado que faltaba algo. Desde la experiencia de uso, el resultado era absurdo: la aplicación avisaba de un problema creando otro mayor.

La corrección exigía conservar el contenido, señalar el campo que requería atención y avisar antes de que la persona perdiera su trabajo.

En otra pantalla, las tareas excluidas no entraban en el cálculo, pero todavía parecían disponibles para marcarlas como completadas. El sistema hacía una cosa y la interfaz sugería otra.

Estos fallos también son diseño. Una pantalla puede verse bien y seguir siendo confusa cuando alguien se equivoca o cambia de opinión.

Del producto a la onepage: continuar con Codex

Más adelante continué el trabajo con Codex y construí la onepage actual de Roadmade.

Parecía una tarea distinta, pero explicar la aplicación me obligó a revisarla otra vez. Había que dejar claro que incluye procesos de UX/UI e identidad visual, que las tareas se pueden adaptar, que las horas son una estimación interna y que la IA nunca modifica el proyecto por su cuenta.

Escribir esa explicación fue otra forma de diseñar. Si necesitaba demasiados matices para justificar una función, quizá la función o su interfaz todavía no estaban suficientemente claras.

La onepage no fue solo un envoltorio. Funcionó como una prueba de comprensión del propio producto.

Onepage de Roadmade mostrando la fase de entrega, QA y cierre del roadmap UX/UI.

Cambió la herramienta, no la responsabilidad

Claude Code me ayudó a construir la primera etapa. Codex me permitió continuar, revisar y llevar el producto y su presentación a otro punto.

No quiero convertir esto en una comparación de asistentes ni en una historia de velocidad. Ya he contado que usar IA puede añadir más capas al trabajo, no necesariamente quitarlas.

En Roadmade esas capas fueron muy concretas: definir el problema, estructurar el método, probar recorridos, corregir contradicciones, cuidar la accesibilidad y explicar el resultado.

Las herramientas podían proponer código, textos o soluciones. Yo tenía que decidir si respondían a la necesidad original.

Lo que me llevo como diseñadora

Construir Roadmade me ha confirmado que poder producir una primera versión no equivale a tener un producto resuelto. El trabajo importante aparece en las decisiones que conectan una necesidad con una experiencia coherente.

Cuando una interfaz era confusa, no bastaba con explicar mejor mi intención. Había que cambiarla. Cuando una estimación podía confundirse con un precio para el cliente, había que separar ambos conceptos. Y cuando la IA proponía cambios, había que hacer visible que la decisión seguía siendo humana.

No he salido de este proceso pensando que ahora todo es más fácil. He salido con una herramienta real, más criterio sobre cómo construirla y una lista más precisa de lo que todavía quiero mejorar.

En resumen

→ Roadmade nació de una necesidad de aprendizaje y de trabajo, no de un prompt aislado.

→ Claude Code me ayudó a convertir esa necesidad en una primera aplicación durante el curso.

→ Las pruebas reales descubrieron problemas que una pantalla estática no mostraba.

→ El nombre, la identidad, la interfaz y los textos formaron parte del mismo producto.

→ Con Codex continué el trabajo y construí una onepage que también sirvió para revisar qué prometía Roadmade.

→ La IA participó en la construcción; las decisiones y la responsabilidad siguieron siendo mías.

Puedes conocer el resultado actual en Roadmade y leer primero el artículo de presentación de la herramienta. Seguiré contando el proceso sin convertirlo en una historia limpia, porque lo más útil no fue acertar a la primera. Fue saber qué mirar cuando algo no funcionaba.

Del Pantone al prompt: el diseñador como eterno aprendiz

Cuando estudié en Elisava, trabajábamos con papeles Pantone, tijeras y rotuladores. Recuerdo que en clase nos dijeron que los ordenadores «solo serían una herramienta más».

Cuando salí al mercado laboral, solo trabajábamos con ordenadores.

Llevo más de 25 años en diseño. Y esa escena se ha repetido varias veces.

evolución del diseñador UX del pantone a la inteligencia artificial

Guía visual sobre la evolución del diseñador: de las herramientas tradicionales al UX y la inteligencia artificial.


De Freehand a Figma: el suelo siempre se mueve

Empecé con Freehand, Quark, Photoshop. Herramientas que en su momento eran lo que había que saber. Luego llegó Illustrator, InDesign, el diseño web, WordPress…

Cada vez que el sector cambiaba, tocaba aprender. No había otra opción.

Pero hay algo que no cambiaba: el proceso de pensar antes de diseñar.

Desde muy pronto entendí que antes de abrir cualquier programa había que hacer otras cosas. Estudiar la competencia. Conocer al cliente. Entender al usuario final. Saber qué problema resolvía el producto. Tener reuniones, iterar, validar. Construir una arquitectura de contenidos antes de tocar ni un píxel.

No sabía que eso tenía nombre. Lo hacía porque tenía sentido.


El día que descubrí que lo que hacía se llamaba UX

Hace no tanto, escuchando el podcast Píldoras UX, empecé a escuchar conceptos que no conocía: arquitectura de la información, usabilidad, jerarquía cognitiva, patrones de navegación, diseño centrado en el usuario…

Y pensé: ¿pero si esto es lo que yo hago?

Lo que yo llamaba «el esquema de la web» se llamaba arquitectura de la información. Lo que llamaba «conocer al usuario antes de empezar» se llamaba research. Lo que llamaba «que se entienda» se llamaba reducción de fricción. Lo que llamaba «reuniones continuas con el cliente para validar» se parecía mucho a un proceso de Design Sprint.

Había un vocabulario entero, un marco teórico, para decisiones que tomaba por criterio y por años de trabajo.

Eso fue un alivio. Y también un empujón. Y, seré honesta, un pelín estresante — porque junto a las cosas que ya hacía había cosas que genuinamente no sabía. Usabilidad con método. Accesibilidad real — no solo «que se vea bien en móvil». Sistemas de diseño. Figma a fondo. Patrones de interacción. Dark patterns. Sesgos cognitivos aplicados al diseño.

Me puse a aprender. Curso de UX de Google. Cursos de Figma. Libros como No me hagas pensar de Steve Krug. Más podcasts. Más lecturas.

Sustituí Photoshop por Figma. Un programa que uso a diario y con el que cada vez me siento más cómoda — aunque todavía me queda mucho por explorar y perfeccionar. Y luego seguí — porque sigo aprendiendo, y probablemente no pare.


Y cuando empezaba a sentirme más segura, llegó la IA

Ahora toca aprender otra capa encima: Google AI Studio, Figma Make, flujos con IA, prompts, automatizaciones…

Y lo más difícil no es aprender una herramienta. Es que no puedes centrarte en una sola. El trabajo te lleva de una a otra antes de que hayas terminado de entender la anterior. Todavía estás procesando una cuando ya hay tres más esperando.

A veces siento que no llego a todo. Que la meta se aleja justo cuando creía que me estaba acercando.

Me quejo — pero a la vez me emociona. Me emociona ver lo que puedo crear ahora, lo que puedo hacer con herramientas que hace dos años no existían. Y al mismo tiempo me da miedo. Miedo a no llegar, a que el ritmo sea demasiado, a quedarme atrás sin darme cuenta.

Supongo que las dos cosas pueden ser verdad a la vez.


Pero esta sensación tampoco es nueva

La tuve cuando salí de Elisava y el mercado ya solo trabajaba con ordenadores. La tuve cuando el diseño web se convirtió en parte del trabajo y había que aprender casi desde cero. La tuve cuando llegó Figma y tocó reaprender flujos que creía que ya dominaba. Y ahora la tengo con la IA.

Y aquí sigo. Aprendiendo. Trabajando. Sin haber parado.

Lo que cambia con los años no es que la incertidumbre desaparezca. Es que aprendes a reconocerla. Sabes que es parte del proceso, no una señal de que estás haciendo algo mal.


Lo que me llevo como diseñadora

Que la experiencia no te vacuna contra la incertidumbre. Te enseña a convivir con ella.

Que muchas cosas que hacía «por instinto» tenían un nombre, un marco y una razón detrás. Aprenderlo no me hizo sentir que empezaba de cero — me hizo entender mejor lo que ya hacía.

Y que en diseño, como en casi todo, quedarte quieta siempre ha sido la peor decisión.

La meta se mueve. Lleva moviéndose desde que empecé. Eso no es un problema. Es el oficio.


En resumen

→ En diseño, el suelo se mueve. Lleva moviéndose desde los Pantones y el Freehand. → Muchas decisiones de UX/UI las tomaba ya — solo sin el nombre ni el marco teórico. → Aprender el vocabulario no es empezar de cero: es entender mejor lo que ya hacías. → La IA no es la primera revolución que vivo en este sector. Probablemente tampoco será la última. → La sensación de «no llego» no es señal de que algo falla. Es señal de que estás en un sector vivo. → Me emociona y me da miedo a la vez. Supongo que eso también forma parte del oficio.


Fuentes e inspiración

— Píldoras UX (podcast): pildorasux.com/podcast — Steve Krug, No me hagas pensar — Curso de Diseño UX de Google

Guía rápida para entender marca, UI kits y sistemas de diseño

Guía rápida para entender marca, UI kits y sistemas de diseño (explicado fácil)

Llevo años trabajando con marcas y webs, y últimamente me he metido de lleno en el mundo del UX/UI. Y si hay algo que he visto repetirse (en equipos, en clientes y también en mí misma) es esta confusión:

“¿Necesitamos un sistema de diseño?”
“¿O solo un UI kit?”
“¿Esto no era la identidad visual?”
“¿Y la biblioteca de Figma qué pinta aquí?”

La realidad es que todo está relacionado, porque todo busca coherencia. Pero no es lo mismo. Y cuando mezclas conceptos, suele pasar una de dos: o te quedas corto en tus diseños… o te complicas la vida de más.

Así que he escrito esta guía rápida para ordenar las piezas y entender qué es cada cosa, sin tecnicismos raros.


1. ¿Qué es la identidad de marca?

La identidad de marca es quién es la marca y cómo se expresa. No es solo “lo que se ve”, también es lo que se siente.

Aquí entran elementos intangibles y de comunicación:

  • Propósito, valores y personalidad.
  • Tono de voz (cómo habla y cómo escribe).
  • Experiencia (cómo se comporta en cada punto de contacto).
  • Sensorial: cómo suena (si aplica), qué estilo transmite y qué sensación deja al interactuar con ella.

Dicho fácil: Identidad de marca = lo que eres + cómo te expresas.


2. ¿Y la identidad visual?

La identidad visual es una parte de la identidad de marca: la parte que se ve (la “cara”).

Incluye los cimientos gráficos:

  • Logo y sus versiones.
  • Paleta de color.
  • Tipografías.
  • Estilo gráfico (fotografía, ilustración, iconografía).

Dicho fácil: Identidad visual = cómo se ve la marca.

Matiz importante: una marca puede tener una identidad visual impecable en un manual en PDF… y aun así ofrecer una experiencia digital caótica si la interfaz (UI) se monta sin un sistema.


3. Entonces… ¿qué es un UI kit?

Un UI kit es una caja de piezas preparadas para diseñar pantallas de forma consistente y rápida.

Suele incluir:

  • Estilos de color y tipografía ya aplicados a la interfaz.
  • Componentes base (botones, inputs/campos de formulario, tarjetas, etiquetas).
  • Iconos y recursos gráficos reutilizables.
  • Ejemplos de composición (secciones, layouts, módulos).

Un UI kit te resuelve la vida en proyectos donde necesitas mantener coherencia visual, agilizar el diseño y no tener que reinventar la rueda en cada pantalla.

Dicho fácil: UI kit = piezas para diseñar interfaces con coherencia y velocidad.


4. ¿Y un sistema de diseño?

Aquí subimos de nivel. Un sistema de diseño no es solo un kit de componentes. Es componentes + reglas + documentación para que un producto digital se mantenga coherente a lo largo del tiempo, aunque crezca o cambie el equipo.

Según el Nielsen Norman Group, un sistema de diseño reúne patrones, estilos y guías para escalar el diseño en productos digitales.

¿Qué suele incluir un sistema de diseño (aunque sea uno ligero)?

  • Tokens (variables de diseño): por ejemplo, usar colores por rol (como color-primary, color-error, text-default) en lugar de trabajar con nombres subjetivos.
  • Componentes con estados: cómo se ve un botón en default, al pasar el ratón (hover), cuando está enfocado (focus), mientras lo estás pulsando (pressed/active), si está desactivado (disabled) o si hay error.
  • Patrones: cómo se construyen los formularios, la navegación o las pantallas vacías.
  • Accesibilidad: contraste, tamaños mínimos para móvil, foco visible, etc.
  • Reglas de uso: cuándo usar cada elemento y cómo.
  • Implementación en código: si hay equipo tech, su versión equivalente para desarrollo.

Dicho fácil: Sistema de diseño = coherencia a escala (visual + funcional + de equipo).


5. Y en Figma… ¿qué es una biblioteca?

Aquí es donde suele venir el lío. “Biblioteca” suena a concepto abstracto, pero en Figma es una herramienta muy concreta.

Una biblioteca en Figma es el archivo (o conjunto de archivos) donde guardas y publicas tus estilos, componentes, iconos y variables. La idea es que otras personas (o tú en otros proyectos) puedan usar exactamente esos mismos recursos sin tener que copiar, pegar ni duplicar.

Dicho fácil: Biblioteca (Figma) = el “paquete compartible” de tus elementos de diseño.

Ojo con esta diferencia, porque lo aclara todo:

  • Puedes tener una biblioteca de Figma sin tener un sistema de diseño (solo es un kit ordenado, pero sin reglas de uso).
  • Puedes tener un sistema de diseño sin una biblioteca de Figma (está documentado, pero no lo tienes montado en tu software de diseño).
  • Lo ideal: Sistema (decisiones) + Biblioteca (implementación).

El resumen definitivo (y un ejemplo)

Para que todo encaje, míralo así:

  • Identidad de marca: define el carácter (quién eres).
  • Identidad visual: traduce ese carácter en diseño gráfico.
  • UI kit: baja esa identidad a piezas concretas para pantallas.
  • Sistema de diseño: convierte esas piezas en un producto escalable con reglas.
  • Biblioteca (Figma): es la herramienta para compartirlo y trabajar sin caos.

Ejemplo real (Spotify): su identidad es dinámica y musical. Su identidad visual es ese verde icónico sobre fondos oscuros. Su UI kit son los botones, listas y componentes que se repiten en sus pantallas. Y su sistema de diseño (Encore) es el conjunto de reglas y componentes que mantiene todo consistente (tamaños, estados y comportamiento) para que el producto se sienta igual de “Spotify” en cualquier dispositivo.


¿Cuándo necesitas cada cosa? (Regla rápida)

  • Web corporativa (pocas pantallas, poco cambio): con una buena identidad visual y un UI kit ordenado suele ser suficiente.
  • Producto digital / SaaS (muchas pantallas, iteración constante): necesitas un sistema de diseño (aunque sea ligero). Te ahorrará inconsistencias y retrabajo.
  • Trabajo en equipo (diseño + desarrollo o varios diseñadores): una biblioteca de Figma bien montada deja de ser un “lujo” y pasa a ser imprescindible.

¿Y tú, en qué punto estás? ¿Trabajáis con un UI kit bien apañado o ya habéis dado el salto a un sistema de diseño (aunque sea ligero)?


Fuentes e inspiración

  • Nielsen Norman Group – Design Systems 101
  • Figma Help Center – Guide to libraries in Figma
Sesgos cognitivos y UX: por qué tu criterio (y el mío) también se equivoca

Sesgos cognitivos y UX: por qué tu criterio (y el mío) también se equivoca

Durante años he confiado en mi criterio. La experiencia ayuda. Te da intuición. Te permite decidir rápido.

Pero el UX me ha obligado a aceptar algo incómodo: El criterio también está sesgado.

Y cuanto más me adentro en el UX “teórico” —psicología, heurísticos, modelos mentales, sesgos cognitivos— más cuenta me doy de algo incómodo: esos sesgos no son un tema que “le pasa al usuario”. Nos pasan a todos.

  • Al usuario cuando interpreta una interfaz.
  • Al cliente cuando decide qué es importante.
  • Y a mí cuando doy por hecho que algo se entiende “porque está claro”.

No somos “Homo economicus”

La economía clásica partía de una idea mítica: un ser racional que toma decisiones óptimas. Herbert Simon propuso algo más realista: el Homo administrativus.

Somos seres con racionalidad limitada:

  • No podemos procesarlo todo.
  • No tenemos tiempo ni energía infinita.
  • Usamos atajos llamados heurísticos.

Cuando esos atajos nos llevan a errores sistemáticos, hablamos de sesgos cognitivos. No son fallos, son la «cara B» de nuestra supervivencia. Pero en diseño UX, juegan en nuestra contra.

Infografía sobre sesgos cognitivos en UX y racionalidad limitada aplicada al diseño web


El usuario no ve la realidad. La interpreta.

Cada persona llega a tu web con filtros: expectativas, experiencias y modelos mentales propios.

  • Si algo no coincide con su modelo, genera fricción.
  • Si hay demasiada información, activa el modo rápido y superficial.
  • Si algo confunde en los primeros segundos, se etiqueta como “no me interesa”.

Kahneman y Tversky lo explicaron con el Sistema 1 (rápido/automático) y el Sistema 2 (lento/analítico). En una web, casi todo ocurre en el Sistema 1.


El sesgo más peligroso: el del diseñador

Hay uno especialmente delicado: el sesgo de retrospectiva. Cuando algo funciona, parece obvio. Cuando falla, parece que era evidente que fallaría. Pero en el momento del diseño, no lo era.

Es fácil creer que “esto está claro”. Claro para ti o para el cliente, pero no para quien llega por primera vez. Ahí es donde el UX deja de ser estética y se convierte en método.


Cómo gestionamos los sesgos en un proyecto

No se eliminan, se gestionan con acciones concretas:

  1. Separar hipótesis de hechos: No es «creo que…», es tener evidencias reales.
  2. Cuestionar lo obvio: Si parece muy evidente, probablemente es porque lo ves desde dentro.
  3. Contrastar: Observar cómo navegan y dónde se pierden.
  4. Dar tiempo al pensamiento lento: No decidir en caliente tras una reunión.
  5. Documentar decisiones: Escribir por qué eliges una estructura reduce el autoengaño.


UX y UI: donde la psicología se vuelve visible

La jerarquía no es decoración; es reducción de carga cognitiva. La claridad no es minimalismo; es respeto por la atención limitada del usuario.


Lo que me llevo como diseñadora

Que la experiencia ayuda, pero no es neutral. Que el cliente no es el usuario.
Y que yo tampoco lo soy.

Que diseñar bien no es imponer lógica. Es entender la lógica invisible que ya existe en la mente de quien llega.

Y que el verdadero reto del UX no es hacer interfaces bonitas. Es diseñar sabiendo que nuestra percepción de la realidad también está sesgada.


En resumen

  • Usamos atajos mentales para decidir.
  • Los sesgos nos afectan a todos.
  • El proceso UX existe para reducir suposiciones.
  • Cuestionar lo evidente es parte del trabajo.

El buen criterio no es el que siempre acierta, es el que sabe que puede equivocarse.


Fuentes e inspiración

– Daniel Kahneman y Amos Tversky, heurísticas y sistema 1 / sistema 2
– Herbert A. Simon, racionalidad limitada
– Jaime Rodríguez de Santiago, La realidad no existe
– Steve Krug, No me hagas pensar

Quitar texto también es diseñar: claridad y jerarquía en diseño web

La gente no lee tu web: la escanea (diseñar sin asumir esto es perder dinero)

Una de las ideas más liberadoras (y a la vez más incómodas) de No me hagas pensar de Steve Krug es esta:

La gente no lee una web. La escanea.

No porque no le interese.
Porque así funciona la navegación real: prisa, comparación, atención limitada y búsqueda de señales claras.


¿Qué significa “escanear” en la práctica?

Significa que el usuario:

  • mira titulares,
  • detecta palabras clave,
  • busca botones o enlaces evidentes,
  • y decide en segundos si se queda o se va.

Krug también habla de otra idea muy humana: la mayoría no toma “la mejor decisión posible”. Hace satisficing: elige la primera opción que parece suficientemente buena.

Traducido a tu web: si la primera impresión no es clara, no es que el usuario “lea más”. Es que se marcha.


¿Qué debería cambiar en una web cuando asumes esto?

Si aceptas que escaneamos, el diseño cambia de prioridad:

  • Titulares que informan, no que decoran
  • Jerarquía visual clara (qué es lo importante y qué no)
  • Bloques cortos y bien separados
  • Enlaces que parecen enlaces
  • Menos “relleno” y más intención

Este punto me toca especialmente porque en proyectos reales ocurre muchísimo: clientes que quieren “explicarlo todo”, textos largos, introducciones eternas…

Y aquí el UX no es teoría: es supervivencia. El usuario no está para leer una novela antes de entender qué haces.


Un detalle que parece pequeño, pero no lo es: la confianza

Cuando una web se escanea bien:

  • se percibe orden,
  • se percibe claridad,
  • se percibe profesionalidad,

y eso se convierte en confianza.
No es solo usabilidad. También es marca.


En resumen

→ En la web no leemos: escaneamos.
→ Si tu contenido no se entiende al escanear, no se entiende.
→ Diseñar para escaneo mejora usabilidad, conversión y percepción de marca.
→ La claridad no es estética: es estrategia.


Fuentes e inspiración

La gente no lee tu web, la escanea: principio de usabilidad y UX

Quitar texto también es diseñar: la batalla real en casi cualquier web

Hay una recomendación de No me hagas pensar que me parece brutal por lo simple (y por lo real):

Quita la mitad del texto. Y luego vuelve a quitar la mitad.

Steve Krug no lo dice porque la información no sea importante, sino porque el exceso de texto crea un problema silencioso: ruido.

Y cuando hay ruido, lo relevante desaparece.


El problema típico: “ponlo todo, por si acaso”

En la mayoría de proyectos web pasa lo mismo:

  • el cliente quiere justificar,
  • explicar,
  • cubrirse,
  • añadir contexto,
  • añadir historia,
  • añadir otra historia…

Y al final la web no comunica. Acumula.

El usuario, que escanea, se encuentra un muro.
Y un muro no invita a entrar.


Quitar no es empobrecer

Recortar texto tiene efectos muy concretos:

  • se entiende antes qué haces,
  • se detecta el CTA,
  • se reduce fricción,
  • se hace más fácil navegar,
  • se mejora la percepción de calidad.

Aquí hay una idea que me gusta mucho: diseñar también es editar.

Y esto, para mí, es uno de los puntos donde más se nota la diferencia entre “hacer una web” y “diseñar una experiencia”.


En resumen

→ Mucho texto no es más claridad: suele ser más ruido.
→ Diseñar es también saber qué sobra.
→ Recortar contenido mejora comprensión, navegación y confianza.
→ El UX, muchas veces, empieza en una decisión editorial.


Fuentes e inspiración

 

No me hagas pensar aplicado al diseño web y la usabilidad

“No me hagas pensar”: la regla que separa una web bonita de una web que funciona

Esta serie de artículos nace como un cuaderno de notas abierto. Una forma de aprender escribiendo, de poner orden a lo que voy aprendiendo, y de compartirlo por si a alguien más le sirve.

Llevo años diseñando webs y trabajando la arquitectura de la información casi “por instinto”: ordenar contenidos, jerarquizar, hacer que la navegación sea lógica, reducir ruido… Lo curioso es que muchas de esas decisiones hoy las llamamos UX.

Por eso tenía pendiente leer No me hagas pensar (Don’t Make Me Think) de Steve Krug. Es uno de esos libros que se recomiendan una y otra vez cuando empiezas a tomarte en serio la usabilidad.

Y si tuviera que resumirlo en una frase, sería esta:

Una web debería entenderse sin esfuerzo.


Primero: ¿qué significa “no me hagas pensar”?

No significa que el usuario sea “poco listo”.
Significa que la gente navega con prisa, con mil pestañas abiertas y con atención limitada.

Cuando un diseño obliga a detenerse a descifrar:

  • dónde estoy,
  • qué hace esta empresa,
  • qué se supone que debo hacer ahora,

…el usuario entra en un diálogo mental que no debería existir. Empieza a dudar. Y cuando dudas, pierdes confianza.

Krug lo plantea de forma muy visual con una idea que me encanta: una web tiene que funcionar como una valla publicitaria. No porque sea superficial, sino porque tiene que comunicar lo esencial rápido, sin exigir un esfuerzo extra.

No me hagas pensar aplicado al diseño web y la usabilidad


¿Por qué esto es tan importante (incluso si tu web es “bonita”)?

Porque lo bonito puede atraer… pero lo claro convierte.

Una web puede tener un diseño precioso y aun así fallar si:

  • los titulares no dicen nada,
  • los botones no parecen botones,
  • el menú es creativo pero confuso,
  • la información importante está enterrada.

Y esto se nota especialmente en proyectos reales: cuando el cliente quiere explicarlo TODO, cuando el mensaje principal se diluye, cuando la home es una mezcla de “por si acaso”.


Lo que me llevo como diseñadora

Este libro no me ha “descubierto” la claridad (ya la buscaba), pero sí me ha dado un marco muy útil para defenderla:

  • claridad como prioridad
  • decisiones evidentes
  • estructura que guía
  • menos fricción = más confianza

La idea no es diseñar simple.
La idea es diseñar obvio (en el buen sentido): que el usuario no tenga que adivinar.


En resumen

→ Una buena web se entiende rápido.
→ Si el usuario duda, algo del diseño o del contenido está fallando.
→ La claridad no empobrece: enfoca y genera confianza.
→ “No me hagas pensar” es una regla sencilla… y muy difícil de ignorar cuando la interiorizas.


Fuentes e inspiración

 

Captura destacada del artículo sobre dark patterns y diseño UX ético

Dark patterns: cuando el diseño deja de ser inocente

Esta serie de artículos nace como un cuaderno de notas abierto. Una forma de aprender escribiendo, de poner orden a lo que voy aprendiendo, y de compartirlo por si a alguien más le sirve.

Llevo años diseñando webs, marcas, materiales gráficos. Siempre he tenido en cuenta la estructura, la jerarquía, lo que facilita que el usuario se oriente sin pensar demasiado. Pero reconozco que nunca había profundizado en temas como el diseño ético o los dark patterns… hasta ahora.

Y cuanto más aprendo, más me doy cuenta de que muchas decisiones que parecen “normales” están, en realidad, diseñadas para manipular. No de forma malvada y consciente (al menos no siempre), pero sí con una intención clara: hacer que el usuario actúe como le interesa a la empresa.


¿Qué son los dark patterns?

Los dark patterns —o patrones engañosos— son estrategias de diseño que buscan influir en el comportamiento del usuario sin su consentimiento real. Aprovechan sesgos, prisas o descuidos para que tomes decisiones que, probablemente, no hubieras tomado si el diseño fuera más transparente.

No son errores de diseño. Son trucos.
Y están por todas partes.


¿Por qué me interesa esto como diseñadora?

Porque muchas de estas prácticas pueden colarse sin darnos cuenta.
No porque las apliques a propósito, sino porque están tan normalizadas que ni te las cuestionas… hasta que te paras a mirarlas con lupa.

En mi caso, vengo del diseño gráfico y web más tradicional, donde siempre he buscado que el usuario se oriente bien y se sienta cómodo navegando. Pero al sumergirme ahora en el mundo del UX/UI con una mirada más estructurada, me doy cuenta de que el cómo diseñamos afecta más de lo que parece.

No quiero aplicar patrones que erosionen la confianza. Ni ahora, ni cuando no los conocía.
Y precisamente por eso me interesa tanto este tema: porque el primer paso para no usarlos… es reconocerlos.


Los más comunes (y peligrosos)

1. Confirmshaming

Usar la culpa para empujarte a aceptar algo.
Frases como: “No, prefiero seguir pagando de más” o “No quiero mejorar mi vida” en botones que deberían ser simplemente “No, gracias”.

2. Roach Motel

Fácil registrarte, difícil salir.
Suscripciones que puedes hacer con un clic pero que necesitas media hora y tres formularios para cancelar.

3. Forced Continuity

Después del período gratuito, te empiezan a cobrar sin avisarte. A veces sin darte opción clara de desactivar el servicio.

4. Misdirection

Diseños que te distraen de la opción que realmente quieres. Por ejemplo: un botón de “Aceptar” en color llamativo, mientras el de “Rechazar” está escondido en gris claro y tamaño pequeño.

5. Scroll infinito

Contenido que nunca termina. Puede parecer útil, pero a menudo genera fatiga, desorientación y sensación de no saber cuándo parar.


¿Es esto ético?

Muchos de estos patrones se siguen usando porque funcionan: aumentan clics, tiempo en pantalla, ventas… Pero lo hacen a costa de la confianza. Y eso, a la larga, es pan para hoy y hambre para mañana.

Diseñar de forma ética no significa renunciar a la conversión, sino equilibrar los objetivos del negocio con el respeto al usuario. Y eso empieza en los pequeños detalles: cómo se presenta una oferta, cómo se estructura una cancelación, cómo se da (o se esconde) una opción.


En resumen:

→ Los dark patterns no son errores, son decisiones.
→ Se basan en manipular, no en facilitar.
→ Pueden aumentar resultados a corto plazo, pero erosionan la confianza.
→ Aprender a detectarlos es el primer paso para no usarlos sin querer.
→ El diseño ético empieza en lo pequeño.


Fuentes e inspiración

Este artículo nace de muchas lecturas, podcasts y autores que están hablando de este tema con profundidad y visión crítica. Aquí te dejo algunos de los más interesantes que me han acompañado en este descubrimiento:

 

 

 

Descarga el mapa conceptual del post 
Para que tengas las ideas claras y ordenadas de un vistazo. [Enlace de descarga]