Medición del impacto de un sistema de diseño

Hace unos días estaba escribiendo mi revisión semestral y estaba pensando en cómo podría incluir algunas métricas significativas sobre el éxito de nuestro sistema de diseño en Badoo.

Es innegable que en los últimos seis meses Cosmos, el nombre que le dimos, ha ganado mucha tracción: todos están mencionando Cosmos, todos están comenzando a integrarse o adoptar Cosmos, incluso hay bromas sobre eso si tienes un problema , cualquier problema, solo abra un ticket para Cosmos y se resolverá.

Pero esto no es una métrica. Es realmente difícil medir la felicidad de las personas, o el impacto en la forma en que las personas trabajan (y piensan) en términos de IU, o la eficiencia y la velocidad de los equipos para entregar actualizaciones y nuevas características al producto, y más en general el efecto de un cambio en un sistema complejo como una gran empresa.

Sé que este es un problema muy común en el mundo de los sistemas de diseño, y solo conozco algunos ejemplos de personas que pudieron recopilar datos (consulte las referencias al final de la página).

Personalmente, tiendo a desconfiar de la idea de que todo necesita ser medido o no existe, especialmente cuando las cosas involucran seres humanos:

En general, usar solo métricas para tomar decisiones sin usar nuestro cerebro, nuestro corazón y, a veces, incluso nuestro intestino, puede ser un arma de doble filo.

Pero entiendo totalmente el punto de vista de alguien que pregunta números sobre los beneficios y resultados de un sistema de diseño. El año pasado, cuando me pidieron que proporcionara algunas métricas, tuve que encontrar una forma de número, que era algún tipo de "cobertura de IU" de la biblioteca de patrones. Esencialmente, hice un inventario de todos los elementos de la interfaz de usuario que componían la aplicación, creé una lista de componentes y subcomponentes, y los puse en una hoja de cálculo. Para cada uno de ellos, asigné un estado ("hacer", "en progreso", "refinar", "hecho") y algún tipo de "métrica" ​​(de 1 a 5) en términos de esfuerzo requerido para producir ese componente (imagine algún tipo de puntos de historia para estimaciones).

En este punto, he definido una fórmula ponderada compleja, para comparar el total de los puntos requeridos para construir la IU completa, y los puntos de los mismos componentes ponderados en su estado (1 si se completó, 0.8 si se perfecciona, 0.6 si está en progreso , y 0 si aún queda por hacer). Luego he dividido la fórmula en dos, con formas ligeramente diferentes de ponderar los componentes y subcomponentes, y su estado. Estas dos fórmulas produjeron dos números, uno más "optimista" y uno más "pesimista".

Así es como se ve la hoja de cálculo final:

La hoja de cálculo que he creado para realizar un seguimiento del progreso en la componenteización de la interfaz de usuario para nuestro sistema de diseño. La lista de componentes obviamente es más larga que esta, es de alrededor de 240 líneas.

A diferencia de las métricas de cobertura de código que se basan en elementos objetivos, lo que tenemos aquí es una "medida" que se basa en la percepción de alguien (yo), en este caso la complejidad requerida para implementar un componente. Claramente una métrica subjetiva (y probablemente sesgada).

A pesar de ser una métrica tan sintética, en realidad se puede usar de una manera útil: para rastrear el progreso en el trabajo. La gente quiere ver el progreso, necesita ver que las cosas se mueven, y esto puede dar una indicación clara de la "tasa de cambio" en lo medido subyacente (en este caso, cuántos componentes se agregan a la biblioteca y cuántos todavía se quedan fuera).

Cuando trazamos los valores de la cobertura de la IU a lo largo del tiempo, esto es lo que obtenemos:

Puede ver / leer claramente alguna información significativa aquí:

  • En primer lugar, la tendencia: hay un crecimiento constante y sensible en el número de componentes contenidos en la biblioteca, en menos de un año pasamos de ~ 50% a ~ 80% de cobertura
  • las dos fórmulas son convergentes, lo que significa que hay menos incertidumbre
  • estamos alcanzando una buena cobertura, alrededor del 80%, lo que, de acuerdo con el principio de Pareto (y la sabiduría de Nathan Curtis), significa que nos queda un 20% de trabajo que, potencialmente, puede tener un ROI mucho más bajo.
A medida que crece la biblioteca de un sistema de diseño, el costo promedio de un componente de la interfaz de usuario aumenta mientras que el valor para la comunidad disminuye. El umbral cuando el costo excede el beneficio varía según la organización. - Nathan Curtis

Después de este primer intento, he tratado de proponer otras ideas para las métricas, pero todas fueron siempre cualitativas, nunca cuantitativas.

Por ejemplo, he enviado una encuesta interna para evaluar las opiniones y el impacto de Cosmos en diferentes equipos (diseñadores, desarrolladores de iOS / Android, desarrolladores web, gerentes de producto, QA, etc.). Los resultados fueron excelentes, más allá de las expectativas, pero aún así ... los pensamientos de las personas. Sin métricas objetivas, sin números.

Esta fue la pregunta: “Si compara cómo trabajaba hace uno o dos años y cómo trabaja hoy, ¿cree que Cosmos ha tenido algún impacto en su trabajo diario? y en el trabajo de las personas con las que trabajas? en caso afirmativo, ¿cuál ha sido el impacto? ") e incluso si tuviera respuestas como" menos tiempo perdido en las discusiones sobre el cambio de píxeles y más tiempo para ser productivo "o" Etapa de diseño más rápida: todo ahora es como LEGO ", estas no podrían ser convertido en números. No había nada allí que pudiera medirse como un efecto directo y exclusivo del sistema de diseño. Si fuera gerente, me habría preguntado: “¿cuánto más rápido? me puedes dar un numero ¿me puede mostrar una correlación entre el sistema de diseño y la entrega de características del producto? ”, y no tendría una respuesta.

Entonces, desde entonces, esta ha sido mi métrica principal (y única).

Ahora, volviendo al comienzo de esta historia. Como dije, estaba escribiendo mi revisión bianual y pensando en otras formas posibles de mostrar el impacto del sistema de diseño en nuestra empresa, cuando mi cerebro hizo una conexión extraña con una conversación que tuve hace un par de días. uno de mis colegas, acerca de cuántas opciones (y generalmente desconocidas) tiene git-log.

No sé por qué, pero comencé a pensar: ¿qué pasa si puedo contar la cantidad de cambios en la base de código de nuestra aplicación, limitando solo a los cambios que están relacionados con la interfaz de usuario, por lo que los cambios en los archivos CSS y de alguna manera representan ellos en una escala de tiempo? Que veria ¿Sería posible observar algún tipo de efecto (y posiblemente correlación) con un gráfico similar para la base de código de la biblioteca UI?

Mi intuición era que claramente había una cantidad reducida de trabajo en el equipo para los ingenieros de la interfaz de usuario (yo soy uno de ellos), y que esto fue causado por el hecho de que no estábamos escribiendo continuamente CSS nuevo en cada nueva característica, pero pudimos reutilizar y simplemente combinar ("como Lego") los componentes de interfaz de usuario existentes proporcionados por Cosmos. Y que esto también fue causado por el hecho de que también las maquetas proporcionadas por los diseñadores eran más consistentes y seguían un conjunto de patrones predefinidos, por lo que construir interfaces de usuario para nosotros se había vuelto cada vez más simple y directo.

¿Pero cómo probarlo?

No pude evitar pensar en esto, así que inmediatamente comencé a jugar alrededor de la línea de comando, tratando de obtener algo que pudiera usar para extraer los datos. Después de algunas pruebas rápidas, terminé simplemente ejecutando este comando en el repositorio de la aplicación:

git log --stat --reverse --date = short - 'src / css / *. less'> ~ / git-log-stats / data-raw / logs_less.txt

Este comando recorre todo el historial de git y extrae toda la información de confirmación que involucra cambios en los archivos MENOS (nos mudamos de MENOS a Sass hace un par de años, así que tuve que hacer lo mismo para los archivos Sass y fusionar los registros )

Ejecuté el comando tanto para la base de código de la aplicación como para la base de código de Cosmos, y guardé el resultado resultante en archivos de texto separados.

Si tomamos una muestra de esta salida, veríamos algo como esto:

cometer 13f68a70e9fd483f22b527ea63f288e8f4ab4f33
Autor: Nombre Apellido 
Fecha: 2014-12-05
    [MW - ****]: restableció el botón de borrar
    src / css / v2 / elements / forms.less | 12 ++++++++++++
    src / css / v2 / modules / header.less | 2 + -
    2 archivos modificados, 13 inserciones (+), 1 eliminación (-)
commit 303c5cicsoftc70c1932d0fa517cb2ca60783c6fce7
Fusionar: e16b0d0548 c36113c1ca
Autor: Nombre Apellido 
Fecha: 2014-12-10
    [MW - ****]: Combina la rama de seguimiento remoto 'origin / master' en MW - **** _ restore_clear_button
...

La información que estaba buscando estaba allí: la fecha de las confirmaciones, el número de archivos cambiados y, especialmente, el número de líneas de código agregadas y / o eliminadas con ese cambio (solo para archivos MENOS / Sass).

Luego busqué un analizador git-log, encontré uno simple en Python, lo porté a JavaScript, y lo que terminé con fue un analizador / procesador basado en nodos (puede ver el código aquí en este resumen) que toma el salida de estos comandos como archivos de texto y genera enormes archivos JSON que contienen una lista de todos los cambios agregados por día.

