Niveles del sistema de diseño

Tiempo para madurar sistemas para soportar niveles de trabajo

Nuestro sistema de diseño, la única fuente de verdad. Singular, central, perfecto. El único lugar donde encontrarás todas las respuestas. ¿Los sistemas están destinados a tener un conjunto de las mejores cosas? No estoy convencido.

¿Por qué limitar los sistemas de diseño a solo cosas de la más alta calidad, relevantes para todos? ¿Hay espacio entre el núcleo de un sistema de diseño y los adoptantes para características menos perfectas para vivir? ¿Un lugar para compartir ideas de trabajo, realizar experimentos y estabilizar la calidad con el tiempo?

Propongo que los sistemas de diseño ofrecen una oportunidad para una taxonomía de niveles flexibles por debajo de un núcleo de la más alta calidad. Usando niveles, los sistemas pueden mejorar gradualmente las capacidades y la calidad de conjuntos de características significativas y promover ideas de un equipo o grupo hacia arriba a través de una arquitectura que todos comparten.

Un sistema puede soportar niveles

Las ideas brotan. Pueden comenzar con una idea en la mente de una sola persona. Esa idea es útil para un colaborador cercano. Otros se dan cuenta gradualmente de que comparten la necesidad. Finalmente, una idea puede, o no, ser relevante para todos. Podemos diseñar sistemas de diseño para reflejar dichos niveles.

Las arquitecturas comienzan, pero no necesitan detenerse, con dos niveles de un Sistema y está adoptando Productos. Una jerarquía de dos niveles es simple y fácil de entender.

Sin embargo, no todos los componentes y otras características son igualmente valiosos, endurecidos al mismo nivel de calidad o relevantes para tantas personas. Cuanto más alto sea el nivel, más ampliamente se comparte algo.

Para llevar: Anticípese que a medida que un sistema crece, puede beneficiarse de niveles adicionales para crear y compartir activos de diseño, código y documentación. Los niveles inferiores pueden ser espacios para funciones que no necesitan pertenecer al núcleo de un sistema visible para todos.

En la cima, un "núcleo" relevante para todos

Una vez que un sistema expone características de diferente calidad y relevancia, un núcleo deberá separarse como la más alta calidad y más relevante para todos.

En este punto, el núcleo de un sistema de diseño es predecible: el color, la tipografía, la iconografía y el espacio de un estilo visual aplicado a componentes como encabezados, botones, iconos, casillas de verificación, entradas y otros que obviamente todos necesitan. Hasta que tenga el núcleo correcto, no puede crear las cosas sofisticadas con confianza.

El núcleo es administrado y documentado centralmente por un grupo principal o equipo (s) designado (s) del sistema de diseño. Las comunidades de diseño e ingeniería tienen una gran influencia, pero también necesitan un equipo para señalar que sea responsable y responsable del éxito sostenido de un núcleo.

Para llevar: una vez que los niveles adicionales del sistema comienzan a emerger, designe un nivel "central" útil para todos los adoptantes y mantenido por un grupo central identificable. Llámelo como quiera: núcleo, base, base, lo que sea, para denotar claramente estas características más esenciales en la parte superior.

Comience con niveles para las unidades de negocio DENTRO ...

Los conjuntos de características se forman naturalmente dentro de los límites de la organización, como los grupos A, B, C y D que se muestran a continuación.

Subsistemas de nivel 2, que admiten diferentes líneas de negocio (A, B, C, D)

Mis observaciones a través de los sistemas de diseño sugieren que esto ya ocurre, pero de una manera ad hoc no gobernada por un equipo del sistema. Un equipo del sistema ofreció un kit básico de activos de Sketch y código de componente. En la naturaleza, los diseñadores de plataformas en los grupos A y B hicieron distintas extensiones del kit de bocetos, y un ingeniero había creado un "C Kit" de código de componente para su grupo. En tales casos, un programa del sistema podría modelar y proporcionar herramientas para tales extensiones de diseño y código.

... y también potenciar niveles a través de las unidades

Un sistema no necesita limitar un conjunto de características a los límites de la organización. Los niveles también pueden permitir que una comunidad comparta más allá de los límites. Recordaré a los equipos del sistema que su visibilidad en los productos no solo es una fortaleza, sino una responsabilidad. Detectar oportunidades y desencadenar conexiones es parte del trabajo, incluso si está más allá de lo que está en el núcleo de su sistema.

Considere los múltiples puntos de contacto de un ecosistema que integran un editor de texto enriquecido. No es solo una ventana del editor con párrafos, encabezados, listas y otro contenido. Hay barras de herramientas para formatear. Diálogos para cargar. La pantalla completa alterna para componer de forma inmersiva. Los editores no son baratos. A medida que un equipo del Grupo A lo toma, el grupo B se entera de ello y se forma una inversión compartida.

En el mismo ecosistema, pueden surgir otras inversiones compartidas, como experimentos con componentes para navegación, redes sociales y otras características por debajo del núcleo.

