Cómo hago Developer UX en Google

Explicado a través de un estudio de usuario de Flutter

Cuando las personas hablan sobre la experiencia del usuario (UX), a menudo hablan sobre sus queridos productos de consumo: un teléfono inteligente, una aplicación de mensajería o quizás un par de auriculares.

La experiencia del usuario también es importante cuando construyes algo para desarrolladores. La gente tiende a olvidar que los desarrolladores también son usuarios, y el desarrollo de software es una actividad intrínsecamente humana limitada no solo por la forma en que funcionan las computadoras, sino también por cómo funcionan los programadores. Es cierto que hay menos desarrolladores que consumidores en general, pero cuanto más útiles sean las herramientas para desarrolladores, más energía pueden gastar los desarrolladores para entregar valor a sus usuarios. Por lo tanto, la experiencia de usuario de los productos para desarrolladores es tan importante como para los productos de consumo. En esta publicación, voy a presentar la experiencia del desarrollador, explicar una de las formas en que la evaluamos en Google y compartir algunas lecciones que aprendimos de un estudio específico que realizamos en Flutter, un nuevo SDK para crear hermosas aplicaciones móviles.

La idea de la experiencia del desarrollador no es exactamente nueva. La investigación sobre la experiencia del desarrollador se remonta a los primeros días de la informática, ya que todos los usuarios en ese momento eran desarrolladores hasta cierto punto. "The Psychology of Computer Programming", publicado en 1971, es un libro histórico sobre el tema. Cuando hablamos de la experiencia del desarrollador, especialmente aplicando el término a un SDK o biblioteca, generalmente nos referimos a tres aspectos del producto:

  • Diseño de API, que incluye el nombramiento de clases, métodos y variables, el nivel de abstracción de la API, la organización de la API y la forma en que se invoca la API.
  • Documentación, que incluye tanto la referencia de API como otros recursos de aprendizaje, como tutoriales, instrucciones y guías para desarrolladores.
  • Herramientas, que involucra tanto la interfaz de línea de comandos (CLI) como las herramientas GUI que ayudan a editar, depurar y probar el código. Por ejemplo, la investigación ha demostrado que el autocompletado en el IDE tiene un gran impacto en cómo se descubren y usan las API en la programación.

Estos tres pilares de la experiencia del desarrollador se complementan entre sí, por lo que deben diseñarse y evaluarse como un paquete.

¿Cómo observamos la experiencia del desarrollador?

Uno de los métodos de investigación que utilizamos para evaluar la experiencia del desarrollador es observar cómo los desarrolladores reales llevan a cabo una tarea de programación realista utilizando nuestro SDK y herramientas de desarrollo. Este método, llamado prueba de usuario, se usa ampliamente en la investigación de UX del consumidor, y lo adaptamos para evaluar los productos del desarrollador. En este estudio específico sobre Flutter, invitamos a 8 desarrolladores profesionales y les pedimos a cada uno de ellos que implementaran la maqueta a la izquierda.

Una técnica clave involucrada en este proceso es el protocolo de pensar en voz alta. Es un protocolo de informe verbal desarrollado por Clayton Lewis en IBM y es útil para entender el razonamiento del participante detrás de sus acciones. Les dimos a nuestros participantes las siguientes instrucciones:

"Mientras trabaja en el ejercicio de programación," piense en voz alta ". Eso significa describir verbalmente su proceso mental a medida que se desarrolla, incluidas las dudas y preguntas que tiene, las estrategias de solución que considera y las razones que justifican sus decisiones".

Además, aseguramos a nuestros participantes que estábamos evaluando Flutter, no sus habilidades de programación:

"Recuerde que estamos probando la experiencia de desarrollador de Flutter, no es una prueba suya. Por lo tanto, cualquier cosa que encuentre confusa es algo que debemos arreglar ”.

Comenzamos cada sesión con una entrevista de calentamiento sobre los antecedentes del participante, y luego tuvieron unos 70 minutos trabajando en la tarea. En los últimos 10 minutos de la sesión, informamos al participante sobre su experiencia. Cada sesión de estudio, incluida la pantalla de la computadora del participante, se transmitía en vivo en privado a una sala de conferencias separada, observada por varios ingenieros del equipo de producto. Para proteger la privacidad de los participantes, nos referiremos a ellos por identificadores (p. Ej., P1, P2, P3, etc.) que no sean sus nombres en esta publicación.

Entonces, ¿qué aprendimos sobre la experiencia del desarrollador de este estudio?

