Construyendo un lenguaje visual: detrás de escena de nuestro sistema de diseño Airbnb

Al trabajar en el desarrollo y diseño de software, a menudo se nos exige que enviemos soluciones únicas. A veces estamos trabajando dentro de las limitaciones de tiempo y a veces todavía no hemos acordado un camino a seguir. Estas soluciones únicas no son inherentemente malas, pero si no están construidas sobre una base sólida, eventualmente nos veremos obligados a pagar las deudas técnicas y de diseño acumuladas.

El lenguaje visual es como cualquier otro lenguaje. Los malentendidos surgen si el lenguaje no es compartido y entendido por todos los que lo usan. A medida que crece un producto o equipo, los desafíos dentro de estas modalidades se agravan.

El diseño siempre se ha centrado principalmente en los sistemas y en cómo crear productos de forma escalable y repetible. Desde los colores Pantone hasta los tornillos Philips, estos sistemas nos permiten gestionar el caos y crear mejores productos. Los productos digitales son quizás el terreno más fértil para implementar estos sistemas y, sin embargo, a menudo no se considera una prioridad.

Un sistema de diseño unificado es esencial para construir mejor y más rápido; mejor porque los usuarios entienden más fácilmente una experiencia coherente y más rápido porque nos brinda un lenguaje común para trabajar.

¿Por qué necesitamos sistemas de diseño?

Airbnb ha experimentado un gran crecimiento a lo largo de los años. Actualmente, nuestro departamento de diseño consta de casi una docena de funciones y equipos de resultados. Quedó claro que necesitábamos formas más sistemáticas para guiar y aprovechar nuestros esfuerzos colectivos. Si bien reconocimos estos desafíos dentro de la empresa, creo que son síntomas de problemas más grandes en la industria del software.

Muy pocas restricciones
El diseño de software tiene pocas restricciones físicas en comparación con muchas otras disciplinas de diseño. Esto permite una variedad de soluciones para cualquier desafío, pero también lo abre a experiencias de usuario inconexas. Como propietarios y diseñadores de productos, tenemos que crear y seguir nuestras propias limitaciones.

Múltiples diseñadores y partes interesadas
El software a menudo es creado por equipos, a veces equipos increíblemente grandes, de personas. El desafío de crear experiencias coherentes se multiplica exponencialmente a medida que se agrega más gente a la mezcla. Además, con el tiempo, no importa cuán consistente o pequeño sea un equipo, diferentes personas contribuirán con nuevas soluciones y estilos, lo que hará que las experiencias diverjan.

Multitud de plataformas
Necesitamos enviar nuestro producto en una multitud de plataformas y dispositivos. Mantener las características y diseños sincronizados requiere un esfuerzo considerable, que a menudo requiere que se repita el mismo trabajo en todas estas plataformas.

El software como un continuo
Otra cosa única del software es que, si bien puede considerarse un producto, en realidad no se desgasta ni se reemplaza como los productos de consumo tradicionales. El código y los diseños creados hace años todavía existen en muchos lugares, incluso después de que el panorama de una empresa y su producto hayan cambiado significativamente. Esto requiere mantenimiento y actualización constantes.

Llegando al trabajo

Para superar estos desafíos y mantener nuestro proceso de toma de decisiones rápido, reunimos un pequeño grupo de diseñadores e ingenieros [2]. Limpiamos nuestros calendarios, reservamos un lugar de estudio externo a las afueras de la sede central de Airbnb y nos dedicamos a diseñar y construir el Sistema de lenguaje de diseño (DLS).

El objetivo que establecimos para el DLS era crear un lenguaje de diseño más bello y accesible. Nuestros diseños deben ser plataformas unificadas que impulsen una mayor eficiencia a través de componentes bien definidos y reutilizables. Para enfocar nuestros esfuerzos, redujimos el alcance inicial para crear el sistema primero en plataformas nativas (iOS y Android).

Comenzamos auditando e imprimiendo muchos de nuestros diseños, tanto antiguos como nuevos. Al colocar los flujos uno al lado del otro en un tablero, pudimos ver dónde y cómo se rompían las experiencias y dónde necesitábamos comenzar a hacer cambios. Pensamos que la mejor manera de comenzar era abordando los problemas de frente. Cada uno de nosotros se centró en una pantalla o área de producto para rediseñar, y establecimos algunos principios para guiarnos con estos diseños individuales:

Unificado: cada pieza es parte de un todo mayor y debe contribuir positivamente al sistema a escala. No debe haber características aisladas o atípicas.

Universal: Airbnb es utilizado en todo el mundo por una amplia comunidad global. Nuestros productos y lenguaje visual deben ser acogedores y accesibles.

Icónico: nos centramos tanto en el diseño como en la funcionalidad. Nuestro trabajo debe hablar con audacia y claridad a este enfoque.

Conversacional: nuestro uso del movimiento da vida a nuestros productos y nos permite comunicarnos con los usuarios de manera fácil de entender.

Sentando las bases

Antes de comenzar este sprint de diseño, ya habíamos creado una guía de estilo básica, que llamamos la base. Esta base definió libremente nuestra tipografía, colores, íconos, espacios y arquitectura de la información. La base demostró ser esencial para guiar nuestro trabajo en una dirección unificada, al tiempo que nos permitió explorar individualmente soluciones de diseño creativo.

De esta manera, sentimos que todos estábamos trabajando juntos, hacia la misma idea. Al revisar nuestro trabajo colectivo al final de cada día, comenzamos a ver surgir patrones. Corrigimos el curso cuando fue necesario y comenzamos a definir nuestros componentes estandarizados.

Crear los componentes

Tradicionalmente, muchas guías de estilo definen componentes como componentes atómicos, que luego se utilizan para construir moléculas más complejas. En teoría, esto funciona bien para crear sistemas coherentes y flexibles. En la práctica, sin embargo, lo que sucede a menudo es que estos átomos reutilizables se utilizan de muchas maneras diferentes, lo que permite la creación de todo tipo de moléculas. Nuevamente, esto abre la puerta a todo tipo de experiencias desarticuladas y hace que el sistema sea más difícil de mantener.

En lugar de depender de átomos individuales, comenzamos a considerar nuestros componentes como elementos de un organismo vivo. Tienen una función y personalidad, se definen por un conjunto de propiedades, pueden coexistir con otros y pueden evolucionar independientemente. Un lenguaje de diseño unificado no solo debe ser un conjunto de reglas estáticas y átomos individuales, sino un ecosistema en evolución.

Un lenguaje de diseño unificado no debe ser solo un conjunto de reglas estáticas y átomos individuales; Debería ser un ecosistema en evolución.

Por ejemplo, nuestro elemento de avatar de usuario podría definirse inicialmente por una guía de estilo, pero su uso final en la plataforma puede asumir cientos de permutaciones, lo que dificulta la actualización exitosa del elemento de avatar en el futuro ”. Si queremos cambiar De estas cosas, podemos estar seguros de que no rompemos otras pantallas.

Cada componente se define por sus elementos obligatorios (como título, texto, icono e imagen) y, en ocasiones, puede contener elementos opcionales. Estos elementos están definidos tanto en el documento de Sketch como en el código. En lugar de permitir las líneas divisorias en sí, requerimos que cada componente tenga un divisor, que luego sea visible u oculto según la lógica de la vista.

Compilando la biblioteca

Al crear estos componentes, los recopilamos en un archivo maestro llamado biblioteca, al que nos referimos durante todo el proceso de diseño. Después de una semana o dos comenzamos a ver grandes saltos en la productividad al usar la biblioteca al iterar en los diseños. Un día, al armar un prototipo de último minuto, nuestro equipo pudo crear casi 50 pantallas en unas pocas horas utilizando el marco que proporcionó nuestra biblioteca.

Mientras la biblioteca crecía, comenzamos a organizar componentes individuales en mesas de trabajo que contenían elementos similares. Estas mesas de trabajo se organizaron por categoría general en: navegación, carpas, contenido, imagen y especialidad.

Creamos un conjunto de estos componentes para teléfonos (iOS y Android), y los adaptamos a los tamaños de tableta desde allí. Los componentes de la tableta son en gran medida los mismos que para los dispositivos móviles, y a nivel técnico el código solo necesita existir una vez en dos estilos diferentes. Con este sistema, los componentes pueden variar en su aspecto y posicionamiento, de manera similar a la forma en que el diseño receptivo funciona para la web. Los diseñadores pueden diseñar una pantalla una vez usando componentes comunes, y puede adaptarse fácilmente a diferentes tamaños de pantalla, así como a iOS y Android.

Para la tableta, creamos un par de conceptos de diseño simples, como Vistas de enfoque, que enfoca el contenido en la página, modales y diseños de 2 columnas y cuadrículas.

