Header Ads Widget

Ticker

6/recent/ticker-posts

Acumulación de comentarios: 4 preguntas que los proveedores de API deben hacer a sus usuarios

 

acumulando comentarios 4 preguntas para hacerles a los consumidores desarrolladores de API

El activista estadounidense Bryant H. McGill dijo una vez: "una de las formas más sinceras de respeto es escuchar lo que otro tiene que decir". Para los proveedores de API, escuchar al usuario promedio, aceptar comentarios , asimilar estas experiencias e iterar sobre esta información es un ejercicio poderoso.

Dicho esto, ¿qué preguntas deberían hacer los desarrolladores a sus usuarios en primer lugar? Saber qué preguntar, cuándo preguntar y cómo hacerlo, es tan importante como ingerir la respuesta final, quizás incluso más importante, al considerar cómo establece la dicotomía desarrollador / usuario y el tono del discurso para el futuro.

En este artículo, nos preocupamos por responder una pregunta singular: ¿qué preguntas deberían hacer los desarrolladores de API a sus usuarios y cómo deberían hacerlo?

Por qué es importante la retroalimentación

Aquí no estamos hablando de labios para afuera: los comentarios de los consumidores son posiblemente el elemento más importante de cualquier ecosistema de desarrollo. La creación de una API es esencialmente un rompecabezas de diseño, que combina las necesidades específicas que el usuario ha comunicado con los talentos, habilidades y limitaciones específicas del entorno de desarrollo.

Cuando los desarrolladores no hacen coincidir las necesidades de sus clientes con su estrategia de desarrollo y sus objetivos a largo plazo, se crea una brecha entre el usuario y el desarrollador. Esta brecha es la causa principal de la mayoría de las dificultades en lo que respecta a la adquisición, retención y experiencia del usuario.

Entonces, ¿cómo puede un desarrollador prevenir esta ruptura? Ahí es donde entra en juego la comunicación. Las relaciones con los desarrolladores adoptan muchas formas, desde interacciones sociales básicas en Twitter y foros oficiales hasta campañas de correo electrónico y conversaciones directas. La utilización de métricas de API efectivas y completas también es un factor clave que conduce al éxito de una API.

Ahora que entendemos la importancia de esta retroalimentación, surge la pregunta: ¿qué preguntas se deben hacer?

¿Qué espera de esta API?

Como señalamos en nuestro artículo sobre la redacción de una política de plataforma legible , las expectativas impulsan todas las interacciones comerciales y sociales. La coincidencia de las expectativas del usuario y el proveedor impulsará la experiencia general del usuario de la API y los servicios relevantes, y puede contribuir en gran medida a informar tanto su imagen pública para otros usuarios potenciales como la experiencia interna de utilizar el servicio.

Enmarquemos esto como una manera de sentido común. ¡Es tu cumpleaños! Como parte de tus celebraciones, has decidido salir a cenar a un restaurante que acaba de abrir en la misma calle. Mirando los precios, decides que es bastante caro, pero vale la pena el gasto adicional.

Cuando vas a este restaurante, tus expectativas de servicio, la calidad de la comida y las interacciones con los camareros definen tu percepción de ese restaurante y esa comida, para bien o para mal. Si tiene pocas expectativas del restaurante, pero en cambio recibe una comida de cinco estrellas con un servicio maravilloso, eso comunica una falla en sus expectativas. Por el contrario, si espera lo mejor y recibe comida de baja calidad y un servicio lento, eso comunica expectativas erróneas del proveedor de servicios.

En este ejemplo, espera calidad por el alto costo. Lo mismo ocurre con los usuarios de API: descubrir y utilizar su servicio en lugar de otros requiere una inversión de tiempo y esfuerzo, y no proporcionar valor a esa inversión de recursos puede llevar a una percepción negativa de toda la experiencia.

Al preguntar directamente qué esperan sus usuarios , no solo puede ajustar su rendimiento y servicio a una alta expectativa, sino que también puede ayudar a nivelar sus expectativas de desarrollo e implementación a largo plazo.