Para llevar: Sea un emparejador que conecte los esfuerzos entre los equipos. Ofrezca herramientas (andamios de repositorios y componentes, plantillas de croquis, rellenos de documentos en blanco) para iniciar conversaciones para que su primera cita se convierta en una relación fructífera.

Ampliar el uso de herramientas del sistema para trabajo escalonado

Entonces, ¿cómo rodaría niveles dentro de una organización? Un enfoque sería pilotear una primera fase para algunos conjuntos entre equipos: editor, navegación, social. Esto le daría la oportunidad de probar los permisos de acceso, la incorporación, el flujo de trabajo e incluso la posible promoción. A medida que esos pilotos tienen éxito, profundiza las herramientas en una segunda fase para admitir un uso más autónomo y extenso en un tercer nivel dentro de los equipos.

Un sistema que soporta aproximadamente 25 equipos instauró deliberadamente su arquitectura core-ui en un repositorio hermano de ventas-ui dependiente de los componentes y el estilo de core-ui. El catálogo de ventas-interfaz de usuario se expandió rápidamente en relación con el núcleo de evolución más lenta. Los controles estaban sueltos. Se cumplieron los plazos de entrega. Algunos vieron un desastre.

Ejemplo: organización de ventas que construye una biblioteca de componentes extendida

Sin embargo, el equipo del sistema vio la oportunidad. Había candidatos claros para promocionar desde ventas-ui a core-ui. Las herramientas que mejoran la calidad (linting, pruebas de regresión visual) se afianzaron en un grupo previamente marcado. Por encima de todo, los equipos de ventas integraron funciones core-ui en todo lo que hicieron sin pensarlo dos veces. Sin darse cuenta, ahora eran un segundo nivel de ese sistema de diseño.

Para llevar: las unidades de negocio y las líneas de productos están motivadas para trabajar rápido, cumplir objetivos y reutilizarse con sus escuadrones adyacentes. Las herramientas del sistema pueden desarrollar prácticas de diseño y desarrollo rápidas y sistemáticas para estimular a los grupos a avanzar, sin necesariamente complicar el núcleo del sistema.

Permisos modelo para visibilidad y control

Cuando un equipo de sistema de diseño admite un núcleo, está claro que serán responsables de hacer gran parte del diseño, la codificación y la documentación de ese núcleo. Como resultado, verán las contribuciones propuestas que cambian ese núcleo con mucho cuidado. Sin embargo, para cualquier nivel por debajo del núcleo, más personas necesitan más permisos abiertos para contribuir, ampliar y mantener activos.

Los equipos pueden usar aplicaciones como Abstract y Lingo App para distribuir los activos de la biblioteca Sketch para su sistema. Los kits proporcionan un botón central, una casilla de verificación y muchos otros componentes para toda la comunidad, aunque solo los miembros centrales del equipo (y socios clave) tienen acceso de edición.

Los kits adicionales (como Productos, Cuenta, Regalos y Pagar) podrían organizar un segundo nivel de subgrupos por experiencia. Estos subgrupos pueden ampliar componentes como tarjetas y formularios y también incluyen activos (como imágenes) y componentes (como Encabezado de cuenta) solo relevantes para su equipo. Si bien cada kit es visible para toda la comunidad de diseño, los privilegios de edición de cada kit están limitados a los diseñadores de esa unidad de negocio más el equipo central.

Para llevar: Modele los permisos para obtener la máxima visibilidad y minimizar el riesgo. Mientras más diseñadores y desarrolladores puedan ver el trabajo realizado en otros grupos, pueden formar conexiones, reducir la redundancia y unirse a un experimento.

Conservar el espacio de nombres centralmente

Una vez que un sistema fomenta las contribuciones de diversos grupos, puede convertirse en el salvaje oeste salvaje. Debes estar atento al premio: una biblioteca que comparte una arquitectura sin conflictos ni colisiones. Nadie necesita el botón de casilla de verificación, el botón de acción y la casilla con el botón de marca de verificación en él.

Eso requiere gobernar el espacio de nombres para garantizar que las nuevas características:

  • no se superponga con otras capacidades de funciones
  • no colisionará con otros nombres de características como se usa o promociona
  • minimiza los cambios de nombre para que los primeros usuarios no tengan que refactorizar más tarde

Nombrar es difícil. Todos entendemos eso. Pero renombrar más tarde realmente puede ensuciar los trabajos. Un sistema establece un espacio compartido que requiere un vocabulario entre desarrolladores y diseñadores. Por lo tanto, a medida que un sistema difunde las características entre los conjuntos, debe normalizar el nombre de cada elemento y cómo se agrupa.

Para llevar: seleccione cuidadosamente los nombres de conjuntos y características, especialmente los componentes. Sea claro sobre quién selecciona los nombres y revisa los nombres propuestos a medida que surgen. Esto incluso puede ser una persona específica o un grupo pequeño que tiene mucho talento y / o pasión por el tema.

Exponer niveles en la documentación

