Órbita 1: Diseñar para que funcione Introducción

Introducción

El diseño de interfaces no consiste en hacer algo "bonito", sino en facilitar que el usuario logre sus objetivos de manera clara, rápida y sin fricciones. Esta órbita se centra en el diseño funcional: en pensar primero en tareas, flujos y estructura antes de aplicar cualquier decisión visual.

La interfaz es el puente entre el usuario y el sistema. Si ese puente está mal diseñado, el usuario se pierde, se frustra o abandona. Por eso, antes de decidir colores o tipografías, debemos entender para qué sirve la interfaz, qué necesita el usuario, y cómo debe estar organizada la información.

1. UX primero, UI después: pensar en funcionalidad

En el mundo del diseño web y de interfaces, es muy fácil dejarse llevar por lo visual. Muchas veces empezamos un proyecto pensando en el logo, los colores corporativos o los estilos tipográficos. Pero esta no es la forma más eficaz de construir una interfaz que realmente funcione.

El punto de partida siempre debe ser la funcionalidad: entender al usuario, identificar qué tareas necesita realizar, y diseñar una estructura que le permita lograr su objetivo sin frustración. Esto es lo que diferencia una interfaz atractiva pero inútil de una interfaz efectiva.

¿Qué es la UX y en qué se diferencia de la UI?

UX (User Experience) es la experiencia completa que tiene una persona al interactuar con una app, web o sistema. Abarca desde la lógica de navegación hasta cómo se siente al usarla: ¿es fácil?, ¿consigue lo que busca?, ¿se siente frustrado o satisfecho?
UI (User Interface) es el aspecto visual de la interfaz: botones, colores, iconos, tipografía, animaciones... Es la parte “visible”, pero no debe determinar el funcionamiento, sino estar al servicio del mismo.

Pensar primero en la UX significa diseñar desde las tareas, no desde los colores. Significa analizar qué necesita hacer el usuario y en qué orden, antes de decidir cómo se verá cada pantalla.

Las leyes de UX: principios para un diseño funcional

Los profesionales del diseño de experiencia de usuario trabajan apoyándose en principios basados en la psicología y el comportamiento humano. Estas leyes de UX nos ayudan a diseñar con más criterio. Aquí tienes algunas fundamentales:

1. Ley de Hick

Cuantas más opciones tiene una persona, más tarda en decidir.

Por eso es mejor simplificar. No muestres 12 botones cuando el usuario solo necesita 3. Un menú corto es más efectivo que uno con 15 categorías.

2. Ley de Fitts

El tiempo que se tarda en alcanzar un objetivo depende de su tamaño y cercanía.

En dispositivos móviles, los botones más usados deben ser grandes y estar al alcance del pulgar. No escondas funciones clave en esquinas lejanas.

3. Ley de Jakob

Las personas esperan que tu web/app funcione como las que ya conocen.

Esto no es malo: aprovecha los patrones familiares. Si un icono de carrito siempre está arriba a la derecha, no lo pongas en el pie de página sin motivo.

4. Ley de Tesler (Ley de la complejidad)

Cada sistema tiene una complejidad mínima. Si no la gestiona el diseñador, la asume el usuario.

Simplificar no es eliminar opciones, sino organizar bien la complejidad: agrupando, mostrando por pasos o usando asistentes.

5. Ley de Miller

El cerebro humano sólo puede procesar entre 5 y 9 elementos a la vez.

Si en una pantalla hay más de 9 cosas “gritando”, el usuario se bloquea. Usa jerarquía, espacios, agrupaciones y orden lógico.

Ejemplo práctico: app de comida a domicilio

Imaginemos que vamos a diseñar una aplicación de comida a domicilio similar a Glovo o Just Eat. En este tipo de apps, el objetivo del usuario es claro: pedir comida de forma rápida, cómoda y segura. Pero ¿cómo se traduce eso en pantallas funcionales? Para hacerlo bien, necesitamos pensar en términos de experiencia de usuario y responder a una serie de preguntas clave.

¿Qué es lo primero que necesita hacer el usuario al entrar?

Lo más probable es que quiera ver qué restaurantes tiene disponibles cerca. Por tanto, lo primero debería ser introducir su dirección o permitir la geolocalización. Si esa información ya está guardada, puede pasar directamente al listado de restaurantes.

Funcionalidad recomendada: una pantalla inicial con buscador de dirección o botón de “Usar mi ubicación”.

¿Debe buscar un restaurante, o iniciar sesión?

No debería ser obligatorio iniciar sesión para navegar y explorar opciones. Obligar al registro en el primer paso genera fricción. Es más recomendable dejarlo para el momento del pedido.

Funcionalidad recomendada: navegación libre por el catálogo; la sesión solo se solicita al confirmar el pedido.

¿Cómo se muestra la información del producto?