Un gran ejemplo de esto es el ciclo de desarrollo adoptado por Mojang , desarrolladores del exitoso juego para PC Minecraft. Durante su ciclo de desarrollo Early Alpha, dejaron en claro que, aunque tenían grandes planes, la implementación sería lenta. Cuando comenzaron a vender Minecraft y entraron en "beta", notaron que la experiencia del usuario puede estar plagada de errores y problemas, pero que los usuarios deben esperar actualizaciones periódicas para solucionar estos problemas.

Mojang pidió a los usuarios lo que querían. Les preguntaron cómo esperaban que se viera el juego, qué elementos deberían incluirse y qué mecánicas les gustaría ver. Luego comunicaron las realidades de la plataforma de desarrollo, expresando qué era factible y qué no. Atenuaron las expectativas al tiempo que reunían estas expectativas como una plataforma desde la que guiar el desarrollo futuro.

Todo, desde las ranuras de inventario hasta las mecánicas de combate, se ha modificado y manipulado gracias a los comentarios de los usuarios. Cada compilación del juego se lanza en un canal beta para las pruebas de los usuarios, y los foros de Minecraft a menudo están inundados de puntos de datos para la experiencia del usuario que el equipo de desarrollo a menudo llama durante su segunda fase de prueba.

Si bien este ejemplo no está necesariamente en el espacio de la API, demuestra específicamente cuán poderoso es un canal de comunicación abierto. Mojang es conocida entre su comunidad de seguidores como una empresa que se preocupa, una empresa que se comunica y una de la que se puede confiar para implementar cosas cuando dice que las implementarán, con pocas excepciones. Lo más importante es que los usuarios son conscientes de la realidad de sus expectativas y de si se pueden implementar o no.

Al hacer que las compilaciones beta estén abiertas, los usuarios pueden probar el código, un beneficio que se discutió anteriormente en nuestro artículo sobre GitHub . Del mismo modo, el canal de comunicación abierto permite que las vulnerabilidades de seguridad comunes y los descubrimientos "ocurridos" se comuniquen y solucionen rápidamente, evitando exploits y vulnerabilidades de día cero .

Los proveedores de API deben hacer lo mismo. Pregunte a sus usuarios cómo esperan que se vea la funcionalidad . Pregunte a los usuarios qué quieren que haga la API y cómo quieren que haga estas cosas. Al comprender lo que espera su base de usuarios, puede guiar el desarrollo de tal manera que minimice la reacción y maximice la satisfacción con el producto final.

Relacionado: Lo que Twitter hizo bien y lo que hizo mal en su lucha de 10 años con los desarrolladores

¿Cuál es su mayor frustración con la API?

A menudo, los problemas con una API no se comunican directamente, no por falta de canales de comunicación o por miedo, sino por simple vergüenza o "molestia" percibida por el desarrollador. Los usuarios pueden pensar “bueno, esta es una API beta, así que no los molestaré con una solicitud; ojalá se resuelva en una revisión posterior ”. Aún otros usuarios pueden decir "tal vez esto no sea un problema de API, pero mi propio problema ... no soy un codificador muy bueno, después de todo".

Gran parte de este pensamiento puede ser perjudicial para el ecosistema API. Al asumir que la culpa es del usuario, y no del proveedor, los problemas legítimos a menudo no se controlan o no se gestionan, solo para ser descubiertos en una fecha mucho más tarde como parte de una auditoría de errores o una actualización que rompe funciones.

La mejor manera de solucionar estos problemas es involucrar al usuario en una conversación sobre lo que percibe como "frustrante". En lugar de hacer una pregunta clave, como "dónde falla a menudo su uso" o "qué cree que no puede hacer", pregunte acerca de sus frustraciones . Esto conducirá a una mayor comprensión de la funcionalidad de su API y, potencialmente, puede resaltar problemas que de otro modo no se abordarían.

