Mayo de 2016
Volumen 31, número 5
Visual Studio: promoción de prácticas de Lean UX
Por Karl Melder | Mayo de 2016
En Visual Studio 2015, Microsoft introdujo varias características de depuración y diagnóstico nuevas, que Andrew Hall detalla en el artículo de marzo de 2016 de MSDN Magazine, "Visual Studio: mejoras en la depuración de Visual Studio 2015" (msdn.com/magazine/mt683794). Para las características que implican cambios sustanciales en la experiencia de usuario, Microsoft adoptó un enfoque "Lean UX" mediante experimentos iterativos con comentarios directos de usuarios para formar el diseño.
Quiero compartir con usted el proceso que se usaba para diseñar una de estas características, Sugerencias de rendimiento, junto procedimientos recomendados, consejos y trucos recopilados en su transcurso. El objetivo es inspirar y permitir que tanto usted como sus equipos incorporen de manera eficaz los comentarios de los clientes directamente en sus procesos de desarrollo.
Lean UX
Lean UX es un complemento para las prácticas de desarrollo lean que marcan tendencia en el sector. Eric Ries definió lean como el procedimiento de "crear, medir y aprender" en su libro de 2011, "El método Lean Startup" (Deusto S.A. Ediciones), donde describe un enfoque de "empresa-hipótesis-experimentación dirigida". De manera similar, Lean UX es un conjunto de principios y procesos que se centra en la validación muy temprana y continua del cliente, con experimentos para validar la hipótesis de diseño del producto y el usuario en ciclos extremadamente cortos. Las iteraciones del diseño se realizan rápidamente con un enfoque en la resolución de problemas reales del usuario. Una buena referencia es el libro de Jeff Gothelf de 2013, "Lean UX" (UNIR Editorial), donde proporciona instrucciones y hojas de cálculo para ayudar a los equipos a aclarar aquello en lo que creen o esperan conseguir.
Para el equipo que proporciona la experiencia de depuración en Visual Studio, Lean UX es un enfoque altamente colaborativo, donde todo el equipo, incluidos administradores de programas, investigadores de experiencias de usuario, desarrolladores y diseñadores de experiencias de usuario, estaba implicado en la generación de ideas, la generación de hipótesis y la interpretación de lo que habían oído y visto de nuestros clientes.
Este artículo trata de la adopción completa de los comentarios de clientes en el proceso de desarrollo del producto. Se trata de aprender de los fallos rápidamente. Se trata de obtener comentarios sobre sus ideas sin bits de trabajo. Se trata de que no solo lo haga un equipo de la división de herramientas de desarrollo, sino de que muchos equipos cambien fundamentalmente cómo se diseñan las características en el proceso de desarrollo lean.
El desafío del diseño
La tecnología de Microsoft cuenta con un completo origen de datos que puede proporcionar a los desarrolladores un método apropiado para diagnosticar problemas. No obstante, en los laboratorios de experiencias de usuario, los usuarios volverían a recorrer manualmente la ejecución del código, a pesar de las ventajas que ofrecen esas herramientas, como el generador de perfiles. Los datos de instrumentación corroboran el bajo uso del generador de perfiles de Visual Studio, a pesar de la convicción de que puede mejorar notablemente la eficiencia del proceso de búsqueda de problemas de rendimiento. Para una herramienta como Visual Studio, donde un usuario invierte ocho o más horas por día laborable, pedirle que cambie su manera de trabajar puede ser un tema peliagudo. Así, el equipo quería aprovechar el estilo de trabajo natural del usuario al depurar problemas de rendimiento y ofrecer una experiencia ambiental.
Con un enfoque de cascada más tradicional adoptado, los grupos de enfoque se podrían haber dirigido para obtener los primeros comentarios, una especificación detallada por escrito y, una vez el código estuviera casi completado, también se podrían haber programado estudios de la posibilidad de uso. Se podrían haber asignado tareas a un usuario para ejercitar las nuevas características y triar los problemas detectados, como se lleva a cabo con los errores. Para Visual Studio 2015, se optó por un enfoque muy diferente.
El proceso de investigación
En lugar de programar estudios de las posibilidades de uso cuando había bits de trabajo disponibles, se preprogramaron dos usuarios cada viernes para la mayor parte del ciclo del producto. Estos días se conocían de manera informal como "viernes intensivos". Los usuarios entraban durante unas dos horas, donde su tiempo se repartía por lo general en dos o cuatro experimentos. Para cada experimento, se realizaba un cálculo estimativo sobre cuánto tiempo debía dedicarse. Cada experimento consistía en ayudar a Microsoft a obtener más información de sus usuarios y cómo trabajaban, o en probar una idea. Las ideas de diseño debían sobrevivir tres semanas como mínimo después de obtener resultados positivos para poder avanzar con ellas. Un resultado positivo indicaba que los usuarios realmente sentían que les ofrecía valor, mayor detectabilidad y un uso más simple, así como que podía mostrar mejoras para los principales escenarios.
La investigación de la experiencia de usuario se suele clasificar en cuantitativa y cualitativa, donde una combinación de instrumentación/análisis y comentarios de clientes guía el desarrollo de productos y empresarial. En las primeras investigaciones cualitativas, los comentarios equivalían a obtener la reacción de los usuarios a las ideas. El equipo tuvo en cuenta no solo lo que dijeron, sino también la reacción física, las expresiones faciales y el tono de voz. También se asignó a los usuarios una tarea real, como corregir un error de rendimiento en una aplicación sin la ayuda del equipo de investigación mientras eran observados, como se muestra en la foto de la Figura 1. Ello significaba dejar que los usuarios se esforzaran. El equipo los grabaría en vídeo para revisarlo posteriormente y tomaría notas sobre lo que oía y veía. Observar a los usuarios ayudó al equipo a comprender su estilo de trabajo y a identificar necesidades no articuladas que un usuario quizás no sabía pedir, pero podían proporcionar una mejora drástica para el producto.
.png "Sesión de investigación con un usuario")
Figura 1 Sesión de investigación con un usuario
Lo que fue decisivo para el éxito del equipo fue no invertir tiempo intentando convencer a los clientes para que les gustase una idea. Simplemente se mostró la idea a los usuarios en términos de cómo sería usarla. Entonces, el equipo dio un paso atrás y se dedicó a escuchar, ver y formular preguntas para comprender los puntos de vista de los usuarios. La clave para el éxito del equipo era la capacidad de distanciarse de una idea o un diseño que quizás había considerado encarecidamente.
Cada semana, se contrataban distintos participantes para lograr un flujo constante de nuevas perspectivas. Había un equipo interno y un proveedor que contrataban, filtraban y programaban a los usuarios. El equipo no buscaba usuarios con experiencia específica en diagnósticos; en su lugar, el perfil de contratación consideraba simplemente a usuarios activos de Visual Studio. Esto significaba que cada semana había usuarios con distintas aptitudes, experiencias y contextos laborales. Esto daba al equipo la oportunidad de aprender algo nuevo cada semana e identificar las incoherencias. El equipo también pudo hacer evolucionar sus ideas para que funcionasen con un público más amplio.
Igualmente importante fue equilibrar la interacción del equipo con los usuarios. La manera de formular una pregunta podía afectar drásticamente al resultado e influir en la conversación. El equipo desarrolló el hábito de formular siempre preguntas abiertas, donde las preguntas incisivas se derivaban de lo que el usuario había dicho o hecho. Por ejemplo, si un usuario indicaba al equipo que no le gustaba algo, simplemente preguntaba: "díganos algo más al respecto". El equipo intentó no suponer nada y retaba sus suposiciones e hipótesis a cada oportunidad. Estas habilidades son básicas para el campo de experiencia de usuario y todos los miembros del equipo las adoptaron. Si quiere obtener más información sobre estas técnicas de entrevista, le recomiendo el libro de Cindy Alvarez de 2014, "Desarrollo de Clientes LEAN" (UNIR Editorial).
Primeras sesiones intensivas y estilo de trabajo firme
Al principio del ciclo del producto, el equipo comenzó con una idea para ayudar a los usuarios a supervisar el rendimiento de su código. El equipo creó un boceto y lo presentó a los usuarios de los viernes intensivos. Lo que se comentaba constantemente, incluso tres semanas después de las alteraciones del diseño, era que no estaban seguros de cuál era su finalidad y que "probablemente lo descartarían". No era necesariamente lo que el equipo quería oír, pero necesitaban oírlo.
No obstante, mientras se observaba a los usuarios diagnosticar los problemas de la aplicación, quedó claro que el equipo necesitaba una experiencia de usuario que formara parte más directamente de la experiencia de navegación del código. Aunque había varias ventanas del depurador que proporcionaban información adicional, era difícil para los usuarios prestar atención a todas ellas al mismo tiempo. El equipo observó que muchos usuarios centraban la atención en el código, a menudo "recorriendo con el código" mentalmente la ejecución. Esto podría parecer obvio para cualquier desarrollador que lea este artículo, pero lo fascinante era la firmeza del estilo de trabajo, a pesar de la disponibilidad de herramientas adicionales destinadas a mejorar la eficacia de esa tarea.
El equipo comenzó a concebir ideas usando Photoshop, donde un diseñador con la máxima experiencia podía tardar más de un día en generar un boceto que se pudiera usar para comentarios. Photoshop tiende a prestarse a la creación de una UI de alta fidelidad. En su lugar, el equipo comenzó a usar Microsoft PowerPoint y un complemento de guion gráfico (aka.ms/jz35cp) que permitía a todos los miembros del equipo crear representaciones de fidelidad media de sus ideas. Estos guiones gráficos ofrecían a los usuarios una idea del aspecto que podía tener, pero era bastante difícil para los usuarios explicar que se trataba de un diseño en curso y que su entrada tenía un impacto directo. El efecto neto es que era mucho más fácil deshacerse de una inversión de 30 minutos cuando un experimento fallaba. Asimismo, se podían probar ideas que el equipo sabía que no iban a funcionar en la práctica, pero los comentarios de los usuarios ayudarían a generar nuevas ideas.
Para obtener comentarios sobre el modelo de interacción del usuario, cada diapositiva de los lotes de PowerPoint representaba una acción del usuario o una respuesta del sistema a dicha acción. Al esbozar la interacción, se incluiría una imagen de icono de cursor para mostrar dónde podía hacer clic el usuario. Resultaba útil al compartir ideas y resolver los detalles. No obstante, el icono de cursor se quitaría antes de mostrarse a los usuarios. Esto permitía al equipo preguntar a los usuarios qué iban a hacer a continuación, proporcionándoles así un método de descarte para identificar posibles problemas de detectabilidad. Por cada diapositiva de respuesta del sistema, el equipo también preguntaría si los usuarios sentían que progresaban, lo que permitiría al equipo saber si proporcionaba comentarios adecuados. Esta técnica de comentarios se denomina "proceso de tutorial cognitivo" en la investigación de experiencias de usuario y puede ayudarle a identificar algunos problemas en las primeras etapas del diseño de su interacción, y ofrecerle al mismo tiempo una primera idea de las áreas problemáticas que requerirán más iteración y experimentación para funcionar.
Para determinar el impacto potencial de una idea, el equipo se fió de la capacidad del usuario para articular específicamente cómo podría usar la idea en su entorno laboral cotidiano y cuáles eran, según su percepción, las ventajas y desventajas directas. El usuario tenía que proporcionar ejemplos detallados y plausibles para que el equipo confiara en que valía la pena seguir aquella idea. El equipo también observaba si el usuario prestaba más atención, mostraba más entusiasmo o expresaba emoción. El equipo buscaba ideas para entusiasmar a los usuarios y para intentar conseguir un impacto positivo en su experiencia de diagnóstico.
"¡Es sorprendente!"
El equipo necesitaba un método para mostrar la información de rendimiento en el código que no afectara a la legibilidad del código y que proporcionara a los usuarios una experiencia ambiental de depuración en código. CodeLens, una característica de Visual Studio que permite ver información sobre el historial de ediciones, los errores, las pruebas unitarias y las referencias, proporcionó inspiración para un posible modelo de interacción y un diseño visual. El equipo experimentó con bocetos de varias ideas que mostraban a los clientes cómo, mientras un desarrollador seguía el código, las cifras de rendimiento se mostraban en milisegundos (consulte la Figura 2).
.png "Boceto anticipado que muestra los datos de rendimiento en una sesión de depuración")
Figura 2 Boceto anticipado que muestra los datos de rendimiento en una sesión de depuración
La primera indicación de que el equipo tenía algo era cuando un participante (un administrador de desarrollo) mostraba un gran entusiasmo al pasar por la experiencia. Debería hacer hincapié en que solo se le mostraba la experiencia propuesta, sin ninguna información de referencia. A medida que se daba cuenta de lo que veía, empezaba a formular preguntas concretas y mostraba bastante entusiasmo mientras hablaba. Comentaba que sería una solución a un problema que tenía con sus desarrolladores noveles, quienes tomaban decisiones de codificación poco acertadas que daban como resultado un rendimiento deficiente de las aplicaciones. En su proceso actual, los problemas de rendimiento se resolvían por medio de un arduo proceso de revisión de código, que suponía una pesada carga para él y para su equipo. Creía que esta idea podía ayudar a sus desarrolladores noveles a aprender a escribir código de mayor rendimiento en sus primeros trabajos. Algunos de sus comentarios fueron: "¿Esta [sugerencia de rendimiento] puede ser una directiva [en Visual Studio]?" Otro usuario, tras reconocer su valor, comentó lo siguiente: "Lo extraordinario de Visual Studio son las funcionalidades cuando te encuentras en una línea de código."
Estos comentarios anticipados también entusiasmaban al equipo, ya que esta característica potencial era un punto de entrada para las herramientas de diagnóstico, lo que resolvía algunos problemas de detectabilidad. El equipo conjeturó que estas sugerencias de rendimiento podían ser un desencadenador para que los usuarios se atreviesen con nuestro conjunto de herramientas más completo.
Diseño de los detalles
Todo lo hecho hasta este punto implicaba solo bocetos, sin ninguna inversión en codificación. Si las ideas ganaban terreno, se creaban niveles de detalles superiores en la funcionalidad "click-through" de PowerPoint, así como numerosas alternativas de diseño con las que experimentar semanalmente. No obstante, el límite de lo que se podía hacer con los bocetos se alcanzó cuando aún quedaban algunos problemas de investigación:
- Validar que el diseño de sugerencias de rendimiento al depurar problemas de lógica comunes no fuera una distracción, pero siguiera siendo detectable al tratar problemas de rendimiento.
- El equipo quería que los usuarios interpretaran correctamente las cifras de rendimiento, que se medían desde la última interrupción de la ejecución.
- Los usuarios habían sugerido mostrar solo los valores cuando el rendimiento fuera preocupante, pero nadie pudo sugerir con seguridad un umbral predeterminado.
- Preocupaba que la sobrecarga del depurador, que podía sumar varios milisegundos, pudiese disminuir su valor para los clientes.
El equipo implementó una versión muy mínima de la característica que funcionaba en condiciones específicas. Luego, se creó una aplicación con problemas de lógica y rendimiento para que los usuarios pudiesen generar diagnósticos. Se pidió a los usuarios que identificaran la causa específica del problema. Si no lo conseguían, el equipo podía determinar por qué lo que oían y veían los usuarios no les permitía lograr su objetivo. El diseño se podía alterar y volver a probar la semana siguiente. Asimismo, durante este tiempo se entregó una versión de CTP externa instrumentada, donde la sugerencia de rendimiento estaba vinculada a la ventana de propiedades, lo que permitía a los usuarios cambiar fácilmente el umbral si lo consideraban necesario. El equipo concluyó lo siguiente:
- Las sugerencias de rendimiento no eran una distracción cuando los usuarios corregían problemas de lógica. De hecho, las sugerencias de rendimiento debían ajustarse con una animación sutil para ser más perceptibles cuando los usuarios trataban con problemas de rendimiento.
- Algunos cambios de expresión simples, como agregar la palabra "transcurrido", disipaban cualquier confusión que los usuarios pudiesen tener sobre la interpretación de los datos de tiempo.
- Los umbrales solo confundían a los usuarios cuando no se mostraban de manera coherente y no se podía identificar un valor simple que funcionara en la mayoría de las circunstancias. Algunos usuarios comentaban que, al conocer mejor su código, podían emitir el mejor juicio sobre los tiempos de rendimiento razonables.
- Los usuarios reconocían que los valores no serían exactos debido a la sobrecarga del depurador, pero afirmaban repetidamente que eran aceptables, ya que pretendían observar las diferencias a grandes rasgos.
En general, durante la varias semanas que duraron las iteraciones, el equipo obtuvo resultados positivos coherentes al encargar a los usuarios la identificación del origen de sus problemas de rendimiento. Sin pedirlo, los usuarios proporcionaron comentarios entusiastas como "fantástico" y "¡es sorprendente!".
Tomar notas
Al tomar notas, el equipo aprendió a evitar sacar conclusiones hasta el fin de la sesión cuando tenía tiempo para reunirse y hablar de lo ocurrido. Lo más útil era tomar algunas notas en tiempo real, e intentar escribir textualmente todo lo que los usuarios decían y lo que hacían. La gramática y la ortografía no eran importantes. Estas notas se convirtieron en la referencia del equipo al ponerse al día sobre lo ocurrido y permitían extraer información de los patrones observados durante varias semanas.
Microsoft OneNote se convirtió en una herramienta muy práctica para realizar el seguimiento de lo que el equipo planeaba probar, tomar notas y redactar borradores de resumen. Siempre había un usuario encargado de tomar notas que capturaba aquello que oía y veía. Esto proporcionaba a los demás miembros del equipo tranquilidad para centrarse completamente en el usuario. Para aquellos que no podían asistir, las sesiones en directo se compartían con el equipo a través de Skype; todos los miembros del equipo estaban invitados a ver y aprender. Asimismo, las sesiones se grababan para los miembros del equipo que no podían atenderlas y querían verlas más tarde. Las grabaciones en vídeo también permitían al equipo revisar las áreas que requerían atención adicional. En la discusión del equipo sobre los resultados semanales se informaba de lo que se haría la semana siguiente. No era necesario escribir un informe formal, ya que ralentizaría todo el proceso.
Resumen
El diseño y el desarrollo de sugerencias de rendimiento solo era una parte de lo que se hacía en los experimentos semanales. Se exploraban muchas ideas, con hasta cuatro experimentos semanales por usuario. El rediseño de la configuración de punto de interrupción es otro ejemplo de los experimentos que se realizaban cada semana para iterar con la finalidad de ofrecer una experiencia más útil y fácil de usar. Al aplicar Lean UX, el equipo podía mitigar el riesgo, al mismo tiempo que buscaba la inspiración de lo que oía y veía durante los experimentos. Estos experimentos eliminaron las conjeturas de la ecuación al diseñar las características. Las ideas procedían de muchos orígenes y recibían la inspiración de la observación del trabajo natural de los desarrolladores.
Si los usuarios no podían ver el valor de una idea, el bajo coste de creación de un boceto permitía comenzar desde cero fácilmente. Asimismo, los fallos desencadenaban nuevas ideas. Espero que los ejemplos y las sugerencias de Lean UX le inspiren a probarlo. La serie de libros "Lean" a la que se hace referencia en este artículo le servirá de guía y marco para adoptar este enfoque.
Participación en el programa
El equipo de investigación de experiencias de usuario de Microsoft busca todo tipo de desarrolladores para que proporcionen comentarios directos, así como para participar en este experimento continuo. Para registrarse, incluya algunos datos sobre sus conocimientos técnicos y la mejor manera de contactar con usted en aka.ms/VSUxResearch.
Quiero dar las gracias especialmente a todo el equipo implicado de una manera u otra en este proyecto. Solo puede describir los viernes intensivos como "abarrotados", con el equipo totalmente dedicado a ver, aprender y pensar en cómo entregar una incorporación meditada y resuelta a Visual Studio. Gracias en especial a Dan Taylor, que tuvo que liderar el equipo de desarrollo y que se enfrentó a los desafíos tecnológicos con aplomo. Andrew Hall mantuvo al equipo avanzando con sus profundos conocimientos técnicos y su enfoque pragmático. Frank Wu mantuvo vivo el flujo de ideas y tuvo una capacidad asombrosa para resumir una idea y buscar la manera de simplificarla.
Karl Melderes un investigador sénior de experiencias de usuario que ha aplicado incesantemente sus conocimientos y su experiencia a la investigación de experiencias de usuario, la informática, las UI y los factores humanos para diseñar experiencias de usuario. Desde hace más de 15 años trabaja para mejorar la experiencia de desarrollo en Visual Studio para una amplia variedad de clientes.
Gracias a los siguientes expertos técnicos de Microsoft por revisar este artículo: Andrew Hall, Dan Taylor y Frank Wu
Andrew Hall es administrador de programas sénior del equipo del depurador de Visual Studio. Tras graduarse en la universidad, escribió aplicaciones de línea de negocio antes de volver a estudiar este Máster en informática. Tras completar el Máster, se unió al equipo de herramientas de diagnóstico en Visual Studio. Mientras estuvo en Microsoft, trabajó en el depurador, el generador de perfiles y las herramientas de análisis de código de Visual Studio.
Dan Taylor es un administrador de programas del equipo de diagnóstico de Visual Studio y lleva trabajando en las herramientas de generación de perfiles y diagnóstico los últimos dos años. Antes de unirse al equipo de diagnóstico de Visual Studio, Taylor era administrador de programas del equipo de .NET Framework y contribuyó en numerosas mejoras de rendimiento para .NET Framework y CLR.
Frank Wu es diseñador de experiencias de usuario sénior que se centra actualmente en el diseño y la entrega de la mejor experiencia de edición y diagnóstico para todos los desarrolladores. Ha trabajado en software de seguridad, productos de Windows Server y herramientas de desarrollo durante los últimos 10 años después de obtener su Máster en HCI (interacción persona-máquina).