Por la gente, para la gente: mantener su sistema de diseño siempre verde

Esta publicación es la tercera de una serie sobre HubSpot Canvas, nuestro nuevo lenguaje de diseño. Lea el primero aquí y el segundo aquí.

Cada enero, millones de personas deciden que este es el año en que sus vidas serán diferentes. Leerás más libros. Pondrás más dinero en ahorros. Comerás menos Doritos Cool Ranch y pintas de Ben & Jerry's. Y lo harás en el gimnasio. Cada. Día.

Pero la mayoría de las veces, tan pronto como llega febrero, hay una pila de libros sin leer en tu mesita de noche. Sus ahorros rutinariamente van a financiar su hábito de Taco Tuesday. Y hay una fina capa de polvo de Dorito que cubre tu sofá.

¿Por qué? Porque las buenas intenciones no son suficientes. A menos que haga un cambio de estilo de vida, incluso la resolución mejor intencionada simplemente no se mantendrá.

Lo mismo es cierto con los sistemas de diseño. Cuando rediseña su producto, los sistemas que causaron el estancamiento de la guía de estilo de su producto (o llevaron a su equipo a crear 6 botones principales diferentes) probablemente todavía estén presentes. Y sin un verdadero cambio de estilo de vida, es probable que termine justo donde comenzó.

Es por eso que la parte más importante de su nuevo sistema de diseño no es su hermosa y nueva paleta de colores, o incluso las herramientas que implementa para hacer que el uso de su sistema de diseño sea sencillo: es la forma en que su equipo interactúa con el sistema de manera continua.

No queríamos que nuestro nuevo sistema de diseño, HubSpot Canvas, siguiera los pasos de nuestra (s) antigua (s) guía (s) de estilo, que terminaron obsoletas e ignoradas. Queríamos que fuera un ser vivo, cambiante y en crecimiento. Necesitábamos un cambio de estilo de vida. Y solo íbamos a llegar allí revisando nuestro proceso de diseño.

Por la gente: su sistema debe ser propiedad de todos

El proceso a veces tiene mala reputación. Y es cierto: el proceso por el proceso puede ser ineficiente en el mejor de los casos y frustrante en el peor.

Pero el proceso correcto elimina la fricción. Acelera la toma de decisiones, aclara los roles y las responsabilidades y pone a todos en la misma página. Al descubrir cómo gobernar HubSpot Canvas, nuestro lenguaje de diseño, queríamos crear un proceso que lograra todas estas cosas. Sabíamos que si nuestro nuevo proceso iba a tener éxito, tendría que ser ligero y ser copropietario de las personas que lo usaban todos los días.

No hay duda de que construir y mantener un sistema de diseño puede ser un trabajo de tiempo completo. Pero hemos descubierto que difundir ese trabajo en un grupo rotativo de diseñadores funciona mejor. Es lógico pensar que los diseñadores que trabajan en nuestro producto todos los días, que entienden a nuestros usuarios y que están capacitados en cómo priorizar el trabajo e iterar sobre las soluciones son los mejores pastores de este proceso.

Cada 6 meses, un grupo de cuatro diseñadores se integra y asume roles y responsabilidades específicos en el equipo de Canvas. Los beneficios son dobles: no solo mejorarán directamente el sistema mientras están en el equipo, sino que tendrán una comprensión profunda de cómo contribuir a él después de que termine su rotación. Nuestro objetivo es que todos los diseñadores de productos en HubSpot eventualmente realicen un recorrido de servicio en el equipo de Canvas.

Los diseñadores que trabajan en nuestro lenguaje de diseño lo hacen además de sus "trabajos diarios". Hemos encontrado que esto funciona bien, porque ahora que se han creado todas las piezas principales de Canvas, la tarea de mantener el lenguaje de diseño es mucho menor exigente.