Preguntar acerca de las frustraciones comunes ayuda a informar dónde falla su experiencia de usuario. Cuando un usuario se encuentra con algo frustrante, a veces es el resultado de una navegación confusa, documentación deficiente o notaciones de funcionalidad defectuosas. Resaltar estas fallas y abordarlas mejora la experiencia del usuario y, por lo tanto, mejora la calidad de su API .

En segundo lugar, permitir que sus usuarios desahoguen sus frustraciones ayuda a guiar el desarrollo al mostrar debilidades en la funcionalidad. Cuando surgen frustraciones que no están relacionadas con la documentación u otros problemas similares, se deben en gran parte a una funcionalidad deficiente. Un usuario puede encontrar frustrante una llamada cuando no funciona como se esperaba o devuelve datos incompletos.

Si bien esto a menudo se corrige por parte del usuario o se procesa mediante la corrección de errores, encontrar estos problemas desde el principio y corregirlos ayuda a que el desarrollo vaya por el camino correcto. Identificar problemas comunes y rectificarlos puede convertir una API mediana en un servicio realmente útil y funcional para los usuarios de la API.

Por último, y lo más importante, los proveedores deben crear un canal de comunicación con los usuarios desarrolladores. Ya sea que esto signifique tener foros oficiales de API, un administrador de Twitter para desarrolladores, una dirección de correo electrónico pública o incluso un formulario personalizado de Google, garantizar que haya un camino para desahogarse y discutir es tan importante como aceptar estos comentarios.

Claves de API ≠ Seguridad: descubra por qué los proveedores deberían asumir más responsabilidades para proteger sus API

¿Por qué eligió nuestra API?

Un "usuario potencial" tiene un uso métrico limitado, ya que es un completo desconocido. Los usuarios potenciales son comodines y atraerlos a su API en primer lugar puede ser un proceso de descubrimiento complejo . Sin embargo, los "usuarios actuales" representan métricas importantes y de gran valor porque todos comparten intereses comunes que los atrajeron a su API. Las métricas son una herramienta increíblemente importante y poderosa para los desarrolladores de API , y no aprovechar este tipo de métricas podría condenar una API a la oscuridad y la baja integración del usuario.

Preguntar por qué los usuarios eligieron su API en particular sobre el conjunto de otras opciones que se ofrecen hace mucho para informar al desarrollador no solo sobre los deseos y comportamientos específicos del usuario, sino que también ayuda a definir su propuesta de valor única y ayuda a sus intentos de marketing a dirigirse a otros establecer demográfico.

La economía de las API ha evolucionado y ahora hay muchos tipos de consumidores que utilizan API . Es probable que tenga una gran cantidad de datos demográficos sobre su usuario específico; grupos de edad, perfiles de navegador y hardware, ubicación geográfica, etc. Emparejar este perfil con lo que atrajo específicamente a diferentes consumidores a su API podría ser un conocimiento poderoso para segmentar campañas de marketing lean.

Si sabe por qué las personas acuden en masa a su API, el desarrollo futuro se puede orientar hacia la especialización, enfatizando las cualidades y funcionalidades consideradas "únicas" y "atractivas" para estos usuarios, al tiempo que mitiga los aspectos negativos que de otro modo podrían haberlos rechazado.

Sin embargo, tenga en cuenta que se puede reaccionar de forma exagerada a este tipo de datos, lo que lleva a la "regla de la mafia". Si bien es importante adaptarse a los deseos y deseos del grupo de usuarios mayoritario, es igualmente importante que los desarrolladores intenten evitar el aumento y la hinchazón de las funciones. Esta filosofía se conoce más comúnmente como la regla 80/20 en el desarrollo de software ágil.

Si pudiera cambiar nuestra API, ¿cómo lo haría?

A veces, la mejor manera de obtener información útil y procesable es simplemente pedirla. Preguntar a sus usuarios qué cambiarían de su API es similar a esa vieja pregunta de "si usted fuera presidente / rey", y abre una vía de cambio directo que de otra manera quedaría oculta.