Cuando un usuario entra en un restaurante, lo que necesita ver es el menú clasificado, con nombre, descripción, precio, imagen opcional y un botón para añadir. No conviene mostrar demasiada información en bloque. Los platos deben estar organizados en categorías (entrantes, principales, postres...).

Funcionalidad recomendada: menú estructurado con listas claras, elementos clicables y opción de añadir al carrito directamente.

¿Cómo se simplifica el proceso de pago?

El pago debe requerir el menor número posible de pasos. Idealmente, se resume en una pantalla clara donde se pueda revisar el pedido, añadir dirección si no estaba guardada, elegir método de pago y confirmar.

Funcionalidad recomendada: pantalla de revisión con totales, dirección editable, opciones de pago guardadas o rápidas.

¿Dónde puede consultar su pedido actual?

El usuario debe tener acceso rápido al estado de su pedido. Lo más habitual es incluir un icono fijo de carrito (en la parte superior) que lleve directamente a la pantalla del pedido.

Funcionalidad recomendada: icono de carrito visible en todo momento, con número de productos y acceso directo al resumen.

Este tipo de análisis funcional es lo que permite construir una experiencia de usuario fluida, centrada en las tareas reales del usuario. El orden de los pasos, la visibilidad de la información y la simplicidad de las acciones son aspectos que definen una buena UX.

Una vez esté claro qué pantallas necesita el usuario, qué datos debe ver y cómo fluye la navegación entre ellas… entonces nos preocuparemos por los colores y la tipografía.

En resumen, el diseño funcional es la base de todo buen diseño de interfaz. Una buena experiencia de usuario es lo que hace que una app sea útil, clara y agradable. La interfaz visual debe servir a esa experiencia, no sustituirla ni taparla.

Enlaces de referencia

Actividad práctica en clase

Título: “Analizar y repensar la funcionalidad”

Divide al alumnado en pequeños grupos.
Cada grupo elegirá una app popular (puede ser Instagram, Amazon, Glovo, Duolingo...).
Deben responder por escrito:
¿Cuál es el objetivo principal del usuario?
¿Cuáles son los pasos que debe dar para lograrlo?
¿Qué elementos visuales lo ayudan o lo entorpecen?
¿Qué decisión de diseño visual no tiene sentido desde el punto de vista funcional?
Después, cada grupo debe proponer una mejora funcional (no estética) que haría más fácil o clara la experiencia del usuario.

Esta actividad puede completarse con una puesta en común o una presentación breve por grupo.

2. Patrones y antipatrones en el diseño de interfaces

Cuando diseñamos interfaces, no empezamos desde cero. Existen soluciones que ya han demostrado funcionar bien porque los usuarios las reconocen y entienden con facilidad. A esas soluciones las llamamos patrones de diseño. Un patrón es una estructura o mecanismo que se repite en múltiples sistemas porque ha probado ser eficaz y comprensible.

Por el contrario, a las malas soluciones —aquellas que generan confusión, dificultan la interacción o rompen expectativas— las llamamos antipatrones. Detectarlos y evitarlos es tan importante como aplicar los patrones correctos.

¿Qué es un patrón de diseño?

Un patrón de diseño es una solución probada a un problema común de interacción. No se trata de copiar diseños visuales, sino de identificar estructuras funcionales que los usuarios ya conocen y que permiten lograr tareas de forma clara y rápida.

Por ejemplo, cuando entras en una tienda online y ves un carrito en la esquina superior derecha, sabes automáticamente que ahí puedes consultar tus productos. Cuando ves una lupa, sabes que es para buscar. Estos elementos son familiares porque responden a convenciones que todos hemos aprendido usando cientos de webs y apps.

Utilizar patrones no es falta de originalidad: es una forma de respetar el tiempo, la atención y las expectativas del usuario.

Algunos patrones frecuentes:

Menú de navegación fijo en la parte superior
Icono de hamburguesa para desplegar el menú en móvil
Carrito de compra visible con número de artículos
Cards o tarjetas con información agrupada (producto, noticia, perfil…)
Botón de acción principal destacado (como el botón azul de “publicar” en redes)
Sistema de pasos progresivos (checkout, formularios…)

Estos patrones no son normas cerradas, pero ayudan a construir una experiencia intuitiva.

¿Qué es un antipatrón?

Un antipatrón es una solución mal aplicada o inadecuada que provoca errores, malentendidos o fricciones en la experiencia del usuario. A menudo surgen por intentar ser “demasiado creativos” sin pensar en las consecuencias.

Los antipatrones rompen las expectativas del usuario, hacen que tenga que “pensar demasiado” o provocan errores evitables.

Algunos ejemplos de antipatrones comunes:

Usar solo placeholders sin etiquetas en los formularios: si desaparecen al escribir, el usuario olvida qué tenía que poner.
Botones que parecen texto y no se distinguen como clicables.
Formularios con errores ocultos o sin mensajes de validación claros.
Menús ocultos sin pistas visuales: el usuario no sabe cómo navegar.
Campos obligatorios que no están marcados como tales.
Cambios bruscos de diseño o comportamiento entre pantallas similares.