Así es como se vería una sección de un archivo JSON:

    {
        "date": "2014-12-05",
        "archivos": 2,
        "inserciones": 13,
        "eliminaciones": 1
    },
    {
        "fecha": "06/12/2014",
        "archivos": 10,
        "inserciones": 120,
        "eliminaciones": 60
    }, ...

Finalmente, tomé los datos generados por el script y los usé para crear una visualización de estos números usando la biblioteca D3.js.

Lo primero que me vino a la mente fue dibujar "burbujas" a lo largo de una línea de tiempo, donde el radio de la burbuja era el valor para trazar.

Tan pronto como generé el gráfico, mi mente quedó impresionada. ¡Todo lo que imaginaba estaba allí! Al observar el gráfico de la base de código de la aplicación, hubo claramente un antes y un después, una serie de burbujas medianas / grandes seguidas de una serie de burbujas pequeñas; y esto era consistente con el segundo gráfico, para la biblioteca de componentes del sistema de diseño.

Representación visual de los cambios en dos bases de código, en la parte superior de la aplicación y en la parte inferior de la biblioteca de componentes.

¡Había tanto para leer en esta tabla!

En comparación, los cambios en la base de código de la aplicación principal y los cambios en la base de código de la biblioteca de componentes mostraron una correlación clara y evidente: desde la introducción del sistema de diseño y la adopción de los componentes de la interfaz de usuario de la biblioteca en la aplicación, la cantidad de los cambios se han reducido significativamente. Lo que significa mucho menos trabajo para los ingenieros de UI (o, diría, un mejor trabajo, con más tiempo para dedicar a la calidad de la aplicación, que ha mejorado constantemente en los últimos años).

La reducción de trabajo en la aplicación principal no fue contrarrestada por una cantidad igual de trabajo en la biblioteca de componentes (de lo contrario, ¡habría sido solo un juego de suma cero!). Si observa, en promedio, el tamaño de las burbujas en Cosmos es mucho más pequeño que el tamaño de las burbujas en la aplicación. Este es un efecto claro del hecho de que los componentes se "agregan una vez y se usan para siempre". Si observa el cuadro anotado a continuación, verá que estas burbujas coinciden con la implementación de componentes específicos (son solo componentes nuevos agregados a la biblioteca) y el costo de su mantenimiento es insignificante (pequeñas burbujas).

Todavía había una cosa que me intrigaba: en realidad, esta representación no era 100% correcta. Las medidas se trazan como radio, pero las percibimos como áreas ("burbujas"), por lo que el hecho de que no sean lineales sino cuadráticas puede inducir algún tipo de sesgo o sobreestimación del efecto.

Así que decidí probar otra forma de visualización: usar solo rectángulos simples, con la altura del rectángulo directamente proporcional al valor trazado y el ancho de un tamaño fijo. De esta forma, las medidas fueron lineales y proporcionales.

Los resultados ahora eran aún más claros:

Una representación visual similar de los cambios en dos bases de código, esta vez usando rectángulos en lugar de círculos.

Lo que esta representación hizo más visible fueron diferentes patrones en la forma en que los cambios se aplicaron a la base de código principal:

  • En los primeros meses de 2016 hubo una fase de muchos y muy frecuentes cambios de tamaño mediano (cierto: esto corresponde a una fase de evolución y establecimiento de la base de código CSS: introdujimos una guía de estilo y comenzamos a componer componentes cada vez más UI);
  • entre finales de 2016 y 2017, un período de grandes cambios masivos (cierto: fue cuando trabajamos en un rediseño completo de toda la aplicación, un proyecto llamado Re-Think);
  • luego, en 2017, hubo tres grandes picos, correspondientes a tres grandes refactorizaciones del código (de hecho, pasamos de LESS a Sass, introdujimos stylelint y aplicamos el orden de las propiedades CSS);
  • en la última parte de 2017 y para todo 2018, solo cambios relativamente pequeños y aislados, con algunos grupos de cambios más evidentes aquí y allá (introdujimos una nueva característica compleja llamada Livestream en nuestra aplicación, eliminamos por completo todos los íconos SVG en la base de código).

Simplemente cambiando el tipo de visualización, de repente descubrió una medida secundaria que de alguna manera estaba oculta en el ruido de los círculos: no solo la cantidad de cambio, sino también la frecuencia de cambio era una métrica significativa. Y esto ahora era claramente visible: cuantos más rectángulos se dibujan uno cerca del otro, lo que significa que cuanto más "densos", más frecuentes son los cambios en el tiempo, más opaca es el área pintada en ese espacio de tiempo (tenga en cuenta que el La opacidad del rectángulo único es un valor fijo).