La clave para implementar esta pregunta de manera efectiva es pedir respuestas específicas y viables. Una respuesta como "mejor integración con los servicios de medios" no es una respuesta procesable, ya que no enumera los servicios con los que el usuario le gustaría integrarse mejor, ni cómo esos servicios se relacionan con la funcionalidad de la API.

Una mejor respuesta sería algo así como “herramientas mejoradas para integrarse con extensiones de medios al paquete de manejo de datos de API”. Cuando se dan respuestas, se deben solicitar detalles adicionales como parte integral.

Tenga en cuenta que debe comunicarse claramente a los usuarios que no todos los cambios son posibles. Los cambios en la funcionalidad principal fuera de la expansión planificada, los cambios en la forma en que los servicios interactúan cuando causarían interrupciones de funciones, etc., deben tenerse en cuenta como advertencias.

Métodos a utilizar para acumular comentarios

Todo esto está muy bien, pero todas las preguntas del mundo no importarán sin tener un medio eficaz por el cual se pueda formular y recopilar la pregunta. Los proveedores de API pueden encontrarse rápidamente en una especie de trampa 22: obtener esta retroalimentación es importante, pero la fuente de esta retroalimentación puede determinar su responsabilidad, y el método de adquisición podría incluso alejar a los consumidores.

Del mismo modo, comprender cuándo hacer estas preguntas es tan importante como averiguar cómo hacerlas. No existe una respuesta mágica a esta pregunta, pero si observamos dos aplicaciones teóricas de estos conceptos, podemos ver algunas cosas que se deben evitar, así como algunos métodos que sobresalen.

Ejemplo uno: cuestionamiento ineficaz

Un proveedor de API con el nombre de Laboratorios KAL, o KAL para abreviar, está realizando una encuesta de su base de usuarios para mejorar la rentabilidad e identificar nuevos mercados. El programador principal, Shawn, decide comenzar el cuestionario con una serie de preguntas técnicas.

Estas primeras preguntas giran en torno a los lenguajes utilizados por la API y contienen preguntas como "¿te gusta la integración de la API de Twitter que hicimos con el paquete de manejo de datos?" y "¿Qué opinas sobre el uso de Go?".

El cuestionario se pasa a la especialista en recursos públicos, Sandra, quien agrega sus propias preguntas. Cosas como "¿sabías sobre nuestro trabajo con organizaciones benéficas sin fines de lucro?" y "¿Cuáles son sus sitios web favoritos?" abundar.

Finalmente, el cuestionario se edita ligeramente, se pone en un formulario de stock y se envía por correo electrónico a todos los usuarios que han registrado su correo electrónico como parte del proceso de registro de la API. El cuestionario obtiene muy pocas respuestas y la base de usuarios declina.

¿Qué salió mal?

Desde el principio, hay algunos problemas importantes con la metodología mediante la cual se elaboró ​​este cuestionario. En primer lugar, el alcance es extremadamente amplio: identificar nuevos mercados y aumentar los ingresos por monetización es un tema enorme y por el que los encuestados podrían sentirse fácilmente desanimados.

En segundo lugar, las preguntas no son muy útiles. Debido a que el tono de las preguntas varía enormemente dependiendo de quién las haga, y van de un nivel técnico alto a uno “esponjoso”, el cuestionario sería difícil de tomar en serio en el mejor de los casos y molesto en el peor. Incluso si las preguntas estuvieran bien formadas, proporcionarlas en forma de stock sin marca ni explicación hace que sea más fácil ignorar la encuesta.

Finalmente, el cuestionario se distribuyó de forma molesta. Los encuestados probablemente no sabían que sus correos electrónicos se usarían para análisis como este y, como tal, cuando se ven inundados con lo que es esencialmente correo no deseado, sus opiniones tanto sobre el proveedor de API como sobre su producto disminuirán rápidamente.

Ejemplo dos: cuestionamiento eficaz