¿Cómo detectar y aplicar patrones de forma consciente?

Aplicar patrones no significa copiar ciegamente otros productos. Significa entender qué quiere hacer el usuario y cuál es la forma más clara de ayudarle a hacerlo. Un buen diseñador es capaz de adaptar patrones al contexto concreto de su app.

De la misma forma, evitar antipatrones exige observar críticamente otros productos, probar las soluciones propias con usuarios reales y cuestionar si algo realmente funciona o solo “parece bonito”.

Recursos de referencia

Si quieres explorar colecciones reales de patrones y estudiar cómo se aplican en apps y webs actuales, te recomiendo estos sitios:

UI Patterns: recopilación de patrones con explicación de cuándo usarlos.
Mobbin: biblioteca visual con miles de capturas de apps reales clasificadas por componentes.
PageFlows: vídeos reales de flujos de usuario dentro de apps conocidas.
Pttrns: ejemplos de interfaces móviles organizadas por patrones.
GoodUI: colección de ideas de interfaz que han funcionado bien en tests reales.

Actividad práctica en clase

Título: “Caza de patrones y antipatrones”

El alumnado visitará User Inyerface, una web intencionadamente mal diseñada.
En parejas o grupos, deben identificar al menos tres antipatrones que dificultan la interacción.
Por cada antipatrón encontrado, deben explicar:
Qué problema genera.
Por qué rompe con las expectativas del usuario.
Qué patrón correcto se podría aplicar para resolverlo.
Como complemento, pueden buscar dos patrones positivos en una app real que les guste (Spotify, TikTok, Airbnb, etc.) y explicar por qué funcionan.

Con esta actividad nor permite desarrollar el pensamiento crítico y aplicar conceptos de forma práctica. Podemos cerrar con una puesta en común o una galería de ejemplos comentados en el aula. (dependiendo del tiempo que tengamos).

3. Arquitectura de la información: ordenar para entender

Cuando una persona entra en una web o app, no espera tener que explorar a ciegas. Necesita encontrar lo que busca con rapidez y saber dónde está en todo momento. Para que esto sea posible, el contenido debe estar bien estructurado. Esa estructura lógica, jerárquica y funcional es lo que llamamos arquitectura de la información (IA).

Diseñar una interfaz no es sólo decidir cómo se ve una pantalla, sino cómo se relacionan entre sí las distintas pantallas, cómo se agrupa el contenido y qué rutas puede seguir el usuario para llegar a su objetivo.

¿Qué es exactamente la arquitectura de la información?

La arquitectura de la información es la disciplina que se encarga de organizar, etiquetar y jerarquizar los contenidos de un sistema para facilitar su uso y comprensión. Se aplica tanto a webs como a apps, e incluso a sistemas físicos como museos o supermercados.

En el diseño web, la arquitectura de la información responde a preguntas como:

¿Cuántas secciones principales hay?
¿Qué subsecciones dependen de cada una?
¿Dónde colocamos ciertas funcionalidades o tipos de contenido?
¿Qué estructura de navegación es la más clara para este producto?

Una buena arquitectura de la información no siempre se nota, pero una mala se sufre al instante: el usuario se pierde, no encuentra lo que busca o repite pasos innecesarios.

Elementos clave en la arquitectura de información

Hay muchos recursos y técnicas que se usan para representar y planificar la arquitectura de la información de un producto digital. Algunos de los más habituales son:

1. Mapa de navegación o sitemap

Es un esquema que muestra cómo se relacionan todas las pantallas o secciones. Permite ver de un vistazo la jerarquía de contenidos. En Figma o Miro, se puede representar con cajas y líneas.

2. Agrupación por categorías

El contenido debe estar organizado por bloques coherentes. Por ejemplo, en una app de viajes: “vuelos”, “hoteles”, “actividades” y “mi cuenta”. Si las categorías no están claras, el usuario se confunde.

3. Breadcrumbs o migas de pan

Permiten mostrar al usuario en qué punto exacto está dentro de la jerarquía. Por ejemplo: Inicio > Productos > Electrónica > Portátiles.

4. Menús y sistemas de navegación

La arquitectura también define cómo se accede a cada sección: ¿desde un menú lateral? ¿con iconos inferiores? ¿mediante pestañas?

Principios de Dan Brown para la Arquitectura de la Información.

El experto Dan Brown propuso siete principios que ayudan a construir una buena arquitectura de información:

Objetividad: no diseñar para nosotros, sino para el usuario.
Organización: los elementos deben agruparse según su lógica, no su estética.
Navegabilidad: el usuario siempre debe saber dónde está y cómo volver.
Contexto: cada sección debe tener sentido por sí misma.
Trazabilidad: permitir al usuario seguir el rastro de su navegación.
Consistencia: usar el mismo tipo de estructura y lenguaje en todo el sistema.
Economía: no abrumar con opciones innecesarias; menos es más.

