Hace poco me amenazaron con una reunión para discutir este tema, así que hice unas notas en el metro, sobre como evaluar la experiencia de usuario sobre API´s, aquí lo dejo.

Son solo notas, solo pretenden ser un punto de partida para un debate. 

¿A quien vamos dirigidos?

Como el caso que me tocaba estaba dirigido a pequeña y mediana empresa, supongamos que vamos dirigidos a dos tipos de roles :

A – Director de IT, Product Manager,  otro tipo de rol de dirección.
B – Desarrollador, analista o miembros de IT.

El tipo de usuario A, esta muy interesado en la funcionalidad, capacidades y costes. Y en la mayoría de casos decidirá el uso de la plataforma cuando un rol B haya filtrado la propuesta.

El tipo de usuario B, es práctico y vago (en el mejor sentido de la palabra), podemos decir que está interesado en documentación, ejemplos y facilidad de implementación. Tal vez no toma la decisión final pero es un rol clave.

Un contexto de busque, compare y elija (comparativo)

En la mayoria de casos, no somos los únicos que ofrecemos el mismo servicio (o similar), de lo que se deduce que seremos uno más en la elección. En el caso de ser únicos (jeje, en internet.. jeje), podemos aplicar los mismos principios para procurar que la experiencia sea un poco mejor.

¿Que elementos ayudarán a que nuestra API sea escogida?

Básicamente se trata de ser IT-friendly 🙂  Aparte de lo más obvio (facil de integrar y configurar) tal vez estos puntos nos ayuden, como recordatorio, a hacerlo un poco mejor.

Quick Start: ¡Copio, pego y funciona!

Es un buen punto ofrecer un ejemplo sencillo, rápido y ejecutable en la primera visita. Esto tiene dos efectos, hacer al programador sentirse seguro sobre las posibilidades de implementación y convencer al rol A de que esto va a ser fácil. Los mejores que hay en esto son posiblemente Twilio Quick Start, te reto a encontrar los mismo en por ejemplo en Lleida.net.

Documentación libre y abierta

No creo que este punto necesite mucha explicación, tenemos a un usuario evaluando nuestra opción, buscando resolver sus dudas… deberemos dejar toda la documentación navegable (normalmente por árbol) y que facilite la búsqueda.

Mejor un SDK 

La mayoría de los desarrolladores prefieren un buen SDK fácil de descargar, en su propio lenguaje de programación, que puedan probar (funcionalidad básica) sin necesidad de conocimiento.

Una descarga accesible, sin registro, compacta, con una clara referencia al lenguaje de programación: Descarga tu SDK para PHP, JAVA, ASPX, etc.. procurando no liar al desarrollador con varias  opciones y organizando de manera clara los ficheros del SDK (por ejemplo mira https://github.com/paypal/rest-api-sdk-php , para probar el API, ¿debemos ir a test o sample?).  Tal vez un ejemplo_sencillo.php y ejemplo_completo.php serían de ayuda.

Soporte para no-usuarios

El soporte es clave antes de su contratación. Cuando estamos decidiendo que tipo de API vamos a utilizar, leyendo documentación y viendo ejemplos, pueden surgir dudas exclusivas de nuestro caso (no resueltas en un FAQ o Foro). Por lo que enviamos un ticket a soporte, he visto varios casos donde se ha rechazado el uso de un API en particular, por el simple hecho de no recibir una respuesta a este primer ticket.

En otras palabras: El soporte para no-usuarios es extremadamente importante, en muchos casos aún más que el soporte para usuarios (que puede resolverse en comunidad o por documentación).

“Poco y robusto” frente a “mucho y cambiante”

A la hora de desarrollar un buen API, nos conviene pensar en poca funcionalidad, pero que sea robusta, que no cambien ni tengan que actualizarse.

Reportes comprensibles (respuestas comprensibles)

Una buena galeria de mensajes de respuesta ayuda mucho al desarrollador, evita que deba consultar la documentación cada vez que algo no funciona.

¿Se te ocurre alguna más?

Espero que os guste.

Deja un comentario

Necesario