1. Proporcione muchos ejemplos y preséntelos de manera efectiva

Después de unas pocas sesiones de prueba de usuarios, quedó claro que los desarrolladores esperaban aprender a trabajar con un nuevo SDK a partir de ejemplos. Sin embargo, el problema no era que Flutter no proporcionara suficientes ejemplos: tenía toneladas de ejemplos en su repositorio de Github. El problema era que esos ejemplos no estaban organizados y presentados de una manera que fuera realmente útil para los participantes de nuestro estudio por dos razones:

Primero, las muestras de código en el repositorio Github de Flutter carecían de capturas de pantalla. En ese momento, el sitio web de Flutter proporcionaba un enlace para buscar todos los ejemplos de código que contenían una clase de widget en particular en su repositorio de Github, pero era difícil para los participantes determinar qué ejemplo produciría el resultado deseado. Debía ejecutar el código de ejemplo en un dispositivo o un simulador para ver la apariencia del widget, que nadie se molestó en hacer.

“Esto es bueno, vinculando al código real. Pero es muy difícil elegir cuál le gustaría usar a menos que vea el resultado ". (P4)

En segundo lugar, los participantes esperaban tener un código de muestra en la documentación de la API, no en un lugar separado. La prueba y error es una forma común de aprender una API, y los fragmentos cortos en los documentos de la API permiten ese método de aprendizaje.

"Hago clic en" Documentación ", pero son las API, no las muestras" (P4)

Varios ingenieros del equipo de Flutter observaron sesiones de estudio a través de la transmisión en vivo, y les sorprendieron los desafíos que experimentaron algunos participantes. Como resultado, el equipo ha estado agregando constantemente más código de muestra a los documentos API de Flutter (por ejemplo, ListView y Card).

Además, el equipo comenzó a construir un catálogo visual curado para muestras de código más grandes. Solo hay un puñado de muestras por ahora, pero cada muestra presenta una captura de pantalla y un código autónomo, por lo que los desarrolladores pueden determinar rápidamente si una muestra es útil para su problema.

2. Acomodar las habilidades cognitivas de los desarrolladores.

La programación es una actividad cognitivamente intensa. En este caso, encontramos que escribir un diseño de interfaz de usuario puramente en código era difícil para algunos desarrolladores. En una aplicación Flutter, construir un diseño implica seleccionar y anidar widgets en un árbol. Por ejemplo, para crear el diseño en la tarjeta de información del café, debe organizar varios widgets de fila y varios widgets de columna correctamente. No parecía una tarea difícil, pero tres participantes mezclaron Fila y Columna cuando intentaron crear ese diseño.

"¿Me puede decir cuál esperaba que fuera la salida?" (Moderador)
[Hablando sobre lo que quería hacer] "Oh ... probablemente debería haber usado una columna, no una fila" (P6)

Nos dirigimos a la psicología cognitiva para obtener explicaciones. Resulta que construir un diseño en código requiere la capacidad de razonar sobre la relación espacial entre los objetos, y los psicólogos cognitivos lo conocen como la capacidad de visualización espacial. Es la misma habilidad que influye en qué tan bien una persona puede explicar las direcciones de conducción o rotar un cubo mágico.

Este hallazgo ha cambiado la opinión de algunos miembros del equipo sobre la necesidad de un generador de interfaz de usuario visual. El equipo estaba muy emocionado de ver exploraciones impulsadas por la comunidad en este frente, como este generador de interfaz de usuario basado en web llamado Flutter Studio.

3. Promover el reconocimiento sobre el retiro

Es un principio UX bien conocido que las interfaces de usuario deben evitar obligar a los usuarios a recuperar información (por ejemplo, un comando o parámetro arcano). En cambio, la interfaz de usuario debe permitir a los usuarios reconocer posibles cursos de acción.

¿Cómo es este principio relevante para el desarrollo de software? Un problema que observamos fue que no era intuitivo comprender el comportamiento de diseño predeterminado de los widgets de Flutter y descubrir cómo cambiar su comportamiento. Por ejemplo, P3 no sabía por qué la Tarjeta, por defecto, se redujo al tamaño del Texto que contenía. P3 tuvo problemas para descubrir cómo hacer que la tarjeta llene el ancho de la pantalla.

cuerpo: nueva tarjeta (
  hijo: nuevo texto (
    "1625 Charleston Road, Mountain View, CA 94043"
  )
),
"Lo que quería es que ocupe todo el ancho de la pantalla". (P3)