Ejemplo práctico: una app de gestión de tareas

Imaginemos una app que permite al usuario crear tareas, organizarlas por proyectos y hacer seguimiento del progreso.

Las secciones principales podrían ser: “Inicio”, “Proyectos”, “Tareas”, “Calendario” y “Cuenta”.
Dentro de “Proyectos” habría una lista de proyectos y, al entrar en uno, las tareas correspondientes.
La navegación incluiría un menú inferior con iconos y un botón flotante para crear una nueva tarea desde cualquier parte.
El usuario debería poder ver fácilmente en qué proyecto está y volver atrás sin perderse.

Diseñar esta estructura antes de hacer wireframes evita improvisaciones y facilita la coherencia del producto.

Recursos de referencia

Information Architecture Basics (NNGroup)
Dan Brown – Seven principles of IA
UX Collective – What is Information Architecture?
Miro templates para IA: mapas de navegación, árboles de contenido, etc.

Actividad práctica en clase

Título: “Construye tu mapa de navegación”

Cada grupo trabajará sobre la app que están diseñando en el proyecto práctico.
Deberán elaborar un mapa de navegación que incluya:
Secciones principales
Subpantallas o funcionalidades internas
Relaciones entre páginas
Usarán papel o Figma para representarlo visualmente.
Como extensión, deberán justificar por escrito:
Por qué han agrupado así el contenido
Qué flujo principal sigue el usuario
Cómo se evita que el usuario se pierda

Esta actividad nos va a servir como paso previo obligatorio antes de crear wireframes, que será el siguiente punto que veamos.

4. Wireframes de baja fidelidad: pensar con bocetos

Una vez definida la estructura lógica de la app y organizada su arquitectura de información, llega el momento de representar visualmente las pantallas. Pero aún no es momento de elegir colores, ilustraciones ni tipografías. Lo que necesitamos ahora es probar la funcionalidad con el menor coste posible. Para eso sirven los wireframes de baja fidelidad.

Un wireframe es un esquema visual que representa cómo se distribuyen los elementos en una pantalla. En su versión de baja fidelidad, está despojado de detalles visuales innecesarios: no hay imágenes reales, ni sombras, ni estilos sofisticados. El foco está en la funcionalidad: qué hay en cada sitio, qué se puede hacer y cómo se conecta con otras partes del sistema.

¿Por qué son tan importantes?

Fomentan la iteración: como son rápidos de hacer, podemos probar varias versiones sin miedo a equivocarnos.
Ahorran tiempo y recursos: permiten validar ideas antes de invertir en diseño visual o desarrollo.
Facilitan el diálogo: ayudan a que el equipo (y los usuarios) puedan entender cómo funcionará el sistema sin necesidad de explicaciones técnicas.

El objetivo de esta etapa no es tener algo bonito, sino tener algo que funcione en papel.

¿Cómo se construyen?

Un wireframe puede hacerse a mano, con lápiz y papel, o con herramientas digitales como Figma, Balsamiq, Whimsical o incluso PowerPoint. Lo importante es que el diseño:

Muestre la jerarquía de la información.
Incluya los elementos funcionales (botones, inputs, menús…).
Mantenga una estructura coherente con la arquitectura de información.
Es fácil de entender para cualquier persona, aunque no tenga estilos aplicados.

Buenas prácticas

Usa cuadrados y líneas básicas para representar secciones y botones.
Añade etiquetas y comentarios breves si algún elemento no se entiende.
Asegúrate de que haya flujo entre pantallas (por ejemplo, del login al dashboard).
Trabaja con plantillas reutilizables si tu app tiene estructuras repetidas.

Ejemplo práctico: pantalla de registro en una app de recetas

Un wireframe de esta pantalla incluiría:

Un título principal: “Crear cuenta”
Tres campos de texto: email, contraseña, repetir contraseña
Un botón grande y claro para enviar
Un enlace inferior: “¿Ya tienes cuenta? Inicia sesión”
Nada más: sin logos, colores, ni imágenes decorativas

Esto basta para probar si el flujo de registro funciona y si es comprensible.

Recursos de referencia

Wireframing with Figma
Balsamiq Wireframes (gratuito con prueba)
Mockflow
Material Design Wireframe Kit (componentes de Google Material para wireframes)
UXPin Guide to Wireframing

Actividad práctica en clase

Título: “Bocetar antes de construir”

Cada grupo tomará el mapa de navegación que haya creado previamente (actividad del punto 3).
A partir de ese mapa, elaborará los wireframes de al menos cuatro pantallas clave de su app.
Los wireframes podrán hacerse:
A mano (en hojas de trabajo proporcionadas)
En Figma, con formas básicas
Deberán añadir anotaciones mínimas para explicar el propósito funcional de cada pantalla.
Por último, deberán hacer un pequeño recorrido en clase explicando el flujo que sigue el usuario.

