Usamos cookies

Utilizamos cookies propias y de terceros para analizar el tráfico y mejorar tu experiencia. Puedes aceptarlas o rechazarlas. Política de privacidad.

Saltar al contenido
—Guías

Prototipado interactivo: de baja a alta fidelidad y cuándo usar cada uno

Por
Juan Navarro
Lectura
11 min
Publicado
10 de agosto de 2026

Un prototipo es una pregunta hecha con forma de producto. Elegir bien su fidelidad es elegir bien qué quieres aprender, con quién y en cuánto tiempo.

Hace unos años diseñamos el área de clientes de una empresa de alquiler vacacional. En la reunión de presentación, con las pantallas impresas en la mesa, todo el mundo estaba de acuerdo: el flujo para modificar una reserva era claro. Al día siguiente montamos un prototipo navegable con las mismas pantallas y se lo dimos a cinco propietarios reales. Cuatro de ellos buscaron el botón de modificar en la ficha del apartamento, no en la reserva. En el papel, la lógica era impecable. En la mano, la gente pensaba de otra manera.

Para eso sirve un prototipo interactivo. Las pantallas estáticas se miran; los prototipos se usan, y al usarlos aparecen cosas que mirando nunca salen. La buena noticia es que no hace falta construir un producto casi terminado para aprender. A veces basta con unos papeles y diez minutos; otras sí merece la pena un prototipo pulido con animaciones y datos reales. Saber cuál toca en cada momento es la habilidad que esta guía quiere darte.

01Qué es un prototipo y qué no es

Un prototipo es una representación de un producto que se puede experimentar antes de construirlo. Puede ser de papel, de Figma o de código. Lo que lo define no es el material sino el propósito: responder una pregunta concreta con el menor esfuerzo posible.

En 1997, Stephanie Houde y Charles Hill publicaron un artículo de referencia, What do prototypes prototype?, que propone pensar cualquier prototipo según qué explora:

  • El papel: qué hace el producto en la vida de la persona y si encaja con su necesidad.
  • El aspecto y la sensación (look and feel): cómo se ve, cómo se siente al tocarlo, qué transmite.
  • La implementación: si técnicamente se puede hacer y cómo se comporta con datos reales.

Esta idea sigue siendo la mejor brújula. Un prototipo que intenta responder a las tres a la vez acaba siendo caro y lento. Uno que se centra en una, y la responde bien, cumple su función.

Conviene distinguirlo también de sus vecinos. Un wireframe es un esquema estático de estructura; un mockup, una imagen estática con el aspecto final. Ambos pueden convertirse en prototipo en cuanto se conectan y se pueden recorrer.

02Las dimensiones de la fidelidad

Solemos hablar de «baja» y «alta» fidelidad como si fuera una sola escala, pero en realidad son varias que se combinan con libertad:

DimensiónBajaAlta
VisualCajas grises, tipografía genérica, sin imágenesDiseño final con marca, color e imágenes
ContenidoLorem ipsum o etiquetas genéricasTextos y datos reales o muy verosímiles
InteractividadClics que saltan entre pantallasEstados, animaciones, campos que se rellenan, lógica
AmplitudUn solo camino felizVarios caminos, errores, casos límite
MedioPapel o pizarraDispositivo real, en contexto

La combinación más infravalorada es la de visual bajo y contenido alto: pantallas sencillas, en grises, pero con los textos reales. Nielsen Norman Group insiste a menudo en que el contenido es lo que más influye en cómo la gente entiende una interfaz, y un prototipo con textos de verdad revela muchos más problemas que uno precioso con lorem ipsum.

03Baja fidelidad: aprender rápido y barato

Papel y bocetos

Dibujar pantallas a mano en fichas o en papel y «simular» la interfaz cambiando papeles cuando la persona señala un botón sigue funcionando sorprendentemente bien. Es ideal en las primeras horas de un proyecto, cuando aún se discute qué pantallas existen y en qué orden.

Su gran virtud es psicológica: nadie se encariña con un boceto, así que se tira y se rehace sin pena, y la persona que lo prueba se siente libre de criticarlo.

Wireframes navegables

El siguiente paso son wireframes en Figma, Balsamiq o similar, enlazados entre sí. Con un par de horas de trabajo tienes un flujo completo que se puede probar en el móvil. Responde preguntas de estructura: ¿se entiende la navegación?, ¿en qué orden espera la gente los pasos?, ¿falta alguna pantalla?

Cuándo usar baja fidelidad:

  • Al comparar varias ideas de flujo muy distintas.
  • Al validar la arquitectura de la información o la navegación.
  • Cuando el equipo todavía no está de acuerdo en qué hace el producto.
  • Cuando quieres que el cliente opine de la lógica y no del color.

04Media y alta fidelidad: sentir el producto

Media fidelidad

Pantallas con la jerarquía y el espaciado reales, tipografía definida y contenido verdadero, pero aún sin todos los detalles visuales. Es el punto en el que más tiempo pasamos en el estudio, porque equilibra velocidad y realismo. Permite hacer tests de usabilidad muy fiables sobre tareas concretas.

