Saltar navegación
Contacto: (+34) 670 230 483

Usted está en: Inicio > Blog > Nada más inútil que un prototipo perfecto

Nada más inútil que un prototipo perfecto

Escrito por Dani Armengol Garreta el 7 Jun 2011

Haced un ejercicio: pasaros por una biblioteca, id a la sección de informática y abrid algún libro de algoritmia. Dad un vistazo y probad a mirar cuántas veces se utiliza la expresión “caso peor”. Os sorprenderéis. Repetidamente se habla del “peor caso de ejecución” o “peor estructura de datos posible” y, probablemente, una lectura superficial os hará pensar que los programadores son gente muy pesimista. ¿Por qué, sino, hablar del “caso peor” y no del “caso mejor”? La respuesta es que, independientemente del optimismo o pesimismo del desarrollador de una aplicación, los “casos peores” existen y, perdonad la perogrullada, siempre son los peores... Por eso se les debe prestar especial atención.

Los que nos dedicamos a la arquitectura de información parece ser que hacemos justo lo contrario a los buenos desarrolladores: prototipamos poblando las interfaces de datos, considerando el caso ideal, perfecto, en el que todo está en su sitio y en la cantidad justa. Un caso que, incluso, ni siquiera se acercaría al caso “promedio”.

¿Qué le sucede a esta interfaz si en un momento determinado no tiene datos a mostrar? ¿O hay muchos? ¿O no son justamente como planteamos que serían?

Estas tres preguntas reflejan tres escenarios que deberíamos tener siempre en cuenta para prototipar mejor:

  • Pocos datos 
  • Muchos datos 
  • Datos de Marte 

Pocos datos

En un tweet de la semana pasada compartíamos una lista de 10 importantes consideraciones para plantear aplicaciones web. La encabezaba un concepto clave: el blank state. El blank state, (o blank slate, o tabula rasa), es ese preciso instante en la vida de una aplicación en el que todavía no hay datos: una aplicación de facturación sin facturas, un sitio web de fotos sin fotos, un agregador de restaurantes sin restaurantes, etc.

Estos casos acostumbran a suceder una única vez por usuario: la primera vez que accede al sitio web o ejecuta la aplicación. ¿Pero son por eso menos importantes? Tal y como cuenta 37signals en su libro Getting Real, el blank slate es el momento en que muchos usuarios se forman una primera impresión de la aplicación y toman la decisión de si van a usarla, comprarla, recomendarla o, sencillamente, olvidarla.

Controlar esta primera impresión es esencial. ¿Qué podemos hacer como diseñadores de interacción para controlar la experiencia de usuario en este primer momento? El paso inicial es muy sencillo: ser conscientes que existe y concretar el prototipo de los escenarios en los que no hay nada en la interfaz.

Muchos datos

La escalabilidad de un sistema es una cuestión muy importante en el mundo del desarrollo. Hablad con un desarrollador web y os dirá de forma precisa cuántos usuarios simultáneos admite su sistema.

¿Son las interfaces que prototipamos escalables? ¿Hemos definido cómo deben escalar? Por ejemplo: si tenemos más de 50 resultados en un buscador, ¿debemos utilizar un sistema de paginación? ¿Hemos definido cómo debe funcionar ese sistema? ¿Deben usarse meramente números o bien el sistema de paginación debe permitir previsualizar qué contenidos hay en cada página?

Todas estas preguntas no tienen ningún interés si planteamos una pantalla con sólo 10 ítems, pero es importante que tengamos en cuenta qué pasa si hay 1.000.

Datos de Marte

Tenemos tendencia a pensar que los datos que van a poblar nuestra interfaz son de este planeta. Craso error.

Si plantemos un sitio web de recetas, que son introducidas por un equipo gestor de contenidos, parece ser fácil marcar unas pautas de edición y calidad: todas las recetas llevarán fotografía, esta tendrá unas dimensiones y proporciones concretas, el texto indicará claramente los pasos a seguir en la receta, los ingredientes serán precisos, etc.

Si definimos una interfaz, también de recetas, pero donde estas son introducidas por usuarios, ¿podemos plantearlo igual? ¿Qué sucede si el usuario no sube fotografía? ¿Y si no divide el texto claramente en pasos? ¿Qué hacemos con todas estas recetas “marcianas”?

Definir variaciones para una misma pantalla es la mejor solución a estos casos: es importante determinar los distintos escenarios que deben ser satisfechos y adecuar la interfaz a cada uno de ellos.

Por ejemplo, ¿cómo planteamos la pantalla de una receta si el usuario no ha subido foto? Una opción es, simplemente, eliminar el espacio de la foto y readecuar la situación de los contenidos para que se ajusten a este nuevo escenario. Otra opción es no eliminar el espacio de la foto y dejar claro que esa receta carece de foto. Quizá, de esta forma, el usuario se siente más motivado a “completar” su receta con lo que falta. ¿Quién debe tomar esta decisión? ¿Alguien en el último momento? Seguramente ya conocéis la respuesta.



Comentarios (3)

ruymanfmruymanfm dijo el 22 Jun 2011:

Me resultó muy interesante este post de Juan Leal sobre una experiencia real en la que no se contempló lo que él llama "usuario cero": http://www.seisdeagosto.com/indica/2010/02/disenando-para-el-usuario-0%E2%84%A2-es/

DaniDani dijo el 23 Jun 2011:

Leí hace un tiempo, no recuerdo dónde, otro artículo también interesante sobre casos reales de sitios web cuya utilidad estaba basada totalmente en las aportaciones de los usuarios (típica start-up dospuntocerista de los últimos años).

El artículo sugería que un sitio web basado en contenidos de usuarios debe definirse en dos fases: en una primera fase el diseño está orientado a los productores de información. Se incentiva su participación mediante mecanismos como rankings, premios, visibilidad, etc.

Una vez se ha generado esta comunidad de generadores de contenidos y el sitio web ya no está vacío es el momento de "acomodar" a los consumidores de información, rentabilizando así la actividad de los productores.

No recuerdo si es del artículo o esto ya es aportación mia, pero diseñar el equilibro para que las dos tipologías de usuarios se sientan cómodos creo que es parte del éxito. Y es otro tema que se olvida a menudo, como el "usuario 0" que comenta Juan Leal.

DarkyDarky dijo el 13 Ago 2011:

Muy buen articulo... al momento de diseñar nos dejamos llevar por el "happy path" pero al vaciar el contenido dinamicamente nos encontramos con escenarios que no consideramos y hacen que nuestro "bonito" diseño se deforme y tengamos que retrabajar en esos pequeños detalles..



Últimos tweets de Usolab

  • Ups, parece que ahora mismo no podemos mostrar nuestros tweets.

Proyectos propios

Bankimia

Bankimia es un comparador de productos financieros.

Actualmente ofrece información sobre hipotecas, depósitos bancarios, cuentas y préstamos de 42 bancos y cajas.