Contenido del Articulo
Seguimiento automático de la adopción de tokens y componentes
Al principio del desarrollo del sistema de diseño Onfido, todos nuestros datos y métricas se recopilaron manualmente. Éramos un equipo fragmentado sin recursos dedicados, e hicimos lo mejor que pudimos dentro de esas limitaciones.
Los datos que recopilamos en esta etapa nos ayudaron a mantener el presupuesto y rediseñar nuestro sistema de diseño para que sea mejor y más flexible. Teníamos la columna vertebral de un gran sistema que incluía tokens de diseñador y unos cinco componentes de alta calidad que confiábamos en que se utilizarían ampliamente. si nuestros equipos de producto los aceptan.
Cada etapa de la madurez del sistema de diseño tendrá diferentes métricas que son más apropiadas para realizar un seguimiento de acuerdo con sus objetivos actuales. En este artículo, sólo me centraré en aceptación creciente.
Integración mínima viable
Comenzamos hablando con los tres equipos de productos que creemos que se beneficiarán más del sistema. El único obstáculo para la adopción para ellos era esfuerzos preliminares para integrar las bibliotecas requeridas en su producto. Una vez que se construyen estas bibliotecas, los tokens o componentes se pueden usar fácilmente en nuevos proyectos en el futuro, agregando valor inmediato. No necesitábamos portar ningún componente existente para hacer esto, y se podía hacer en un par de horas (incluida la capacitación, la resolución de problemas, la implementación y las pruebas). A este paso inicial lo hemos llamado mínima integración viable.
Una vez que se integraron las bibliotecas, pudimos planificar una serie de trabajos más detallados para migrar componentes o tokens individuales y distribuir este trabajo a lo largo del tiempo. También hizo que las pruebas fueran mucho más fáciles que si intentáramos cambiar todo a la vez.
Indicadores procesables
Dado que este enfoque distribuiría la migración en varios trimestres, necesitábamos métricas actuales confiables para ayudarnos a medir el progreso hacia nuestros objetivos.
Nos hemos esforzado por hacer que nuestras métricas sean lo más procesables posible.. La mayor parte de la acción será comunicar dónde es mejor gastar nuestros esfuerzos.
Para nosotros, las preguntas clave que queríamos responder eran:
- ¿Cómo sabemos si lo que creamos se usa ampliamente?
- ¿Cómo podemos enfocar nuestros esfuerzos para aumentar la adopción?
A partir de aquí, refinamos nuestro pensamiento haciendo preguntas más específicas que ayudan a responder las dos preguntas clave anteriores:
- ¿A qué distancia estamos de nuestro objetivo de adopción de tokens como porcentaje?
- ¿En qué productos podríamos centrarnos para obtener el mayor beneficio en general?
- ¿Qué componentes tienen baja tracción en todos los productos?
- ¿Qué alimentos tienen bajas tasas de aceptación de componentes?
- ¿Qué productos son buenos ejemplos de mejores prácticas que podemos usar como estudios de casos internos para aumentar la visibilidad e impulsar aún más la adopción?
Maquetas de datos
El esfuerzo de responder estas preguntas con datos recopilados manualmente fue demasiado alto teniendo en cuenta la frecuencia con la que esto tendría que suceder y los resultados habrían sido demasiado confusos, por lo que decidimos utilizar un enfoque más automatizado.
hemos comenzado datos y gráficos simulados en la hoja de google. Acabamos de recopilar todos los datos para empezar. Me acerqué a esto de la misma manera que me acerqué a cualquier proyecto de diseño exploratorio temprano y solo usé una herramienta que nos permitió discutir algo visual lo más rápido posible. En este caso, fue Hojas de cálculo de Google.
fichas
Para realizar un seguimiento de la adopción de tokens, nos enfocamos principalmente en los tokens de color porque son fundamentales para nuestras nuevas capacidades de tema y porque se asignan de manera clara y sencilla a nuestros diseños en Figma.
Decidimos rastrear Colores sin fichas (palabras clave RGB, hexadecimal, CSS), Fichas de tema semánticotanto como Tokens de paleta basey mostrar los datos de cada producto. Esto nos permitiría tener una idea aproximada del % de los colores de cada producto cubiertos por nuestros nuevos tokens y luego apuntar a los productos que nos darán el mayor impulso en nuestro lanzamiento global.
Discutimos si realmente podemos obtener datos razonables para valores que no sean tokens y decidimos que con algunas expresiones regulares específicas podríamos obtener algo suficientemente bueno.
Según el gráfico (falso) anterior, apuntaríamos primero al producto Dashboard, por ejemplo.
Componentes
Los componentes resultaron ser mucho más complejos. No teníamos una manera fácil de determinar qué componente no era del sistema con una expresión regular. El botón se puede implementar como <button>Enlace <a class="button"> o entrada <input type="submit"> o cualquier número de abstracciones de lenguaje o componentes con nombres personalizados que son visual o funcionalmente similares a los botones. Es posible si tiene una base de código más consistente en un lenguaje consistente, pero ese no fue el caso para nosotros.
Por este motivo, decidimos no intentaríamos rastrear porcentajes como lo hacemos con tokens. Esto nos llevó a una discusión sobre si hacer un seguimiento de la cantidad de instancias de cada componente en un producto, lo que nos llevó a otro agujero de conejo. Por ejemplo: digamos que tienes button un componente en el título de una aplicación y ese título aparece en 30 páginas o interfaces diferentes, ¿eso cuenta como 30 botones o un botón? Hemos discutido muchos escenarios diferentes como este.
Al final, decidimos que ninguno de los enfoques nos brindaría datos en los que pudiéramos confiar o que fueran lo suficientemente significativos, por lo que decidimos comenzar con una vista a nivel de producto:
Cuántos productos han adoptado un componente determinado al menos una vez en su base de código.?
Es muy fácil de medir y nos permitió asegurarnos de que los componentes que creamos se estaban utilizando.
El primer gráfico de datos falsos era exactamente lo que buscábamos, pero nos dimos cuenta de que también necesitábamos saber qué productos acepta cada componente. Los visualizamos como gráficos de barras con un segmento para cada producto. Dado que rastreamos estos datos, también podríamos dividirlos para ver qué productos usan muchos componentes y cuáles solo unos pocos (o ninguno).
Dado que teníamos muchos productos escritos en lenguajes de programación completamente diferentes, en ese momento no había una solución preparada que se ajustara a nuestras necesidades, por lo que creamos algo nosotros mismos.
Ya implementamos Looker en toda la empresa para todo tipo de métricas, por lo que lo elegimos como nuestra herramienta para crear y mostrar gráficos basados en los datos que recopilamos.
Nota. Existen otras herramientas de procesamiento de datos similares, como Mesapero si su empresa tiene equipos que ya realizan análisis y métricas, comuníquese con ellos y vea si puede usar su infraestructura.
Los ingenieros de nuestro equipo, Julius y André, diseñaron y construyeron un “code scraper” que se ejecutaba todas las noches en todo nuestro servidor GitLab. Utiliza la API de GitLab para buscar en todos los repositorios de nuestra empresa y filtra los archivos que pueden contener tokens, colores o componentes (como .css y .tsx) en cada repositorio. Luego usa una serie de expresiones regulares para buscar cadenas específicas de caracteres en esos archivos. Por ejemplo, podemos buscar tokens que comiencen con ods-color-o importar sentencias para componentes como import {ComponentName} from ‘@onfido/castor’.
Luego recopilamos y agrupamos los resultados en un formato que podemos manipular fácilmente y enviarlos al Looker.
A partir de estos datos sin procesar, construimos nuestros gráficos, que puede ver a continuación. Hemos establecido nuestro objetivo de adopción de tokens en un 80 % y tenemos al menos tres productos que usan un componente para considerar que ese componente es un éxito.
Como puede ver, nuestro panel de control de Looker es muy similar a nuestros diseños originales de datos falsos. Tener gráficos que rastrean tanto el número absoluto de tokens como el porcentaje nos ayuda a tener una mejor idea de cada producto.
También creamos una vista de “estudio de huérfanos”, que es una tabla que enumera todos los valores de color individuales que no son tokens (por ejemplo, #ffffff), el número de instancias de cada uno de ellos en un producto determinado y la lista de archivos en los que se encontraron. Esto nos permitió profundizar para encontrar las mayores oportunidades y ayudarnos a escribir tickets con los equipos.
Como cualquier parte de un sistema de diseño, este tablero tiene brechas, fallas y siempre estará en desarrollo.
La brecha más grande es el raspador solo mide fichas de colores en este momento. No hay nada más que tiempo/prioridad que nos impida aumentar el alcance para incluir diferentes tipos de tokens, solo queremos hacerlo con cuidado y consideración sin agregar demasiado ruido. Además, dado que nuestras herramientas de diseño no admiten explícitamente marcadores de tamaño/distancia, hay un poco menos de rigor en ese sentido, y espero mejorar el sistema general el próximo año.
Teniendo en cuenta la arquitectura del raspador, no puede rastrear fácilmente cómo estos números han mejorado con el tiempo. El analizador guarda la instantánea y sobrescribe la última para que no haya problemas con el almacenamiento de datos. Agregar algunas de las métricas de alto nivel que rastreamos a lo largo del tiempo es algo que podemos agregar en el futuro. En este punto, decidimos que el valor era relativamente bajo porque los datos históricos no eran tan procesables y podíamos llenar el vacío muy fácilmente con capturas de pantalla ocasionales. También nos estamos acercando a salir de la fase de implementación y ver cuáles serán nuestras próximas grandes métricas.
Uso de varios combinaciones de opciones otra gran brecha. Nos gustaría realizar un seguimiento de las opciones de una forma u otra, pero necesitamos comprender mejor qué es lo más importante y procesable aquí. Instintivamente, podría pensar que estas son las opciones o combinaciones más utilizadas, pero en realidad, menos usado puede ser más eficiente. Entonces podría descartar cosas que no se están utilizando, potencialmente. Se necesita más reflexión y discusión con el equipo.
Las métricas más útiles para su equipo dependerán de su etapa de madurez, los recursos disponibles, la organización y la arquitectura del sistema. Trabajen en ellos juntos como equipo y pasen algún tiempo discutiéndolos.
No necesitas tantas métricas como probablemente piensasasí que siéntase cómodo con las métricas “suficientemente buenas”, concéntrese en las prácticas y obtenga lo que necesita para contar historias convincentes para mantener o aumentar la inversión en su sistema.
Gracias al equipo de Castor en Onfido que trabajó en esto: Andre Rabello (quien ayudó con los aspectos técnicos de este artículo), Corey Hume, Julius Osokinas y Mark Opland.
Para otros recursos sobre la medición de la adopción y el impacto de un sistema de diseño, recomiendo los siguientes artículos:
