UX Writer, el nuevo perfil UX

Hace 10 años nadie había escuchado hablar de las siglas UX, algunos nos hacíamos llamar "expertos en usabilidad" o algo un poco más moderno como "Diseñadores Centrados en el Usuario".

Acabamos de empezar el 2017 y podemos decir que desde hace un tiempo UX está de moda. Durante el 2016 pudimos ver como algunos perfiles diseñadores  se ponían las siglas UX delante de las siglas UI, quedando UX/UI Designers. Podía parecer que era la moda del "UX"  pero este 2017 todo apunta a algo nuevo. Quiero dar la bienvenida a los "UX Writers" y los "UX Developer".  Vamos  a darle vuelta a "UX Writer".Read more


La app de Netflix para AppleTV, tiene algún problema de UX

Hace poco más de un año me compré la nueva versión de Apple TV. Fueron diversos los motivos de la compra, entre ellos la posibilidad de instalar aplicaciones... Pero hoy no voy hablar de AppleTV ni voy hablar de su nuevo mando Siri Remote. Quiero hablar de una pequeña cosa que tiene la app de Netflix, que como UX que soy me pone un poco de los nervios.

No soy el típico cinéfilo que conoce todas las series y todas las películas del mundo. Si me pones un listado de nombres de series y de películas puede que no acierte si un título es una película o una serie.

 Problema

Netflix no diferencia "a simple vista" lo que es una película de lo que es una serie. Tengo que mirar "muy bien" en el detalle de la ficha para ver lo que es, el tema es que la única forma de saberlo es mirar en la zona donde pone la duración, en el caso de las películas aparece por ejemplo 1hora 43 minutos, en el caso de una serie 1 temporada. Para algunos os parecerá una tontería muy grande pero este pequeño detalle me irrita un poco :) ya que es la única forma de saber si es una película o una serie.

 

Detalle ficha de una serie
Detalle ficha de una serie

 

Una persona que va a Netflix y dice "Hoy quiero empezar una serie nueva" o "Hoy quiero ver una película", tiene un cierto problema para identificar a simple vista, tiene  que pulsar en el screenshot y ver en la esquinita de todo si pone una duración en tiempo o en temporadas.

Por lo tanto podemos detectar dos cosas:

  • Hay que entrar en el detalle para ver si es una serie o una película, no hay un filtro previo.
  • He de leer y reinterpretar que temporada=serie, minutos=película, un esfuerzo que no debería hacer.

 Solución

Hacer mayor diferenciación series-películas en la home inicial. Se podría realizar de diferentes formas:

  • A partir de iconos, se tendrían que escoger bien los iconos ya que pueden hacerte dudar.
  • Utilizar tabs para diferenciar. Aunque es extraño usar tabs  solo para dos elementos, podrían ser útiles para diferenciar los documentales (ahora no se diferencian, se ponen como películas) o en el caso que se quiera hacer una retransmisión en directo o se quiera añadir conciertos.
  • Cambiar los labels de los apartados de la home y hacerlos mucho más claros.
  • Permitirte de forma clara filtrar lo que quieres ver.

 

Si vemos su principal competidor HBO, hace unos labels mucho más claros para saber que información encontraremos y por otro lado añade un filtro superior.

Home HBO para AppleTV

Conclusiones

Desde mi punto de vista, para solucionar el problema tendríamos que aplicar una idea parecida a HBO y a su vez poner un pequeño TAB en cada screenshot para poder diferenciar a simple vista si es una serie o una película. Tenemos que intentar evitar los iconos, como ya sabemos muchas veces se pueden interpretar de muchas formas o simplemente no lo interpretamos. Revisando la web de Netflix veo que tienen el mismo problema, la solución podría ser la misma.

Por otro lado, actualmente la app dispone de un apartado en el menú que se llama "categorías" pero no quiero hablar de ello ya que hay un importante problema de arquitectura de la información del cual no hablaré en este post.

El problema que he expuesto es a partir del uso que le doy a la aplicación (contexto de uso) y a su vez a partir de un perfil de usuario parecido al mío.

¿Tenéis Netflix y habéis detectado algún problema de funcionalidades o UX?


UX de la mano de Customer Support

UX trabaja de forma colaborativa con otros perfiles dentro de la empresa. Siempre queremos que todos los componentes se focalicen con una misma idea,  el concepto "Kentucky Fried Donut", todos trabajan con los mismos KPI's y de forma paralela.

 

KFD no es una cadena de comida americana, KFD son las siglas de "Know, Feel, Do".

  • Know: ¿Cómo queremos que utilicen el producto nuestros usuarios?
  • Feel: ¿Qué queremos que sientan nuestros usuarios cuando utilicen nuestra herramienta o funcionalidad?
  • Do: ¿Qué queremos que hagan?

 