Al ver la mala respuesta a su primer cuestionario, KAL decide reevaluar su enfoque. En primer lugar, miran sus motivos y preguntas. Su objetivo original declarado era investigar cómo "mejorar la rentabilidad" e "identificar nuevos mercados". Si bien estos son objetivos comprensibles, no están debidamente enmarcados. La mejora de la rentabilidad viene con la comprensión de por qué las ganancias están deprimidas artificialmente, y la identificación de nuevos mercados viene con la comprensión de lo que hace bien su API (e igualmente lo que hace mal).

Con esto en mente, un equipo se reúne para discutir un nuevo cuestionario. En lugar de depender de solo dos personas para construir la encuesta, las preguntas se envían al equipo de relaciones públicas para su verificación, se seleccionan un puñado de 10 y la encuesta se reestructura para facilitar la retroalimentación con preguntas fáciles desde el principio. Toda la experiencia se revisa y refina internamente.

Comienza una prueba limitada. Se pregunta a un grupo de “usuarios avanzados” si les gustaría responder un cuestionario durante una conversación de soporte de rutina. Aceptan hacerlo y responden la encuesta. Dan sus respuestas no solo a las preguntas de la encuesta, sino a preguntas específicas sobre la calidad de la encuesta en sí.

Con esta información, el equipo vuelve a revisar las preguntas y las examina antes de enviar una llamada de correo electrónico general. Esta vez, en lugar de llamar en frío a sus usuarios, simplemente notifican a la base de usuarios que comenzarán a emitir encuestas periódicas para mejorar la funcionalidad, y que los usuarios simplemente pueden optar por no recibirlas.

Después de un breve período, se envía la primera encuesta, se analizan las métricas y la actividad se considera un éxito rotundo.

Lo que salió bien

Lo más importante aquí es el hecho de que todo se hizo mediante un proceso. Antes, todo, desde la construcción de la encuesta hasta su aplicación, era desordenado. En esta variación, el equipo no solo identificó lo que específicamente querían saber, sino que también discutió cómo preguntar.

Esta investigación es clave para el proceso. Si bien un ingeniero puede legítimamente querer saber qué piensa un usuario de su código complejo y la interfaz resultante, la pregunta no debería ser "¿Cuál es su opinión sobre nuestra página frontal en vivo?", Sino más bien, "¿Es nuestro portal fácil de usar?" ? ”.

A continuación, el equipo se acercó a un número selecto de usuarios confiables para probar estas preguntas. Poder probar preguntas en un microcosmos le brinda la ventaja de extrapolar las respuestas generales a su encuesta sin incurrir realmente en el costo de realizar la encuesta.

Finalmente, una vez que se probaron estas preguntas, el equipo se acercó a los usuarios para informarles de sus intenciones y darles una opción de exclusión voluntaria. Forzar preguntas sobre su base de usuarios es ineficaz y contraproducente. Más bien, dígales a sus usuarios por qué existe su encuesta y hágalo completamente opcional. Esto le da al usuario una sensación de control y aumenta el valor de su respuesta, así como la frecuencia con la que responderá el usuario medio.

Vea lo que significa la promoción eficaz de los desarrolladores en El día en la vida de un evangelista de API

Piense como usuario

Al final del día, compilar este tipo de preguntas es increíblemente útil para un proveedor de API. Ayuda a validar la dirección de su producto, así como la viabilidad, necesidad y deseo de servicios adicionales con nuevas posibilidades de monetización.

La conclusión de todo esto es simple: piense como un usuario . Imagínese iniciar sesión en su correo electrónico un día para encontrar una gran encuesta que le impuso una empresa que en un momento pensó que no era intrusiva y respetaba la privacidad. Imagina que esta encuesta está llena de errores gramaticales, preguntas sin sentido y terminología confusa. ¿Cómo responderías?

Tenga esto en cuenta al formular sus preguntas y realizar sus encuestas: podría significar la diferencia entre el análisis informativo y una reputación arruinada. Sin embargo, si se hace bien, un proceso de encuesta demostrará que realmente comparte el viaje de su usuario desarrollador y el camino hacia el éxito.

Publicar un comentario

0 Comentarios