Justo cuando los equipos comienzan a crear conjuntos de características distintas, otros querrán usar los conjuntos de características que les interesan. Tampoco querrán ver los conjuntos de características que no les interesan. Esto afecta cómo se presentan las características en la documentación y las herramientas, como:

  • Clasificación de la navegación del sitio de documentación, el estado del catálogo y las páginas de detalles
  • Código de empaque y elementos de diseño, como símbolos de croquis
  • Priorizar conjuntos centrales y ampliamente relevantes más que aquellos menos relevantes
  • Personalización para que los usuarios puedan configurar lo que hacen y no ven
  • Integrando documentación centralmente en una propiedad del sitio o - ¡jadeo! - considerando múltiples sitios de documentación?

Para llevar: Agregar conjuntos más allá de un núcleo es un desafío de arquitectura de información para herramientas y documentación. Obliga a cuestiones de clasificación, organización y prioridad. Visualice un estado objetivo y luego cree herramientas hacia él de forma incremental, una característica a la vez.

Cuanto mayor sea el nivel, mayor será la calidad

Las características de un núcleo deben ser de la más alta calidad. A medida que emergen los niveles, la calidad por debajo del núcleo variará. Los paquetes de código Atlaskit de Atlassian sugieren un segundo nivel de grupos de características tanto para unidades de negocios (bitbucket) como para características entre grupos (editor, inicio, búsqueda y navegación), donde la calidad de algunos puede ser inferior a la que viene con el núcleo. La documentación del sitio de IBM Carbon desmiente dos niveles: un núcleo implícito y un segundo nivel "experimental":

“Se presentan componentes experimentales, diseños y otros recursos para pruebas y comentarios. No están destinados para uso de producción. ”- IBM Carbon

La calidad de la característica debería mejorar cuanto mayor sea el ascenso de una característica. Como resultado, un sistema debe aclarar a los fabricantes qué tan bien se debe hacer cada característica, y a los usuarios qué tan bien se ha hecho cada característica. Depende de un sistema con dos o más niveles diferenciar y comunicar claramente la calidad en cada nivel.

Criterios de calidad de características por nivel

Un modelo refuerza el control de calidad en función de cuán extendida se utilizará la función en todas las unidades de negocio:

  • Las funciones de nivel "Dentro del grupo" deben pasar las comprobaciones del navegador y la alineación de código, abordar los desafíos de accesibilidad relevantes para quienes lo hacen y tener un estilo coherente con el lenguaje de diseño central.
  • Las características de nivel "en todos los grupos" también deben ser receptivas, utilizar la metodología BEM CSS, realizar una versión semántica, registrar cambios, encapsular el estilo que depende de los tokens de diseño, la unidad de configuración y las pruebas de regresión visual, y contar con la aprobación de las comunidades completas de diseño y / o desarrollo.
  • Las características principales del nivel básico también deben pasar una revisión completa de accesibilidad, habilitar el dimensionamiento (S, M y L), trabajar en fondos (blanco, claro, oscuro, negro y de marca), y habilitar características personalizadas de temática, análisis e internacionalización como De derecha a izquierda.

¿Funciona un sistema hoy y apenas cumple con la calidad de nivel "Dentro del grupo"? No te estoy juzgando. Sus adoptantes podrían ser, sin embargo. Así que considere qué calidad se necesita y trace un camino para llegar allí.

Para llevar: Identifique criterios claros y alcanzables para colocar características. Para aquellos que corren rápido y suelto, establezcan expectativas mínimas para no frenarlos. A medida que aumente el uso de una función (y aumente la confianza), aclare qué pasos están próximos a endurecer para la promoción. Para otros que echan un vistazo y están interesados ​​en funciones no básicas, asegúrese de saber en qué se están metiendo.

Usar niveles en conversaciones sobre contribuciones

Los niveles proporcionan un gancho para hablar sobre cómo las características promueven desde experimentos estrechos hasta un uso generalizado utilizando criterios claros. Esa característica tendrá que ir a algún lado, y los niveles proporcionan barreras de protección en conversaciones como:

  • Organicemos las funciones del editor como un conjunto ... (el "¿Qué?")
  • ... construido en el nivel 2 ... (el "¿Dónde?" Y "¿Qué tan bien?")
  • ... que necesitaremos 3 sprints (el "¿Cuánto cuesta?") ...
  • ... para servir a los grupos de productos A y C pero no B, D o E (el "¿Quién?").

¿Por qué? Debido a que los sistemas ofrecen una arquitectura para diseñar de manera más consistente, construir de manera más eficiente y lograr una mayor calidad. No hay razón para limitar ese valor de hacer las cosas bien solo al equipo del sistema.

Para llevar: Puede asignar oportunidades de "contribución" como promoción a través de los niveles de un sistema. Esos contribuyentes necesitan una arquitectura de sistema para construir y miembros del equipo del sistema para identificar oportunidades y guiar el proceso.

Los niveles tendrán éxito cuando una comunidad adopte un lenguaje y una arquitectura para compartir. Las herramientas se ampliarán para dar la bienvenida a más participantes, y la actividad será evidente dentro y entre las unidades de negocios. Estaremos observando