Este efecto es aún más evidente cuando comprimimos la escala horizontal:

La diferencia entre antes / después de la introducción de un sistema de diseño se hace aún más evidente.

En este caso, las áreas de la izquierda se vuelven más opacas, mientras que las áreas de la derecha permanecen relativamente transparentes. Esto significa que a la izquierda tenemos muchos cambios medios / grandes frecuentes, a la derecha pequeños cambios poco frecuentes.

Que era exactamente lo que estaba experimentando en mi trabajo diario. Al verlo allí, a la vista y de una manera tan incontrovertible, fue ... ¡guau!

¿Cuál es el siguiente paso? Probablemente preguntarás. ¿Va a convertir esto en una métrica "adecuada", en un número que pueda usar y monitorear con el tiempo? Bueno, mi respuesta es: no. Por dos razones principales.

Primero, porque eso sería como medir el "número de líneas comprometidas por día" o el "número de tickets cerrados por mes", y esta es una muy mala manera de medir algo (en general, la productividad). Cuando los humanos están involucrados, no todo se puede medir.

Segundo, porque no quiero dejar pasar la idea de que "un sistema de diseño hace que las personas trabajen menos". Si estás leyendo esto en los cuadros anteriores, déjame decirte que estás completamente equivocado. La razón para introducir un sistema de diseño en una empresa no es porque las personas puedan trabajar menos, sino porque las personas pueden trabajar mejor. Quiero que la gente se concentre en las cosas importantes y reduzca la cantidad de trabajo repetitivo que realizan.

Sé por experiencia lo difícil que es medir el impacto de un sistema de diseño en una empresa, una empresa, un equipo. Es por eso que he compartido mi pequeño experimento: con la esperanza de que pueda ser útil para otra persona, que pueda inspirar a otra persona a encontrar sus propias "métricas significativas" y compartirlas a su vez.

Necesitamos más y más ejemplos de posibles métricas para un sistema de diseño, y ejemplos reales del impacto positivo que puede tener un sistema de diseño. Sabemos que está allí, lo vemos día a día, con nuestros propios ojos: solo necesitamos los números (o las tablas de colores, en este caso) para demostrarlo.

A continuación se muestra una versión anotada de los gráficos, con información adicional sobre lo que significan esos picos. Sé que muchas de las cosas que ves allí significarán poco o nada para ti, pero confía en mí, tienen mucho sentido para las personas involucradas en estas bases de código :)

Recursos

Algunos enlaces interesantes sobre la introducción de métricas en sistemas de diseño:

  • Nathan Curtis sobre la medición del éxito del sistema de diseño utilizando OKR para establecer objetivos y seguir el progreso
  • Jeroen Ransijn sobre la medición de la adopción de su sistema de diseño en Segment (ver El mapa de árbol de uso de componentes)
  • Varya Stepanova sobre la recopilación automática de datos cuantitativos sobre el uso de componentes en Elisa
  • Daniel O'Connor sobre el seguimiento de métricas cuantitativas clave y comentarios cualitativos a lo largo del tiempo
  • Diana Mounter sobre cómo miden el éxito de su sistema de diseño en GitHub
  • Joshua Sortino y Jina Anne comparten algunos consejos sobre cómo medir el impacto de un sistema de diseño
  • Bryn Ray ha hecho un análisis interesante y detallado de mucho es un sistema de diseño que vale la pena
  • Lily Dart, en una presentación sobre su sistema de diseño Constellation en Lloyds Banking Group, dijo que el sistema de diseño les ahorró a sus equipos £ 190,000 por proyecto (!), Y que en general ya ha ahorrado al grupo más de £ 3.5M. ¡Esa es una métrica realmente impresionante!
  • Dan Mall de SuperFriendly en su artículo sobre "Sistemas de diseño de ventas" menciona el caso de su cliente, la iglesia adventista, que decidió "medir lo que hacen" y definir los OKR específicos (ver # 1, # 2 y # 3).
  • Rauno Freiberg de Veriff ha escrito una publicación sobre la medición del impacto de un sistema de diseño utilizando un tipo diferente de métrica (uso de componentes):
    https://www.veriff.com/veriff-times/measuring-impact-design-system
  • Anja Klüver recientemente dio una increíble charla en Londres Design Systems conf, sobre cómo defender un sistema de diseño con las partes interesadas y cómo dar cifras significativas sobre costos, ahorros y ROI de un sistema de diseño. Puedes verla hablar aquí: https://youtu.be/-TUHaJgWhZc?t=6053 (comienza a las 1:40:50). También puede ver algunas diapositivas y un pequeño hilo de Twitter aquí.

Si tiene más ejemplos o enlaces sobre este tema, compártalos en los comentarios de esta publicación y los agregaré a la lista.