Esta actividad forma parte del entregable obligatorio del proyecto práctico. Servirá como base para el prototipo navegable del punto siguiente.

Perfecto. Aquí tienes el punto 5 redactado con el mismo estilo, profundidad y tono que el punto 4. Lo he estructurado de forma progresiva, explicativa y con ejemplos, recursos y actividad final para clase.

5. Prototipado navegable lo-fi: simular antes de construir

Una vez tenemos los wireframes de baja fidelidad que representan la estructura funcional de nuestra app, el siguiente paso es hacerlos interactivos. Es decir, convertir esos bocetos estáticos en un prototipo navegable, que permita simular cómo sería la experiencia real del usuario al moverse entre pantallas.

Este tipo de prototipos no son todavía productos terminados ni tienen estilos visuales definitivos. Son maquetas funcionales que ayudan a comprobar si los flujos tienen sentido, si las acciones están claras y si la navegación es intuitiva.

Antes de escribir una sola línea de código, debemos tener claro que la estructura de la app funciona. Y la mejor forma de comprobarlo es navegándola.

¿Qué es un prototipo navegable?

Un prototipo navegable es una simulación interactiva de una aplicación o sitio web, en la que se pueden realizar acciones como hacer clic en botones, cambiar de pantalla o simular una interacción básica.

No se trata de una app real, pero se comporta como si lo fuera, permitiendo recorrer sus pantallas como lo haría un usuario final.

¿Para qué sirve un prototipo navegable?

Validar la experiencia de usuario sin necesidad de desarrollo.
Detectar errores en el flujo o confusiones en la interacción.
Testear con usuarios reales o con otros grupos.
Comunicar la propuesta de forma clara a personas no técnicas.

¿Cómo se construye?

En herramientas como Figma, el proceso es sencillo:

Crear un archivo con los frames de cada pantalla (por ejemplo, los wireframes).
Ir a la pestaña Prototype y enlazar elementos interactivos:
Botones que llevan a otras pantallas
Íconos que abren menús
Áreas clicables que simulan navegación
Ajustar transiciones, animaciones básicas o efectos simples si es necesario.
Compartir el prototipo mediante un link interactivo para que otros puedan probarlo.

Buenas prácticas para prototipos navegables

No añadas estilos visuales si aún no están definidos: céntrate en la lógica funcional.
Usa nombres claros para las pantallas: “Login”, “Home”, “Carrito”, etc.
Asegúrate de que todas las acciones posibles estén conectadas a algún resultado visible.
Simula solo lo necesario para validar el flujo: menos es más en esta fase.
Si algo no funciona aún, indícalo como “pantalla en desarrollo” o “interacción no implementada”.

Ejemplo práctico: app de recetas

Supongamos que ya tenemos wireframes para estas pantallas:

Pantalla de inicio (buscar recetas)
Ficha de receta
Registro de usuario
Crear receta

Ahora en Figma enlazamos:

El botón de “Buscar” lleva a una lista de resultados.
Cada resultado lleva a la ficha de receta.
Desde cualquier pantalla se puede ir al registro.
El botón de “Crear receta” abre un formulario básico.

El resultado es un flujo de navegación funcional que podemos probar, enseñar y corregir antes de empezar a programar.

Recursos de referencia

Actividad práctica en clase

Título: “Prototipa tu idea”

Cada grupo partirá de los wireframes creados en el punto anterior y los transformará en un prototipo navegable.

Instrucciones:

Usarán Figma (u otra herramienta pactada) para montar sus pantallas.
Enlazarán botones y elementos interactivos para simular al menos dos flujos completos de usuario (por ejemplo: buscar > ver > añadir, o registro > login > inicio).
Compartirán el enlace del prototipo con otros grupos.
Cada grupo hará una prueba cruzada: usar el prototipo de otro grupo y dejar comentarios sobre la claridad del flujo.

Objetivo de la actividad:

Comprobar si el diseño funciona sin explicaciones externas.
Detectar puntos de confusión o pantallas innecesarias.
Preparar la validación del diseño antes del desarrollo.

Este prototipo es el entregable funcional previo al desarrollo. Su validación es parte del proceso iterativo del proyecto conjunto.

6. MVP: centrarse en lo esencial

Una vez que hemos definido la arquitectura de la información, diseñado los wireframes y creado un prototipo navegable que represente el flujo funcional de nuestra aplicación, es el momento de tomar una decisión estratégica: ¿qué funcionalidades deben implementarse primero?

En esta etapa, entra en juego el concepto de MVP, siglas de Minimum Viable Product, que podríamos traducir como “Producto Mínimo Viable”. Aunque proviene del mundo del desarrollo ágil y las startups, este concepto es perfectamente aplicable a proyectos educativos y de diseño, ya que nos obliga a priorizar lo funcional frente a lo estético y lo imprescindible frente a lo accesorio.