Los KFD's y los KPI's se tienen que tener muy claros antes de empezar. Mientras que los KPI's pueden ser siempre los mismos, los KFD's pueden ser diferentes para cada proyecto. Por esa razón necesitamos conocer muy bien a nuestros usuarios. Ese "Do" se puede obtener de muchas formas,  ya sea mediante entrevistas, test con usuarios, encuestas, las redes sociales o canales de soporte. El equipo de Customer Support suele ser el encargado de recibir todo el feedback, estar en contacto  con nuestros usuarios y dar la cara.

 

CS conoce muy bien a nuestros usuarios, quizás diría que son los que conocen mejor a nuestros usuarios. Por esa razón os aconsejo que siempre que podamos nos sentemos un día entero o unas horas a su lado escuchando las llamadas, leyendo chats o simplemente los emails que reciben. Será la mejor manera para saber el día a día de los usuarios. "Be a CS"

 

He escuchado muchas cosas del equipo de Customer Support, los eternos conocidos como "Call center", son ellos los que reciben de primera mano las necesidades del día a día de nuestros usuarios ¿Quién mejor que ellos para ayudarnos a responder el KFD?. Seguro que muchas de las personas que habéis trabajado en un equipo de CS o habéis estado al lado de este equipo podréis confirmarme estas frases:

  • "Muchos usuarios quieren que pongas un botón que haga esto." Al preguntar cuantos usuarios lo quieren te dicen "muchos" o "dos usuarios", pero nunca con datos sobre la mesa. Para el equipo de CS todo es importante.
  • "Me ha pedido que lo pongamos". Al preguntar por que lo necesitan no saben muy bien la razón, "ellos lo necesitan si o si o se van y dejan de pagar".

 

No nos engañemos, todos sabemos que CS hará lo que sea para que los usuarios sigan pagando por nuestro producto, siempre lo quieren todo. Nuestro trabajo como UX es saber filtrar toda esta información y poder entender realmente que es lo que quieren los usuarios que se ponen en contacto con nosotros y saber realmente para que lo necesitan.

 

Os aconsejo compartir un excel o un documento con el equipo de CS, nos informaran de forma mas o menos detallada  todos los problemas que tienen los usuarios. Pero este documento no se debe hacer de cualquier forma, debe responder on conjunto de puntos.

 

  • ¿Quién es el usuario?
  • ¿Qué problema tenía el usuario?
  • ¿Cuál es el problema que realmente tenía el usuario?
  • ¿Qué solución le hemos dado al usuario?
  • Si se ha solucionado, ¿el usuario lo ha entendido y ha propuesto una solución mejor?.

 

Estos puntos serán necesarios para poder mejorar la comunicación con el equipo de CS y de esta forma conseguir entender mejor las problemáticas de los usuarios. No sirve de nada saber los problemas que tienen si realmente no sabemos que es lo que se necesita y como se necesita.

 

Atención para los navegantes, os aconsejo que siempre sea la misma persona la que gestiona la comunicación con CS y que diferencia muy bien lo que son bugs o problemas técnicos, de los que son temas de UX. Desde mi punto de vista son cosas que no tendrían que aparecer en este documento.

 

Nosotros como UX podemos conseguir mucha información, ya sea cualitativa como cuantitativa, pero la mejor forma de obtener información directa de los usuarios durante el día a día es con el equipo de CS. Sentaros con ellos y intentar hablar de todo lo que pasa, son la voz de la empresa y de los clientes.


Capítulo 1: UX y el rollito lean en una startup

A partir de un conjunto de posts, quiero hablar sobre mi experiencia en el mundo de una startup (Doctoralia) desde el punto de vista de un UX, trabajando en un entorno ágil, aplicando las técnicas de Scrum. No voy a soltaros una filosofía, creo que hay cracks en nuestro país que os pueden explicar mucho mejor que yo en que consiste todo esto.

Lo que empecé haciendo

Empecé a escuchar hablar de Scrum hace unos 6 años cuando trabajaba en la consultora everis. Teníamos un equipo UX de unas 15 personas en las oficinas de Barcelona. ¿Consultora? ¿Scrum? :) puede ser gracioso pero un día colgamos en una pared post-its donde indicábamos los proyectos en el que estábamos trabajando cada uno de nosotros, con las típicas columnas de "to do", "in progress", "done". Hacíamos dailys cada mañana antes de empezar a trabajar. Pero realmente eso no era un Kanvan ni eso eran dailys. 

El Kanvan lo utilizábamos para ver la carga de trabajo de cada uno de nosotros para distribuirnos los proyectos. Las dailys solo eran para saber que hacían los otros. De poco servía todo eso si trabajábamos con el modelo waterfall... y la mayoría de veces no teníamos ni contacto con los developers o fronts.  (amigos de everis, de eso hace muchos años, seguro que ya no es así).

Lo que hago ahora