Alta fidelidad

Diseño final, componentes con todos sus estados, transiciones y, si hace falta, lógica: un carrito que suma, un filtro que reduce resultados, un formulario que valida. Figma permite hoy bastante de esto con variables, condicionales y expresiones, lo que hace que un prototipo pueda recordar lo que la persona ha elegido en pantallas anteriores.

Cuándo usar alta fidelidad:

  • Al probar microinteracciones, animaciones o gestos donde la sensación es lo que se evalúa.
  • Al validar la respuesta emocional a la marca dentro del producto.
  • Al presentar a inversores, dirección o socios que necesitan «ver» el producto.
  • Como especificación para desarrollo, junto a la documentación.
  • En tests donde los detalles visuales influyen en la tarea (por ejemplo, distinguir dos tipos de producto por su etiqueta).

05Herramientas: qué usar en cada caso

HerramientaMejor paraLímites
Papel y fichasPrimeras ideas, talleres con clienteNo se puede probar a distancia
Figma (prototipado)Flujos navegables, media y alta fidelidad, con variables y condicionalesLa interacción compleja con datos se complica
ProtoPieInteracciones ricas, sensores, gestos, prototipos multi-dispositivoCurva de aprendizaje propia
FramerPrototipos web muy realistas que pueden publicarseOrientado sobre todo a web
Prototipo en código (HTML, React)Datos reales, rendimiento, interacción compleja, accesibilidad realMás tiempo y perfil técnico
Herramientas de IA generativaVersiones funcionales rápidas a partir de una descripción o un diseñoRequieren revisión de marca, accesibilidad y lógica

En los últimos años han aparecido herramientas que generan prototipos funcionales en código a partir de una descripción o de un diseño en Figma. Son un acelerador fantástico, sobre todo para interacciones que en Figma serían laboriosas. Las usamos con una regla: la pregunta, el flujo y la decisión final las pone una persona; la herramienta construye más rápido lo que el criterio ya ha decidido.

Una técnica clásica: el Mago de Oz

Cuando la funcionalidad es difícil de construir (un asistente que responde, un buscador inteligente, una recomendación personalizada), se puede simular con una persona «detrás de la cortina» que genera las respuestas en tiempo real mientras el participante cree que es el sistema. Es una forma muy barata de validar si la idea tiene sentido antes de invertir en tecnología.

06Cómo construir un prototipo útil, paso a paso

Este es el proceso que seguimos para un prototipo de test:

  1. Escribe la pregunta. «¿Encuentran los propietarios cómo modificar una reserva en menos de un minuto?» es una pregunta; «validar el área de clientes» no lo es.
  2. Elige las tareas. Entre tres y cinco tareas concretas y realistas que respondan a la pregunta.
  3. Define el alcance mínimo. Solo las pantallas y caminos necesarios para esas tareas, más las salidas obvias que alguien podría intentar.
  4. Decide la fidelidad por dimensión. Por ejemplo: visual media, contenido alto, interactividad media, amplitud baja.
  5. Prepara contenido verosímil. Nombres, precios, fechas y textos que la persona reconozca como reales.
  6. Construye y recorre. Haz tú todas las tareas en el dispositivo final. Repara enlaces rotos y callejones sin salida.
  7. Prueba piloto. Una persona del equipo que no lo haya visto lo recorre en voz alta. Siempre aparece algo.
  8. Prueba con usuarios. Cinco personas por perfil suelen bastar para detectar la mayoría de problemas importantes de un flujo, según la recomendación clásica de Jakob Nielsen.
  9. Itera. Cambia lo que falla y vuelve a probar, aunque sea con menos personas.

Ejemplo resuelto: reserva de mesa en un restaurante

Pregunta: ¿la gente reserva mesa sin dudas en móvil en menos de 45 segundos? Tareas: reservar para cuatro el sábado a las 21:00; cambiar la reserva a las 21:30; añadir una nota de alergia. Fidelidad: visual media con la tipografía y el color del restaurante, contenido real (carta, horarios, mensaje de confirmación), interactividad media con variables para recordar personas y hora, amplitud con un caso de «sin disponibilidad». Herramienta: Figma, probado en el móvil de cada participante. Tiempo de construcción: un día y medio.

Lo que aprendimos: el selector de hora necesitaba mostrar solo huecos disponibles, y la nota de alergia funcionaba mejor como casilla con opciones frecuentes que como campo libre. Dos cambios que en código habrían costado varias iteraciones se resolvieron en una tarde.

07Qué fidelidad encaja en cada fase del proyecto