Por supuesto, muchos programadores pueden descubrirlo eventualmente, pero necesitan recordar cómo hacerlo la próxima vez que enfrenten el mismo problema. No había pistas visibles para que los desarrolladores reconocieran una solución en esa situación.

El equipo está explorando algunas instrucciones para reducir la carga del recuerdo en los diseños de edificios:

  • Resumiendo los comportamientos de diseño de los widgets para facilitar su razonamiento.
  • Ofreciendo muestras de diseño con código e imágenes para convertir algunas tareas de recuperación en tareas de reconocimiento
  • Proporcionar un inspector de estilo Chrome para mostrar el "valor calculado" de una propiedad de widget

4. Espere que los desarrolladores sean ciegos a algo "justo en frente de ellos"

Una característica de la que el equipo Flutter está realmente orgulloso es Hot Reload. Permite al desarrollador aplicar cambios a una aplicación en ejecución en 1 segundo, sin perder el estado de la aplicación. Realizar una recarga en caliente es tan simple como hacer clic en un botón en IntelliJ IDE o presionar "r" en la consola.

Sin embargo, en las primeras sesiones del estudio, el equipo estaba desconcertado por la expectativa de algunos participantes de activar Hot Reload en el archivo guardado, a pesar de que el botón Hot Reload se mostraba en un gif animado en las instrucciones de Inicio. ¿Cómo podrían no ver el botón Hot Reload?

Resultó que los participantes que perdieron el botón Hot Reload y esperaban activar la recarga al guardar eran usuarios de React Native. Nos dijeron que en React Native, Hot Reload se realizaba automáticamente al guardar el archivo.

El modelo mental preexistente de un desarrollador puede alterar su percepción y conducir a un cierto grado de "ceguera" a los elementos de la interfaz de usuario. El equipo ha agregado más señales visuales para ayudar a descubrir el botón Hot Reload. Además, algunos ingenieros han estado investigando una forma confiable de permitir la recarga al guardar para los usuarios que la necesitan.

5. No asuma que los programadores leen palabras en inglés como se espera cuando aparecen en el código

En Flutter, todo es un widget. Una interfaz de usuario se compone principalmente a través de widgets de anidación. Algunos widgets tienen solo un hijo, mientras que otros aceptan varios hijos. Esta distinción se indica por la existencia de una propiedad "secundaria" o una propiedad "secundaria" en una clase de widget. Suena bastante sencillo, ¿verdad?

Nosotros también pensamos eso. Sin embargo, para algunos participantes, la forma singular de la palabra no indicaba con éxito que solo un widget podría anidarse en el widget actual. Dudaban de que "niño" realmente significara "solo uno".

"Estoy pensando que el" niño "puede ser múltiples o no. ¿Puedo pasar una matriz o solo una es posible? ”(P2)
"Entonces el" niño "será 4 cosas, el primer elemento, un separador y dos elementos más". (P2)

Esta interpretación errónea de la semántica del nombre de la propiedad condujo a un código erróneo como este:

Y el mensaje de error que se muestra en este caso, aunque es exacto, no fue lo suficientemente accionable como para empujar al participante nuevamente en el camino correcto:

Es fácil descartar lo que sucedió aquí como un error de principiante. Sin embargo, el equipo no se sintió cómodo al ver a un desarrollador profesional perder varios minutos lidiando con este simple problema. Por lo tanto, se obtuvo una solución a corto plazo unos días después de que se informaron los resultados del estudio. Agregó uno de los widgets multi-hijo más útiles, Column, a la plantilla de la aplicación que obtienes al ejecutar el comando "flutter create". El objetivo es exponer la diferencia entre "niño" y "niños" a un nuevo desarrollador lo suficientemente temprano, para que no pierdan el tiempo descubriendo eso más tarde. Además, algunos miembros del equipo están investigando una solución a largo plazo para mejorar la capacidad de acción de los mensajes de error en situaciones como esta y más allá.

Conclusión

Podemos aprender mucho observando que los desarrolladores usan API y aplican los aprendizajes para mejorar la experiencia del usuario de un producto de desarrollador. Si escribe algún código o crea una herramienta que utilizan otros desarrolladores, le recomendamos que observe cómo la usan. Como dijo un ingeniero de Flutter, siempre aprendes algo nuevo al observar un estudio de usuario. A medida que el software continúa impulsando cambios en el mundo, asegurémonos de que los desarrolladores sean lo más productivos y felices posible.