Aún así, los diseñadores de este equipo deben:

  • Defiende el lenguaje de diseño de HubSpot Canvas
  • Conozca bien la documentación y las decisiones existentes hasta la fecha para que puedan responder fácilmente preguntas e identificar inconsistencias.
  • Continuar identificando formas de mejorar el proceso y la documentación.
  • Actualice semanalmente el Kit de interfaz de usuario de Sketch y envíe un correo electrónico que detalle las actualizaciones a los diseñadores y desarrolladores front-end.
  • Clasifique los problemas entrantes y facilite la discusión y las decisiones en nuestras reuniones de revisión semanales
  • Comuníquese de manera proactiva con diseñadores de todo el equipo para ayudar a documentar casos de uso, variantes y patrones
  • Trabaje con nuestro equipo de Frontend como servicio para responder preguntas y ayudar a garantizar que los componentes se cambien o construyan correctamente.

Cómo un proyecto de ley se convierte en ley

Mantener un sistema de diseño imperecedero requiere una estrecha colaboración entre diseñadores y desarrolladores. Entonces, para facilitar una colaboración efectiva, decidimos construir nuestro proceso donde las conversaciones y decisiones sobre nuestro sistema de diseño ya estaban sucediendo, en Github.

Esto convierte a Github en nuestra única fuente de verdad para Canvas. Entonces…

  • Si un ingeniero necesita saber si un componente ha sido aprobado por el equipo de diseño? Está en Github.
  • ¿Si un diseñador necesita saber si un componente ya se ha construido? Está en Github.
  • ¿Si el equipo necesita debatir si un componente debería existir? Lo has adivinado, lo hacemos en Github.

Paso 1: Necesitamos un nuevo componente o una edición a un componente existente.

Desde nuestra Biblioteca de UI, cualquiera puede enviar un problema de Github al equipo para su revisión. Estos problemas son cómo un diseñador hace rodar la pelota con el equipo de Canvas.

Solicitamos una serie de detalles en el número inicial de Github. Con el tiempo hemos aprendido (y nos hemos comunicado ampliamente) que las cosas se mueven más suavemente cuando el remitente ha considerado los detalles y los casos de uso de un componente a fondo. Este no es el lugar para ideas generales o mejoras futuras (esas conversaciones a menudo ocurren a través de Slack o fuera de línea entre diseñadores), es para un componente que está listo para ser revisado y construido.

Luego se agrega a nuestra cola:

Paso 2: El equipo de Canvas resuelve los problemas.

Este proceso ha evolucionado con el tiempo, pero nuestro objetivo sigue siendo el mismo. Para asegurarnos de que nada se escape, nos dimos cuenta de que cada problema necesita a alguien responsable de guiarlo a través de este proceso.

En lugar de diseñar un modelo sofisticado sobre cómo dividir o distribuir uniformemente el trabajo, terminamos con un sistema simple de selección de voluntarios cada semana. Nos decidimos por esto por un par de razones. Primero, algunas personas simplemente tienen más interés o experiencia en ciertos temas. Y en segundo lugar, las cargas de trabajo fuera de este equipo fluctúan: a veces ciertas personas en el equipo están ocupadas y otras no. De esta manera, el equipo puede reaccionar ante el trabajo de manera elástica, confiando mutuamente para recuperar la holgura. No es perfecto a veces necesitamos reasignar problemas o hacer pequeños cambios. Pero se ajusta a nuestro estilo general de trabajo en HubSpot, y todavía no nos ha fallado.

Paso 3: Los problemas pasan por una revisión.

A un alto nivel, el proceso de revisión refleja nuestro proceso de diseño general (pero a menor escala):

  1. Comprende el problema
  2. Determinar quién se ve afectado por el problema
  3. Chatea y colabora con equipos afectados
  4. Diseñe, modifique y perfeccione el diseño del componente
  5. Revisión con el equipo de Canvas

Nuestro objetivo es que este proceso demore una semana, pero algunos problemas demoran minutos y otros pueden demorar semanas dependiendo del alcance del componente y sus dependencias.

Paso 4+: depende.

