Prototipado
Maquetas interactivas antes de que nadie escriba código.
Prototipado
Aún no hay productos en esta categoría
Por ahora no hay nada publicado aquí. Si fabrica un producto que encaja en este estante, añádalo y una persona lo revisará.
Añada su productoQué abarca esta categoría
Hacer algo en lo que se pueda hacer clic antes de que nadie lo construya: maquetas interactivas, cambios de estado, flujos que la gente puede probar de verdad y las pruebas que convierten opiniones en observaciones.
El solapamiento con el software de diseño es amplio, ya que la mayoría de las plataformas de diseño incluyen ahora prototipado. Existen herramientas específicas para los casos en que la interacción lleva lógica real, o en que la investigación necesita grabación y análisis integrados.
El diseño de pantallas y los sistemas de diseño están en diseño. La creación de aplicaciones completas sin código corresponde a no-code y automatización.
La fidelidad se decide, no se hereda
El despilfarro más habitual en esta categoría es construir un prototipo precioso para responder a una pregunta que unas cajas grises habrían resuelto.
La baja fidelidad prueba la estructura: si la gente entiende el flujo, qué espera después, dónde duda. Es rápida, barata y casi imposible de sobreinvertir.
La alta fidelidad prueba la comprensión y la confianza. El acabado cambia el comportamiento, y una pantalla tosca vuelve indulgente a la gente de un modo que un producto real no logra, así que todo lo relacionado con la confianza o la compra debe parecer terminado.
Decida primero la pregunta y elija después la fidelidad. Hacerlo al revés es como tres semanas desaparecen en animaciones que nadie había pedido.
Lo que distingue a las herramientas
- Profundidad de interacción, desde simples enlaces hasta condiciones y variables.
- Estado, para que una pantalla recuerde lo que se acaba de introducir.
- Componentes, reutilizados entre pantallas sin duplicar trabajo.
- Datos, reales o verosímiles, en lugar del mismo texto de relleno en todas partes.
- Pruebas en dispositivo, en un teléfono de verdad y no en un marco a escala.
Las variables y las condiciones marcan la frontera. Un prototipo que puede guardar lo escrito en un formulario, bifurcar según ello, recordar la elección y mostrar un estado de error genuino responde a preguntas que el enfoque de pantallas enlazadas no alcanza.
El contenido realista importa más de lo que se cree. Los nombres largos, las listas vacías, las imágenes ausentes y los mensajes de error son donde se rompen los diseños, y el texto de relleno oculta cada uno de ellos.
Las pruebas, que son el verdadero objetivo
Un prototipo existe para enseñárselo a alguien que no estaba en la sala.
Las sesiones moderadas producen razonamientos: por qué una persona dudó, qué creyó que significaba una palabra. Las pruebas sin moderador producen comportamiento a escala y a menor coste, sin la pregunta de seguimiento. Ambas superan a una reunión de revisión en la que gana la opinión más ruidosa.
Cinco participantes por grupo de público detectan la mayoría de los problemas de usabilidad. Más allá, el rendimiento cae en picado, y el tiempo se emplea mejor corrigiendo lo hallado y volviendo a probar.
Redacte la tarea antes de reclutar a nadie. Observar a alguien intentar un trabajo concreto es evidencia, mientras que pedir una opinión sobre una pantalla es una conversación sobre gustos.
Del prototipo a la construcción
La cuestión del traspaso es qué sobrevive.
Algunos equipos tratan el prototipo como una especificación: un registro de cada estado, transición, caso vacío y caso límite que de otro modo se discutiría durante la implementación. Ahí está la mayor parte del valor.
El código generado ha mejorado y todavía hay que reescribirlo para producción. Trate cualquier exportación como un boceto inicial y no como un atajo, y cuente con que la implementación real plantee preguntas que el prototipo nunca afrontó, sobre todo en rendimiento y accesibilidad.
Coste y limitaciones prácticas
El precio es por editor y mes, con los lectores normalmente gratuitos, y las plataformas de investigación específicas cobran por estudio o por participante.
El coste mayor es el tiempo. Un prototipo que lleva dos semanas de trabajo ha costado más que la reunión a la que sustituye, así que conviene mantener el alcance ligado a la pregunta. Los servicios de pruebas suman una tarifa por participante, a veces con el reclutamiento incluido, y normalmente es dinero bien gastado frente a adivinar. Las costumbres generales de precios en el software se describen en lo que ocultan las páginas de precios.
Dónde compensa el coste de un prototipo
Tres situaciones recompensan de forma fiable el esfuerzo de construir uno.
Un flujo con verdadera complejidad, en el que las descripciones escritas producen imágenes distintas en cabezas distintas y el desacuerdo solo aflora durante la implementación.
Una decisión con dinero de por medio, donde un pago, una página de precios o un proceso de registro pueden probarse con personas reales antes de que nadie lo construya.
Una presentación, interna o externa, en la que enseñar algo que funciona cambia la conversación de la opinión al detalle.
Fuera de esos casos, una buena descripción escrita y una pantalla estática suelen bastar. La disciplina que conviene mantener es preguntarse qué pregunta responde el prototipo y parar en cuanto se haya respondido, en lugar de seguir porque trabajar en el archivo resulta agradable.
Preguntas frecuentes
¿Un prototipo es distinto de un archivo de diseño?
Un prototipo se comporta. Responde a un toque, cambia de estado, conserva datos entre pantallas y se puede probar con alguien que nunca lo ha visto. Un archivo de diseño describe cómo debería verse.
¿Qué nivel de fidelidad necesita un prototipo?
El suficiente para responder a la pregunta que se plantea, y no más. Las pruebas de estructura funcionan con cajas grises. La comprensión y la confianza requieren algo más cercano al producto real, porque el acabado cambia la reacción de la gente.
¿Se pueden probar los prototipos a distancia?
Sí, ya sea moderadas por una llamada o sin moderador mediante un servicio de pruebas que graba la sesión. Sin moderador sale más barato y ofrece el comportamiento, pero no el razonamiento que hay detrás.
¿Cuántas personas deberían probar un prototipo?
Cinco por cada grupo de público detectan la mayoría de los problemas de usabilidad. A partir de ahí se confirma en lugar de descubrir, y el tiempo se aprovecha mejor corrigiendo lo que encontraron los cinco primeros.
¿Los prototipos se convierten en código?
El código generado ha mejorado y aun así hay que reescribirlo para cualquier uso real. Conviene tratar el prototipo como una especificación que elimina ambigüedades, no como ventaja inicial para la implementación.