Todos los componentes y vistas están construidos con nuestro propio marco de vista técnica, que maneja estos estilos, estados y adaptabilidad. [2]

Lecciones aprendidas

Sabíamos que este era un proyecto desafiante. Significó rediseñar y reconstruir la mayoría de las vistas en nuestra aplicación. Logramos nuestro objetivo de crear el sistema y lanzar las nuevas aplicaciones el 17 de abril. Como con cualquier proyecto, hay cosas que desearíamos haber hecho de manera diferente.

No todos los componentes son iguales. En la mayoría de las aplicaciones hay un conjunto de componentes que se repiten con frecuencia. Para nosotros, estos componentes son filas (o celdas de tabla). Mirando hacia atrás, desearía habernos tomado más tiempo para pensar en las filas y llegar a un conjunto más fuerte de patrones y componentes. Al final, terminamos con muchos tipos diferentes con algunas inconsistencias.

Bosquejo. Inicialmente intentamos crear estos componentes como símbolos en Sketch, lo que resultó en un desastre. Incluso ahora, nuestros archivos de Sketch a veces son difíciles de mantener. En el futuro, esperamos encontrar mejores formas de mantener y crear nuevos componentes. [3]

Documentación. Este proyecto nos obligó a operar dentro de un cronograma ajustado, lo que nos hizo pasar por alto algunos de los procesos de documentación. La falta de documentación exhaustiva creó cierta confusión que podría haberse evitado. Al igual que con la codificación, documentar los sistemas a medida que se crean es primordial para el proceso. Tiene que hacerse tarde o temprano, y la documentación durante todo el proceso de creación permite una toma de decisiones más fluida.

Conclusión

Dado que el código y el lenguaje de diseño a menudo se comparten, ahora podemos compilar y lanzar funciones en todas las plataformas nativas aproximadamente al mismo tiempo. El desarrollo es generalmente más rápido, ya que los ingenieros de producto pueden centrarse más en escribir la lógica de la característica en lugar del código de vista. Además, los ingenieros y diseñadores ahora comparten un lenguaje común.

Los diseñadores también estaban entusiasmados con el sistema. Permite que las revisiones de productos se centren en los conceptos y experiencias reales de un diseño, en lugar de las opciones de relleno, colores y tipo. El DLS nos proporciona una comprensión compartida de nuestro estilo visual y simplifica las contribuciones a un solo sistema. Este sistema también nos permite a todos crear prototipos y experimentar con ideas en alta fidelidad más rápido y a menor costo.

Creo que con la ayuda de estos sistemas podemos centrarnos más en las experiencias y conceptos reales de los usuarios que queremos crear en el futuro.

También respondí algunas preguntas sobre Designer News AMA.

Actualización: para obtener detalles adicionales y desarrollos más recientes en torno a nuestro sistema de diseño, vea mi charla en la Conferencia Design Systems 2018 Helsinki, Finlandia.

Notas al pie:

[1]: Muchos grandes proyectos son sobre equipos y siempre hay muchas personas a las que agradecer, pero quería destacar a pocas personas que hicieron posible este proyecto:

Bek Stone, Adam Michela, Amber Cartwright, Alex Schleifer, Michael Bachand, Paul Kompfner, Sean Abraham, Salih Abdul-Karim, Michael Sui + muchos otros en los equipos de diseño e ingeniería. Gracias Josh Leong, Sola Biu, Catherine Waite por leer los borradores de esto.

[2]: Dejaré que uno de nuestros ingenieros escriba más sobre el aspecto técnico del DLS.

[3]: en nuestro caso, queremos que las personas puedan cambiar los tamaños de los símbolos (por ejemplo, debe incluir más contenido en un encabezado). Si necesita cambiar el tamaño o cambiar accidentalmente algo, Sketch (2.5) redimensionará automáticamente cada instancia de ese símbolo. Eso mataría su boceto por unos momentos y probablemente arruinaría su archivo permanentemente (a veces deshacer no funcionó). Terminamos colocando los componentes en Grupos de capas y dejando que la gente los copie y los pegue.

También usamos git / github para facilitar el proceso de actualización de archivos. Creamos y agregamos manualmente nuevos componentes a nuestro archivo de croquis de la biblioteca maestra, y enviamos solicitudes de extracción con un registro de cambios y exportaciones PNG generadas que documentan los cambios. Después de eso, el archivo de Sketch termina en una carpeta de Box compartida, que está vinculada a las plantillas de Sketch, para que todos tengan acceso a los nuevos componentes de inmediato.