Mostrando las entradas con la etiqueta ux. Mostrar todas las entradas
Mostrando las entradas con la etiqueta ux. Mostrar todas las entradas

2017/08/09

UX para todo(s)


Nota: Por favor, lee esto con la mente abierta. Si eres frontend, creo lo entenderás. Si eres backend, por favor, no me malinterpretes; también he hecho algo de backend y muchos de mis amigos son backend. No tengo nada en contra de los backend. Excepto quizás la optimización prematura, el overkill (pero eso es algo que se ve en todas partes), y esto.

Encuentro que hay una discusión entre frontend y backend. Entre los chicos que hacen las interfaces para el usuario y los que preparan la data que se mostrará.

Es más o menos así: los backend pretenden que los frontend tienen que usar sus apis cómo a ellos les de la gana de hacerlas.

Por supuesto pueden esgrimir un montón de argumentos; que el mejor modelamiento de las tablas, que la auto documentación, que la optimización, etc.

Lo que yo digo es solamente esto: imagínate que los frontend pretendiéramos que los usuarios tienen que arreglárselas para usar las interfaces que nos diera la gana de hacer.

¿Que así es como haces tus interfaces de usuario? Detente, stop, para un momento.

Por supuesto que durante muchos años se ha hecho así; con la dictadura de los diseñadores sometiendo al usuario y obligándoles a aprender que la opción que buscaban estaba nada más a cuatro clicks de distancia, debajo de un menú desplegable que actuaba cuanto pulsabas la tecla alt después de escape (bueno quizás no tanto, pero seguramente captas la idea).

Pero la abundante oferta de aplicaciones y la despiadada elección de los consumidores ha hecho que recapacitemos y escuchemos al usuario y qué tipo de experiencia realmente le ayuda a conseguir lo que necesita. Porque lo que la UX busca no es que las interfaces sean más bonitas (es un malentendido de marketing); lo que busca es que las interfaces puedan dar lo que se necesita sin obligar a hacer un esfuerzo innecesario.

Además, mira el nombre, "interfaz de usuario", no dice "interfaz del programador frontend". No se supone que debas sentirte cómodo programándola; quizás tengas suerte y sea entretenido, estimulante, o quizás no y sea un dolor de cabeza y un verdadero desafío cómo resolver una interacción; lo importante es que el usuario pueda sentirse cómodo usándola, sin esfuerzos innecesarios.

Pues bien, del mismo modo, la API que se entrega a los frontend es la interfaz con la que nos comunicamos con la fuente de datos. Una buena API no es aquella que sea cómoda o fácil de programar para los backend; puede que lo sea, si se organizan bien, pero es un rollo interno, que no debe atravesar la interfaz. Porque recordemos que se trata de una interfaz: la comodidad y facilidad deben estar del lado de quién la va a usar.

Un backend debería hacer con el frontend el mismo ejercicio que el frontend hace con el usuario. Observarlo, ver cómo va a usar la API, conversar con él acerca de sus necesidades reales, empatizar.

No creo que necesitemos una especie de Frontend eXperience (no más siglas, por favor), sino que comprendamos que los mismos principios que venimos a reconocer como válidos al aplicar UX son aplicables también a la hora de desarrollar interfaces para otros desarrolladores. Puede ser un API REST, o puede ser una librería, o un framework, o cualquier herramienta en general.

En una interfaz, la comodidad y facilidad deben estar del lado de quién la va a usar. Creo que es el principio que guia a la UX y está ayudando a crear más software realmente valioso para los usuarios. Y creo que es hora que apliquemos lo mismo a la relación frontend-backend (y en todas aquellas donde veamos una interfaz), y ayude a crear herramientas realmente valiosas para desarrollar mejor mejores aplicaciones.

2016/11/11

De producir software a vender software


Imagina que trabajas varias horas pintando una pared. Luego armando unas mesas. Después un escaparate. Finalmente, organizando las cosas que se van a exhibir.

Esperas, por supuesto, que el dueño del stand te pague por las horas que has estado ocupado, las herramientas que has usado, los materiales, y tu profesionalismo.

¿Qué dirías si te dijeran que, como no se logró vender mucho, tampoco te pagarán mucho?

Piénsalo un momento.

¿Tiene sentido para tí (el constructor)?

¿O tiene sentido para el dueño del stand (el vendedor)?

Los constructores y productores esperamos un pago en función de lo que construímos y producimos.

El vendedor espera un pago en función de las ventas.

Esa diferencia de expectativas es importante.

Si tenemos dos stands A y B, el A construido por nosotros con mucho empeño y calidad, y el B construido con materiales de segunda y poco gusto (según nuestro imparcial criterio), ¿cómo nos sentimos si el stand B arrasó en ventas y no el stand A?.

¿Te ofenderías? No, porque las cosas que se venden no tienen que ver contigo. Tú te dedicas a construir stands.

¿Se ofendería el vendedor? Sentiría que no resultó su estrategia de venta, pero no estaría ofendido contigo, que cumpliste con tu trabajo, ni con los clientes, que prefirieron comprar en otro lado. Así son las ventas.