¿Qué es exactamente un MVP?

Un MVP es una versión funcional de una aplicación que incluye solo las funcionalidades mínimas necesarias para que el usuario pueda completar su objetivo principal. No se trata de un prototipo estático ni de una maqueta visual, sino de una simulación funcional que, aun con diseño básico, permite al usuario realizar una tarea significativa.

El propósito del MVP no es demostrar lo bonito que puede ser el producto final, sino validar si la solución propuesta tiene sentido, si es comprensible y si realmente resuelve el problema del usuario.

En contextos reales, lanzar un MVP permite recoger feedback temprano, corregir errores y evitar perder tiempo desarrollando funcionalidades que el usuario tal vez no necesita. En nuestro caso, nos sirve para comprobar si el diseño funcional que hemos planificado es claro, lógico y eficiente.

¿Por qué es tan importante en el diseño funcional?

El MVP es una herramienta poderosa para enfocar el diseño desde la funcionalidad. Su valor reside en varios aspectos clave:

Evita sobrecargar el diseño y desarrollo inicial con funcionalidades que pueden esperar.
Permite validar decisiones funcionales sin depender aún de un diseño visual definitivo.
Fomenta la iteración basada en pruebas reales y no en suposiciones.
Ahorra tiempo y recursos, algo especialmente útil en proyectos educativos con plazos y recursos limitados.

Un buen MVP no es una versión “recortada” de la app final. Es una versión estratégica, pensada para cumplir el objetivo principal del usuario con la mayor claridad posible.

¿Cómo definimos un MVP?

La clave para definir un MVP es tener claridad sobre qué quiere lograr el usuario y qué necesita como mínimo para lograrlo. Esto se puede abordar en varias fases:

Identificar el objetivo principal del usuario
Preguntarse: ¿Qué tarea quiere realizar el usuario? ¿Cuál es el núcleo de la experiencia?
Dibujar el flujo mínimo funcional
¿Qué pasos necesita seguir el usuario, desde el inicio hasta lograr su objetivo? Eliminar todo lo que no sea imprescindible.
Filtrar funciones secundarias
Hacer una distinción clara entre lo esencial (que sí entra en el MVP) y lo accesorio (que puede añadirse más adelante).
Validar el flujo con el usuario o con otros grupos
Comprobar si se entiende, si funciona y si permite completar la tarea sin bloqueos.

Ejemplo práctico: app de recetas

Imaginemos que estamos diseñando una app de recetas.

Objetivo principal del usuario: encontrar una receta y leerla con claridad.

MVP mínimo:

Pantalla con buscador de recetas.
Listado de resultados.
Ficha de receta con ingredientes y pasos.

Lo que no entra en el MVP:

Registro de usuario.
Subida de recetas.
Guardar favoritas.
Valoraciones o comentarios.

Aunque estas funciones serán útiles más adelante, no son necesarias para que el usuario logre su objetivo principal en esta primera versión.

¿Qué se entrega como MVP en esta órbita?

En el proyecto práctico asociado a esta órbita, se pide al alumnado que construya y documente su MVP a través de los siguientes elementos:

Mapa del flujo MVP, representado en Miro, Figma o incluso en papel digitalizado. Debe mostrar claramente los pasos que sigue el usuario.
Tabla de funcionalidades, donde se especifique qué entra en el MVP y qué se pospone para futuras versiones. Esta tabla debe ir acompañada de una breve justificación de las decisiones tomadas.
Prototipo navegable en Figma del MVP. Debe incluir como mínimo tres pantallas funcionales enlazadas, que permitan simular la experiencia del usuario realizando su tarea principal.

Recursos recomendados para ampliar

Actividad práctica en clase

Título: “Priorizar para construir”

Objetivo: Aprender a definir el MVP de una aplicación y justificarlo desde la funcionalidad.

Desarrollo:

Cada grupo parte de su mapa de navegación y wireframes previos.
Identifican el objetivo principal del usuario en su app.
Elaboran una tabla que diferencie:
Funcionalidades esenciales (incluidas en el MVP)
Funcionalidades complementarias (para versiones futuras)
Representan el flujo MVP en una herramienta de su elección.
Presentan el flujo y la tabla, justificando qué entra y por qué.

Esta actividad refuerza la idea de que el diseño no debe nacer desde la ambición estética o la acumulación de ideas, sino desde una estrategia funcional clara y enfocada en el usuario.

7. Componentes funcionales (Atomic Design): construir piezas reutilizables

Una vez que tenemos claro el MVP, los flujos funcionales y los wireframes que estructuran la aplicación, es el momento de identificar qué partes se repiten y pueden convertirse en componentes reutilizables. Este es un paso crucial en cualquier sistema de diseño moderno, ya que permite crear una interfaz coherente, mantenible y escalable.

