Caso práctico: Aplicación de iPad para Canal cocina
Canal Cocina ya tenía una aplicación para iPhone y cuando iba a salir el iPad les encargaron una aplicación específica.
Dado que el iPad todavía no se vendía en España y sólo tenían la información que aparecía en la web de Apple, no había forma de saber cómo se usaba, había un montón de cosas que no se sabían todavía, y vieron el investigar como algo imprescindible. Esto al cliente le costó un poco más entender, en ocasiones hay que convencerle de que es necesario ese «vamos a aprender», y lo consiguieron.
Investigación
Optaron por una técnica de investigación que se llama «Walking with magic things», es decir, los usuarios de prueba ponen de su parte imaginando que el objeto que llevan puede hacer cosas que el prototipo todavía no puede hacer.
En este caso hicieron unos iPads de mentira con un look and feel bastante logrado y lo combinaron con un diario de uso, donde el usuario de prueba iba escribiendo sus ideas sobre cómo usaría el iPad en la cocina.
web design tools.org
Los usuarios que escogieron para la prueba fueron:
- Cinco usuarios sin iphone, con instrucciones más aterrizaditas.
- Cinco usuarios de iphone que además ya tenían la aplicación de canal cocina instalada
y lo que les sorprendió fue que no fueron tan distintas las aportaciones de unos y otros.
Resultados
– Buscador de recetas inverso
– Calcular las cantidades necesarias según el número de comensales
– Alimentos de temporada (calendario de lo que es ahora)
– Diccionario de términos
…
– Especias
– Tener tu propio de espacio
– Poder comunicarse con otros usuarios de canal cocina
– Subir y compartir con la comunidad las fotos del plato que hemos preparado (40%)
– Poder guardar la lista de la compra (60%)
– Elaboración de menús semanales. La gente que cocina cada día se vuelve loca)
– Pero en lo que más coincidían era el timer (70%)
– Más transcripción de voz que de vídeo
– Mientras cocinan escuchan música. Algo para escuchar música.
¿Y ahora qué?
Presentar los resultados de la investigación
El siguiente paso fue hacer un listado de contenidos y funcionalidades, sesión con el cliente, sesión interna (retos ideas y prototipado, con marcos de iPad) Se dividieron en grupos, cada grupo trabajando en la que pensaban que era la killer app.
De ahí hubo un listado de funcionalidades, lo prototiparon, lo diseñaron y salió la aplicación.
En este caso el cliente desechó la oportunidad de reclasificar su base de datos, como pedían los usuarios. También era complicado pedir a los usuarios que clasificasen ellos su contenido con formularios eternos, alguien que sube una receta no les vas a pedir además que calcule los valores nutriocionales. «El único sitio donde la gente rellena formularios infumables para participar es en foros de telva«.
Cuando el cliente tiene una web, es relativamente fácil hacer una encuesta a los usuarios. En este caso eran todo preguntas cerradas menos en el final que era un por qué. Eran todas sugerencias de mejora sobre la propia aplicación.
Al final acabaron con un excel bastante grande con un montón de funcionalidades de la propia aplicación.
Lo importante al prototipar fue dar valor a las propuestas de usuario.
«Hay makings off de pollo asado»
Las conclusiones de la sesión con el cliente (3 grupos) fue curiosa porque salieron cosas que el mismo cliente sabía que no iban a implementar.
Como una de las ideas fue un timer digital, hicieron benchmarking de timers digitales. Viendo qué valía la pena configurar. Se habló con el cliente que fuese algo que pudieses configurar. Al menos si no podían cambiar el contenido como el usuario quería, que hubiese un timer que evolucionase.
Arquitectura de la información de contenidos de la web.
Jerarquías de títulos en la búsqueda… etc. Siempre primero la búsqueda y lo que había en la cocina.
El tema de buscar…
Cuánto especificamos la funcionalidad de los prototipos?
Busquedas qué sale en el texto predictivo.
Los primeros prototipos tienen más anotaciones que cuando estás propagando.
En ocasiones no vale la pena hacer una simulación a menos que se lo tengas que vender al cliente o no te fies demasiado del desarrollador.
«Otra cosa que mola es cuando nos dejan trabajarnos los copys». Ellos siempre que pueden redactan ellos los textos, para que el cliente siga que no, o para parecerse al resultado final lom ás posible. Intentan no prototipar nunca en Loren Ipsim.
Formulario de registro
«Juan Leal es uno de los que más nos ha enseñado sobre elementos de formulario, además nos ha hecho entender que los elementos no tienen por qué ser estándar»
En Peercouture es destacable cómo han diseñado los botones y la interacción. Las interacciones ocultas crean un vínculo emocional con el usuario, son detalles que hacen esta aplicación única. Aumenta la memorabilidad de la marca.
Hay un montón de cosas que a nadie se le ocurre hacer porque no son los estándares.
Otro ejemplo: Photojojo
«No puedes basar una web que sean sólo guiños, porque al final son tics»
«No puedo entender que en el formulario de registro de un canal de recetas me diga que mi receta no es lo sificientemente segura»
Muchas veces el cliente intenta en un formulario sacar información para otros fines, márqueting, por ejemplo. Lo que hay que luchar mucho es que en el registro no se pidan tantos datos, y, si es necesario, hacer un escalado de petición de datos. Hay que saber pedir datos a cambio de algo para el usuario.
Cuando especificamos demasiado los formularios, a veces a los técnicos les sienta mal. Hay que trabajar mucho con los técnicos par que se involucren y entiendan la necesidad de los requerimientos.
Tener que hacer propuestas visuales es un dineral.
También hay que trabajar con los diseñadores visuales. Álvaro insiste que cree que hay una diferencia entre visuales y UX visual designers, la idea le viene es este post de Disambiguity donde explica su experiencia comparativa entre Developer y UX developer.
Hay gente que cree que la gente que sabe de todo no sabe de nada, y otros pensamos que es simplemente una cuestión de tiempo. @Mamuso por ejemplo puede pasar directamente de la servilleta al html, por ejemplo. A veces los prototipos no sirven para definir funcionalidades sino para cerrar fases con el cliente.
En el prototipado no vale un «esto imagínate que…» hay que verlo. Al final estas cosas hay que validar si mola o no mola, es una cuestión de cuantos recursos dedicas para no tener que corregir luego.
En opciones de cómo explicar elementos de interacción al cliente, Javi nos recomiendo el siguiente vídeo de ideo presentando a Sesamee Street si aplicación para iphone, en la que se demuestra que a veces no se necesitan grandes medios técnicos:
Prototyping for Elmo’s Monster Maker iPhone App. from IDEO on Vimeo.
Caso práctico: Aplicación para ipad de Un periódico
El cliente era un periódico (con versión papel y online) y que quería una aplicación para iPad.
Con la investigación sobre las visitas de sus usuarios, llegaron a la conclusión de que la gente está dispuesta a pagar por una edición a las 8 de la tarde que resuma qué ha pasado durante el día, aunque sea una versión en PDF, e incluso valora que el periódico no sea infinito, que alguien te haya hecho una selección con un criterio editorial concreto.
A pesar de ello, esto no se implementó. A veces ocurren estas cosas, nos explican, el típico trabajo que tiene un 80% de tu trabajo pero el cliente te cambia justo el 20% que le da ese toque tuyo.
RECURSOS: Programas de prototipado
Orse utiliza el OmniGraffle
Fireworks
Axure -> Te genera un código basura, pero no hace falta saber html.
* Mucha gente que usa el programa con el que aprendió. También hay modas. Y también hay limitaciones de precios, que en una empresa tienen un presupuesto y sobretodo hay alguien que tiene que ser capaz de abrir todos los documentos de los demás
«Hay gente que sigue usando freehand»
Apuntes de UX 