Hay un par de escenarios que pueden surgir de la revisión de componentes:

  • Diseño para componentes con amplio uso. Tiene más sentido para nuestro equipo de Frontend-as-a-Service construir e implementar estos componentes, ya que se utilizarán en todo el producto.
  • Diseño para componentes con un uso más estrecho. A menudo, si se trata de un solo equipo que más necesita un componente, lo crearán de forma reutilizable y luego lo agregarán a nuestra Biblioteca de IU.
  • Diseño para componentes que no necesitan ser reutilizables. A veces, los componentes tienen un alcance tan limitado que no hay razón para que otro equipo necesite usarlo. En este caso, el componente se revisa para garantizar que se ajuste al resto del sistema, y ​​luego el equipo lo integrará en su aplicación. Si necesita convertirse en un componente reutilizable en algún momento en el futuro, los equipos pueden agregarlo a la Biblioteca de la interfaz de usuario.

Si estos problemas provocan que sea necesario cambiar o agregar algo en nuestro Kit de interfaz de usuario de Sketch, recibirá una etiqueta especial con el nombre de la próxima versión. Esto facilita que los diseñadores que seleccionan el kit de interfaz de usuario puedan ver todo lo que debe abordarse.

También hay algunas razones por las cuales el equipo podría rechazar una solicitud de componente:

  • Diseño para componentes que consideramos innecesarios. El equipo siempre incluirá una razón reflexiva de por qué un componente no debería convertirse en un estándar o por qué no se ajusta a nuestras pautas. Si corresponde, se ofrecen otras soluciones o consideraciones.
  • Diseño para componentes que necesitan más información. A veces, los diseñadores necesitan volver al tablero de dibujo para descubrir detalles adicionales antes de que un componente esté listo para el horario estelar.

Para las personas: su sistema debería ayudarlo

Queríamos que Canvas fuera tan fácil de usar que nuestros diseñadores nunca soñarían con usar otra cosa. Entonces, por ejemplo, en lugar de usar solo números para etiquetar nuestras versiones del kit de interfaz de usuario, comenzamos a nombrar cada versión alfabéticamente después de raperos famosos. No solo obtuvimos datos divertidos y excelentes listas de reproducción, sino que también hizo que recordar y hablar sobre las diferentes versiones fuera mucho más fácil (como era de esperar, Jam Master Jay y Kris Kross es mucho más fácil de recordar que v1, v22 o v100). Una vez que lo hicimos a través del alfabeto, comenzamos a trabajar a través de los productos As Seen on TV.

Muchas gracias al comercial Hot Stamps por enseñarnos que todo lo que necesitas para impresionar a tus amigos es un poco de brillo.

Nos preocupamos mucho por evaluar y mejorar continuamente nuestro proceso para facilitar la vida de todos los miembros del equipo de diseño. Algunos ejemplos de los desafíos que hemos resuelto con el tiempo son:

Visibilidad de lo que está cambiando.

En los primeros días, los diseñadores del equipo tenían problemas para saber qué estaba cambiando a menos que estuvieran en el equipo de Canvas. Así que comenzamos a enviar correos electrónicos cada vez que lanzamos un nuevo Kit de interfaz de usuario de Sketch. Estos correos electrónicos nos ayudan a actualizar clara y consistentemente al equipo sobre las novedades y las diferencias en cada versión, y proporcionan un lugar fácil para que los diseñadores descarguen el nuevo Kit. Cada kit de IU también incluye un registro de cambios en la primera página del archivo de boceto.

Código coincidente en la Biblioteca de la interfaz de usuario para diseñar activos en el Kit de interfaz de usuario de Sketch.

Al principio, teníamos un kit de Sketch básico que catalogaba los diferentes componentes que podríamos necesitar y una biblioteca de componentes front-end para que los desarrolladores hicieran referencia y usaran, pero no siempre coincidían. Esta división condujo a un lenguaje no coincidente entre diseñadores y desarrolladores. Entonces, para cultivar la copropiedad entre diseñadores y desarrolladores, emprendimos un gran proyecto para que coincida con las convenciones de navegación y nomenclatura en nuestra Biblioteca de interfaz de usuario y nuestro Kit de interfaz de usuario de Sketch.