Aquí es donde entra en juego la metodología Atomic Design, propuesta por Brad Frost. Esta técnica nos ayuda a organizar los elementos de la interfaz como si fueran piezas de un sistema: desde los más simples a los más complejos, con el objetivo de que puedan reutilizarse de forma lógica y eficiente.

¿Qué es exactamente Atomic Design?

Atomic Design propone una jerarquía de cinco niveles que nos permite dividir y estructurar cualquier interfaz de manera modular:

Átomos: son los elementos más básicos e indivisibles de la interfaz, como un botón, un campo de texto o una etiqueta.
Moléculas: combinaciones simples de átomos que trabajan juntas para cumplir una función. Un buen ejemplo sería un formulario de búsqueda compuesto por un input y un botón.
Organismos: conjuntos complejos y funcionales de moléculas y átomos. Por ejemplo, una cabecera con logo, menú de navegación y buscador.
Templates: estructuras de páginas con componentes distribuidos según una jerarquía definida. Sirven de base para organizar contenido.
Pages: instancias reales del diseño con contenido definitivo, que permiten verificar cómo se comporta todo en conjunto.

Este enfoque no sólo aporta orden, sino que también permite detectar inconsistencias, reducir el número de elementos redundantes y facilitar la colaboración entre diseñadores y desarrolladores.

¿Por qué es útil aplicar Atomic Design incluso antes de tener los estilos visuales definidos?

Puede parecer extraño construir una librería de componentes sin haber definido todavía los colores, tipografías o espaciados. Sin embargo, este enfoque funcional tiene varias ventajas:

Permite iterar antes de definir estilos, centrándonos en cómo funciona la interfaz y no en cómo se ve.
Ayuda a validar interacciones y estructuras de forma rápida, sin necesidad de cerrar detalles estéticos.
Fomenta una mentalidad de diseño sistemático, que facilita el trabajo colaborativo y reduce errores futuros.

Más adelante, cuando se definan los estilos globales (en la siguiente órbita), bastará con aplicar esas decisiones al sistema ya creado, en lugar de rediseñar cada pantalla desde cero.

Construir una librería funcional en Figma

Figma permite trabajar con componentes y variantes de forma nativa. Podemos crear, nombrar, organizar y reutilizar elementos con facilidad, agrupándolos según la jerarquía de Atomic Design. Por ejemplo, un botón puede tener varias variantes: normal, con icono, desactivado…

A medida que los grupos trabajan en sus apps, pueden ir creando una página de componentes dentro de su archivo. Esta página servirá como inventario funcional y como base para el diseño visual futuro.

Es importante que cada componente tenga un nombre claro, una función definida y, si es posible, una pequeña documentación de uso. Esto hace que el sistema sea comprensible para cualquiera que lo revise.

Herramientas y extensiones útiles

Para organizar y mantener bien estructurado el sistema de componentes en Figma, existen algunas herramientas y plugins recomendables:

Instance Finder: permite localizar todas las instancias de un componente, útil para evitar duplicidades.
Design System Organizer: ayuda a categorizar los componentes y mantener una jerarquía clara.
Themer: aunque más avanzado, permite gestionar tokens de diseño como colores o espaciados, incluso antes de definirlos.
Styler: útil para auditar estilos y preparar la transición a diseño visual.
Figma Tokens: para quienes quieran trabajar con variables desde fases tempranas del proyecto.

Estos recursos no son obligatorios, pero pueden facilitar mucho la tarea de mantener un diseño funcional coherente.

Ejemplo práctico: identificar componentes en una app de recetas

Supongamos que hemos diseñado las primeras pantallas de una app de recetas. Podemos observar que hay varios elementos que se repiten: botones, campos de búsqueda, tarjetas con imagen y texto, menús flotantes…

El primer paso sería crear un inventario con estos elementos, clasificarlos por nivel (átomo, molécula, organismo) y construirlos como componentes reutilizables en Figma. Por ejemplo:

Átomos: botón, campo de texto, etiqueta
Moléculas: buscador, tarjeta de receta
Organismos: cabecera, listado de recetas, menú inferior

Estos elementos se pueden usar en múltiples pantallas, garantizando coherencia funcional.

Actividad práctica en clase: “Construcción del sistema de componentes”

Cada grupo revisará su prototipo funcional e identificará al menos cinco componentes reutilizables. En una nueva página de su archivo de Figma:

Construirán esos componentes y los clasificarán según Atomic Design.
Añadirán etiquetas y una breve descripción funcional.
Definirán al menos una variante para cada uno (por ejemplo: activo / inactivo).

Esta actividad no requiere todavía aplicar estilo visual. Su objetivo es estructurar la interfaz funcional como un sistema reutilizable. Además, este sistema servirá de base directa para la siguiente órbita, donde sí aplicaremos colores, tipografías y guías de estilo.

8. Estudios de caso y actividades recomendadas