¿Qué pasaría si el dueño del stand A esperara que los clientes eligieran su producto debido a las muchas horas que trabajaron en el stand, en las herramientas que usaron y el profesionalismo para construirlo?

Sufriría la gran parte del tiempo que no vendiera como espera (una proporción de 10 a 1, según se dice).

Un vendedor entiende que lo importante es el valor que producto tiene para el cliente, no para el productor.

Debido a eso, puede pedir por el producto mucho más de lo que le costó producirlo. Incluso lo suficiente para compensar las veces que le pagaron menos que eso o que no logró la venta.

Esa diferencia de pensamiento es importante.

Valor, trabajo y utilidad

Hay una teoría de pensamiento económico que proponía que el valor de las cosas es lo que costó producirlas. Parece tener sentido. Construir una mesa mejor parece más trabajo que construir una mesa común, así que debería costar más.

Pero no todos los carpinteros son igual de hábiles. ¿Qué pasa si Pedro tarda dos semanas en construir la misma mesa que Juan tarda solo una semana?. Podríamos decir que Juan impregna la mesa con el valor de su habilidad y por eso debe costar más. ¿Y si llega Pablo con una máquina que hace diez mesas mucho mejores en un solo día? Habría que hacer lo mismo con la máquina, que su poder impregna de gran valor las mesas que produce.

Es una forma de pensar que tiene sentido para un productor o constructor.


Otra escuela de pensamiento económico propuso que el valor de las cosas es lo que la gente está dispuesta a pagar por ellas.

Quizás al comienzo cuesta un poco asimilarla. Al menos para mi lo fue. ¿Qué pasa si alguien me quiere pagar menos de lo que me costó producirla? Puede pasar. Pero también puede pasar lo contrario, que estén dispuestos a pagar mucho más de lo que costó producirla.

Una estampilla puede costar un centavo. Pero puede valer un millón para alguien que la considere especial.

Una mesa puede costar 10. Pero si invento una forma de producirla a 0.01, la gente aún me pagará con gusto los 9 que para ellas es menor que su valor en otro lado.

Es una forma de pensar que tiene sentido para el vendedor.

Y es la forma de pensar que ha prevalecido.

La experiencia del usuario

Construir software tiene un costo. En horas hombre, en herramientas, en profesionalismo. Como productores de software, naturalmente esperamos ser pagados en función de eso.

Pero un vendedor de software piensa diferente. Copiar software tiene un costo muy bajo. Aún así, la gente que lo considere valioso pagará mucho más. ¿Cómo hacer algo valioso para la gente?

El vendedor entiende que será pagado en función del uso que se le pueda dar al software. Pudo haber estado toda la compañía trabajando en una característica super sofisticada, algo muy costoso de desarrollar, pero si los usuarios no la consiguen aprovechar, si no la entienden o si ni siquiera se dan cuenta de que existe, entonces es como si no existiera, algo sin valor.

El valor del software que producimos está en función de la experiencia del usuario.

Entender eso puede tomar su tiempo.

De hecho, hay equipos de programadores que se proponen desarrollar un producto con la ilusión de que la aplicación de su mejor profesionalismo, sus mejores herramientas y esfuerzo, garantizará el exito. Son programadores con el pensamiento de productores.

Es necesario pensar diferente.

Tal vez no totalmente como un vendedor, pero sí tomar algunas cosas de su punto de vista. Aceptar la realidad. Aceptar que el valor de un producto está dictado por el usuario.

Como el valor está determinado por la experiencia, es importante mejorar esa experiencia. Las interfaces son como el intermediario entre el usuario y lo que quiere lograr. Debería facilitarle el camino, hacerlo agradable, permitirle mantener el máximo de energía para lo realmente importante.

El uso determina lo que algo es

El valor de algo está determinado por su utilidad, por lo que significa para quien lo quiere.

Lo que algo es está determinado por cómo es usado, por la manera en que lo utiliza quien lo tiene.

Una característica no existe hasta que un usuario la use.

No importa lo cuidadosamente que hayamos diseñado una característica. Lo que importa es cómo la llega a usar a gente. Si nadie la descubre, ¿qué valor le pueden dar?. Por ejemplo, se dice que sólo un 10% de las características de MS Word es usado por el común de la gente, así que cualquier procesador de texto que cubra esas características es igual de funcional.

Como contraparte, hay usos que la gente da a ciertas herramientas, definiendo caracerísticas que nunca fueron diseñadas. Un navegador de Internet, por ejemplo. Pensado para compartir documentos vinculados, se comenzó a usar para imitar otras formas de comunicación, y también para comprar y vender. Y fue ese uso, y no el académico/científico original, el que impulsó el desarrollo web.

El uso que la gente haga de algo también puede darnos pistas de lo que está necesitando.

Conclusión

Si eres productor de software y quieres vender software, hay formas de pensar diferente que vale la pena considerar aprender.

¿Cómo hacer algo que valga para la gente? Es una pregunta importante.

Lo que hagas no tiene valor hasta que alguien lo use. Entonces es importante empezar por ahí; asegurar del modo rápido que estás atendiendo la necesidad correcta. Después ya puedes mejorar la solución, iterativamente.