Si miramos un proyecto de principio a fin, la fidelidad no sube en línea recta: sube, baja cuando aparece una pregunta nueva y vuelve a subir. Esta es la secuencia que se repite en la mayoría de nuestros proyectos de web y producto:

  • Descubrimiento. Bocetos en papel o en pizarra durante los talleres con el cliente. Sirven para ponerse de acuerdo en qué pantallas existen y qué tarea resuelve cada una.
  • Arquitectura. Wireframes navegables del menú y de los flujos principales. Aquí suele hacerse el primer test rápido con tres o cuatro personas.
  • Diseño visual. Media fidelidad con contenido real en las pantallas clave, para probar jerarquía, lectura y llamadas a la acción.
  • Detalle e interacción. Alta fidelidad solo en los momentos donde la sensación importa: el proceso de compra, el onboarding, una animación de confirmación.
  • Preparación para desarrollo. El prototipo de alta se convierte en referencia viva, enlazada a los componentes y a la documentación.

Cuando a mitad del diseño visual surge una duda de flujo («¿y si el pago va antes del registro?»), lo sensato es volver a la baja fidelidad para esa parte concreta. Rehacer en grises un tramo de diez minutos es mucho más rápido que reconstruir pantallas pulidas.

Cómo presentar un prototipo al cliente

Un detalle que marca la diferencia: antes de enseñar un prototipo, explicamos qué se puede pulsar, qué no está hecho todavía y qué pregunta queremos que nos ayude a responder. Con baja fidelidad, decimos expresamente que el color y la tipografía no están decididos, para que la conversación se centre en el recorrido. Con alta fidelidad, dejamos que la persona lo use primero en silencio y solo después hablamos. Las primeras reacciones, sin guion, son las más valiosas.

08Errores frecuentes y lo que funciona en su lugar

  • Lo que funciona es prototipar el flujo, no la pantalla. Una pantalla espectacular aislada no dice si la gente llega a ella.
  • Lo que funciona es incluir el camino triste. Un error de pago, un campo inválido, una búsqueda sin resultados. Ahí es donde más se aprende.
  • Lo que funciona es probar en el dispositivo real. Un prototipo móvil probado en el monitor del portátil oculta los problemas de alcance del pulgar y de tamaño de texto.
  • Lo que funciona es separar el prototipo de la presentación. Si el objetivo es aprender, la persona tiene que poder equivocarse; si es convencer, se cuida el recorrido perfecto. Son dos piezas distintas.
  • Lo que funciona es documentar lo aprendido. Una página con la pregunta, lo observado y la decisión tomada vale más que el propio prototipo dentro de seis meses.

09El prototipo como conversación

Más allá de la técnica, un prototipo es la mejor herramienta de conversación que tiene un equipo. Pone a diseño, desarrollo, negocio y usuarios delante de lo mismo, en vez de cada uno imaginando su versión. Ahorra discusiones abstractas y sustituye opiniones por observaciones.

En nuestro método el prototipo aparece pronto y varias veces, primero en baja y después en alta, y es el puente entre la estrategia y el diseño web y de experiencia digital que acaba en producción. Si tienes una idea que quieres poner en manos de usuarios antes de construirla, escríbenos y la prototipamos juntos.

Juan Navarro

Juan Navarro

Fundador y director creativo de SIMA, en Estepona. Más de 25 años dando forma a marcas, webs y espacios.

—FAQ

Preguntas
al margen.

Las dudas que suelen aparecer después de leer esta guía.

Hacer una pregunta

El wireframe es un esquema estático de la estructura de una pantalla, sin diseño visual. El mockup es una imagen estática con el aspecto final. El prototipo es interactivo: puedes pulsar, navegar y completar tareas, sea cual sea su nivel de acabado. Un prototipo puede hacerse con wireframes (baja fidelidad) o con pantallas ya diseñadas (alta fidelidad).

Depende de la fidelidad y del alcance. Un prototipo en papel de un flujo se hace en una tarde. Uno navegable de media fidelidad con cinco o seis pantallas, en uno o dos días. Uno de alta fidelidad de un flujo completo, con estados y microinteracciones, puede llevar de varios días a un par de semanas. Por eso conviene empezar bajo y subir solo cuando la pregunta lo pide.

Sí, y es una de las prácticas más útiles del proceso. Un prototipo navegable en Figma permite observar si las personas encuentran lo que buscan y completan tareas antes de escribir código. Para tareas con formularios o datos que cambian, ayuda usar variables y condicionales, o recurrir a un prototipo en código si la interacción es muy rica.

Son muy útiles para generar rápido versiones funcionales a partir de una descripción o de un diseño, sobre todo cuando la interacción es compleja. Funcionan mejor como acelerador de un criterio claro: tú decides qué preguntar, qué flujo probar y qué conclusiones sacar. El resultado suele necesitar ajustes para que respete la marca y la accesibilidad.

Un prototipo en Figma no, aunque sirve como especificación muy precisa. Un prototipo en código a veces sí puede evolucionar hacia producción, pero conviene decidirlo desde el principio, porque un prototipo hecho para aprender rápido suele saltarse cosas que la versión final necesita: accesibilidad, rendimiento, gestión de errores y seguridad.

Del papel al proyecto¿Lo hacemos realidad?