Una vez que hemos recorrido todas las etapas del diseño funcional —desde la definición de la arquitectura hasta la creación de un MVP navegable— es fundamental cerrar el proceso con una mirada crítica y aplicada. La mejor forma de reforzar lo aprendido es analizar cómo lo hacen otros, descomponer ejemplos reales, detectar buenas (y malas) prácticas, y, sobre todo, aplicar activamente lo aprendido en un entorno seguro como el aula.

Este último bloque de la órbita no introduce nuevos conceptos teóricos, sino que se centra en afianzar conocimientos a través de la observación, la práctica comparativa y la iteración controlada.

Analizar para aprender: desmontar interfaces reales

A menudo, los mejores aprendizajes no vienen de hacer, sino de entender cómo están hechas las cosas que ya usamos cada día. Instagram, Spotify, Airbnb, TikTok o Amazon no son productos perfectos, pero son ejemplos muy ricos desde el punto de vista de la experiencia de usuario. Están llenos de patrones bien aplicados, flujos funcionales bien resueltos y también —en ocasiones— decisiones discutibles.

El ejercicio consiste en mirar con ojos de diseñador: ¿cómo está estructurada esta pantalla?, ¿qué espera el usuario?, ¿dónde se encuentran los patrones?, ¿dónde aparecen antipatrones?, ¿es clara la arquitectura?, ¿hay MVP reconocible?, ¿qué elementos funcionales se repiten?

Este tipo de análisis activa el pensamiento crítico, refuerza los conceptos estudiados y ayuda a crear un lenguaje común en el aula.

Actividades propuestas para clase

1. Web Without Words

Utiliza webwithoutwords.com, una herramienta que elimina todo el texto de una web real y muestra solo su estructura visual. El alumnado debe:

Identificar la jerarquía visual y funcional.
Suponer qué contenido podría ir en cada bloque.
Justificar cómo se guía la atención del usuario.

Este ejercicio obliga a centrarse en la estructura, no en el contenido, y demuestra la importancia del diseño funcional.

2. Desmontar apps

En grupos, el alumnado elige una app conocida (como Duolingo, Netflix, Glovo o Notion) y debe:

Dibujar su mapa de navegación aproximado.
Identificar patrones y antipatrones.
Detectar cuál podría ser el MVP original de esa app.
Justificar decisiones funcionales observadas.

Opcionalmente, se puede proponer que esbocen una mejora de usabilidad o un rediseño de un flujo concreto.

3. Galería de patrones con Mobbin o UI Patterns

Mobbin (mobbin.com) y UI Patterns (ui-patterns.com) son bibliotecas visuales con capturas de miles de apps y webs. En esta actividad:

El alumnado busca ejemplos de un patrón funcional concreto (por ejemplo: onboarding, buscador, flujo de compra).
Recopilan dos ejemplos buenos y uno malo.
Explican qué les hace efectivos o problemáticos.

Este ejercicio ayuda a aprender no copiando visualmente, sino comprendiendo la lógica funcional detrás de cada decisión.

4. Revisión cruzada de MVPs

Cuando cada grupo haya definido su MVP y prototipo funcional, se organiza una ronda de revisión cruzada. Cada grupo analiza el MVP de otro grupo, respondiendo preguntas como:

¿Se entiende el flujo?
¿Es claro el objetivo del usuario?
¿Falta alguna funcionalidad esencial?
¿Sobran pasos o hay elementos innecesarios?

El objetivo no es criticar, sino entrenar la mirada profesional para detectar problemas y mejorar el propio trabajo.

5. Pitch funcional en clase

Cada grupo presenta brevemente su MVP a modo de pitch, pero sin centrarse en lo visual, sino en lo funcional:

¿Qué hace su app?
¿Qué funcionalidades han incluido en el MVP?
¿Por qué han decidido dejar fuera otras?
¿Cómo han resuelto el flujo de usuario principal?

Este ejercicio entrena la comunicación técnica y ayuda al alumnado a defender decisiones de diseño con criterio, no con gusto personal.

Recursos recomendados

PageFlows – Vídeos de flujos reales de usuario en apps.
UI Garage – Ejemplos visuales clasificados por componentes.
Mobbin – Biblioteca visual de interfaces móviles reales.
UX Archive – Evolución de flujos funcionales en apps famosas.
Web Without Words – Webs sin texto para analizar estructuras.

Conclusión de la órbita

Con este bloque de actividades se cierra la primera órbita del curso: diseñar para que funcione. El alumnado ha aprendido que el diseño no empieza con colores ni logos, sino con tareas, flujos, decisiones estratégicas y estructuras claras. También ha comprendido la importancia de los patrones, el valor del wireframing como herramienta de validación temprana, y la necesidad de construir primero lo esencial antes de avanzar hacia lo estético.

Aquí no termina el diseño: aquí empieza el ciclo de mejora. A partir de ahora, entraremos en aspectos visuales, guías de estilo, diseño responsive, accesibilidad y usabilidad avanzada. Pero todo lo que venga tendrá sentido solo si lo funcional ya está resuelto.