Estructura del equipo

Para que podáis entender la estructura de trabajo, voy a explicar por encima como trabajamos. La empresa está estructurada por mini-equipos. Cada equipo se encarga de una parte de la web o de un producto en concreto. Los equipos están formados por un PO (Product Owner), un UX y Developers que realizan tareas de de backend y frontend.

De forma transversal tenemos un equipo de componentes. Este equipo está formado por dos frontends (puros y duros) y dos diseñadores. Más adelante explicaré como trabajamos con el equipo de componentes. Finalmente un copywritter se encarga de tratar de la mejor forma los copys y las traducciones.

group-7

Esta estructura puede variar, dependiendo del número de personas, productos, KPI's, etc. Personalmente me siento muy cómodo trabajando de esta forma. Anteriormente trabajé con una estructura de "equipos por roles", es decir, un equipo de UX, un equipo de DEV, otro de FRONT.... Cada equipo se va organizando las tareas según prioridades.

 

La forma de trabajar

Como era de esperar trabajamos con sprints. La duración puede variar un poco dependiendo de las tareas o proyectos con los que estamos trabajando, pero si no hay nada nuevo hacemos sprints de 2 semanas.

Los sprints se estructuran de la siguiente forma:

  • Sprint Planning: En esta sesión el PO lista todas las tareas que vamos a realizar en este sprint. Todas la tareas han estado consensuadas anteriormente en una reunión de PO's, teniendo en cuenta los diferentes KPI's de los equipos. En estas plannings se organizan las tareas a partir de todas aquellas personas involucradas. Otro día hablaré más en detalle de las plannings. Lo que voy adelantar es que desde el punto de vista de UX, nuestras tareas suelen estar en sprint -1, es decir, las tareas que tendrán que coger los DEV's, Fronts o cualquier otro miembro, ya estarán trabajadas en el anterior sprint
  • Daily Sprint: Cada día los miembros del equipo se reúnen para comentar como van las tareas, a su vez solucionan dudas y mueven aquellas tareas, ya sea en "in progress", "QA", "Done"... .Aunque no se tenga que hacer, en las primeras dailys siempre es un buen momento decir si alguna cae o no de la planning... a su vez, si alguna crece o no. Lo se... no tendría que ser así pero puede pasar.
  • Demo: Llegó el gran día de la demo, ese día donde cada equipo muestra a otros equipos o compañeros, el trabajo realizado en ese Sprint. A su vez muestra la evolución de otros cambios ya realizados, así como el impacto de los mismos y los KPI's.
  • Retrospective: Es el momento en el que todos los componentes del equipos nos podemos lanzar flores o tirar los platos por la cabeza. En las retros, se intentan sacar las cosas que han ido bien durante el Sprint, las que podrían ir mejor y  finalmente las que no han ido bien y por lo tanto tendremos que mejorar.

A continuación podéis ver un gráfico que explica de forma más visual la estructura y forma de trabajo.

 

scrum-agiletrick

 

Este es un breve resumen de como nos estructuramos  y como trabajamos en un entorno agile siguiendo el famoso "rollito lean". Realmente es una muy buena forma de trabajar, agilizando los procesos, la comunicación entre componentes del equipo, tener un control de los diferentes proyectos, así como su correcta gestión con otros equipos.

¿Tienes alguna experiencia o quieres explicar tu forma de trabajar?


Historia del icon hamburger

Iconburger fué creado por Norm Cox en 1981. Norm es el creador de Xerox Star,  el primer sistema comercial informático que disponía de un conjunto de tecnologías como una interfaz gráfica con ventanas, carpetas, iconos, ethernet, ratón, servidor de impresoras... diciéndolo de otra forma, el creador de los ordenadores tal y como los conocemos actualmente. Norm no solo es el creador del famoso icono hamburguesa, también es el creador del "icono documentos" entre muchas otras cosas. El icono acabó desapareciendo con XeroxStar.

En el siguiente video podéis ver la presentación del icon hamburger, mirar a partir del minuto 21:07.

Más de 20 años pasaron para que la aplicación de Tweetie de iPad lo incorporara en su menú. Aunque el uso no era el mismo, Loren Brichter, ex-trabajador de Apple lo incorporó en la aplicación. ¿Veis alguna relación entre Apple y Xerox? :)

Solo tuvo que pasar un año (2009), cuando Facebook lanzo una actualización de su App con el famoso icono, situado en la parte superior izquierda. A partir de ese momento todos siguieron ha Facebook. No hay que olvidar que las apps para móviles venían con una estructura de menú en forma de matriz.
 

Facebook App 2008 y 2009
Facebook App 2008 y 2009

El "icon hamburger" tiene cosas buenas y malas, aunque desde mi punto de vista las malas pesan más sobre las buenas. En el siguiente post, hablo sobre el uso del icono y sus consecuencias.