Pensar más allá de los componentes tradicionales.

Ilustraciones, diseños de página, estados vacíos, estados de error: lo que sea. Si la reutilización de un objeto crea apalancamiento, vale la pena convertirlo en un componente o un complemento. Nuestro equipo de Frontend-as-a-Service también ha facilitado enormemente a los ingenieros de los equipos de productos enviar componentes o complementos al sistema ellos mismos. También comenzamos a documentar patrones de UX (no solo "¿qué componente debo usar?" Sino "¿cómo debo usarlo?").

Pero ciertamente no lo hemos arreglado todo. Algunos desafíos que todavía estamos tratando de resolver y en los que hemos estado iterando incluyen:

Efectivamente asignando y mostrando prioridad.

Cuando comenzamos a mover nuestro proceso a Github, proporcionamos etiquetas que permitían a los usuarios elegir la prioridad de su solicitud en una escala de P1 a P3 (un P1 significaba "necesitamos hacer esto ayer" y un P3 significa "llegaremos a esto algún día"). Pero debido a que nuestro equipo se mueve muy rápido, casi todo terminó siendo un P1.

Pero tampoco podemos hacer todo: necesitamos equilibrar las prioridades de más de 40 equipos, y hemos tenido algunos problemas que se nos han escapado. Estamos repensando cómo priorizamos los problemas hoy para que podamos resolver tanto para el equipo que construye nuestros componentes como para los equipos que los están esperando.

No tener un recurso de diseño dedicado.

Si bien queremos que todos los diseñadores del equipo hagan una rotación, sus principales responsabilidades aún recaen en sus equipos de productos. Esto significa que debemos ser duros e ingeniosos cuando se trata de hacer el trabajo de manera oportuna. Podemos considerar complementar el equipo rotativo con diseñadores que se centren en el sistema a tiempo completo en el futuro.

En nuestro sistema confiamos

Tenemos una regla de oro aquí en HubSpot como parte de nuestro Código de Cultura: usar el buen juicio. Se deriva de una cultura de confianza y responsabilidad ante los demás. Construimos nuestros principios, pautas y procesos sobre una base de confianza para garantizar que nuestro sistema de diseño dure, porque un sistema solo funciona si las personas confían en él.

Creamos esa confianza al facilitar la comprensión de cómo se toman las decisiones y cómo contribuir si alguien quiere ayudar o no está de acuerdo con una decisión. Recopilamos comentarios periódicamente y hacemos planes para abordar las mejoras. Encontramos formas para que las personas que se preocupan por él o lo usan mucho se involucren. Y documentamos tanto como podemos sobre por qué se tomaron decisiones para que cualquiera pueda verlas y consultarlas.

Al final del día, hacer que el mantenimiento de nuestro lenguaje de diseño sea muy sencillo no solo fue bueno para nuestros diseñadores y desarrolladores, fue bueno para nuestros usuarios. El rediseño de nuestro producto con Canvas fue un gran cambio, pero nuestro objetivo era construir un sistema y un proceso tan fuertes que nunca más tendríamos que rediseñar nuestro producto.

Con la base que hemos creado con todo este sistema, tenemos la capacidad de realizar cambios más pequeños en nuestro producto con el tiempo. Nuevo color primario? Hecho. ¿Las esquinas redondeadas ya no son geniales? Ido. Los usuarios tienen problemas para descubrir cómo proceder en un flujo de asistente. Investigaremos y arreglaremos sin una auditoría completa de la interfaz de usuario en la aplicación.

Al crear un sistema de diseño sólido y un proceso sólido para respaldarlo, podemos apoyar un proceso reflexivo de evolución del producto, sin la carga de la revolución mayorista. Es un sistema que funciona.

Créditos
Ilustraciones de Sue Yee.

Publicado originalmente en el Blog del producto HubSpot.