En DataCamp nuestra misión es democratizar la educación en ciencia de datos para todo el mundo, y con más de 2 millones de estudiantes en todo el planeta avanzamos a gran velocidad. Operar a este ritmo de crecimiento exige mucho esfuerzo de todo el equipo y trae consigo retos nuevos y emocionantes.
Para el equipo de diseño, esto significa pasar del diseño página a página a una forma de diseñar más escalable. Reutilizar componentes existentes, reducir tiempos de desarrollo, mejorar la usabilidad y aumentar la accesibilidad son prioridades cada vez mayores.
Este artículo explica cómo estamos empezando a dar forma a un sistema de diseño.
¿Qué es un sistema de diseño?
Un sistema de diseño reúne todos los componentes necesarios para distribuir y reproducir una solución de diseño. No es algo nuevo ni exclusivo del diseño de productos digitales: hay muchos ejemplos a lo largo de la historia.
Por ejemplo, el primer imperio chino tenía el problema de que los arqueros no podían usar las flechas de sus compañeros. Cada flecha se diseñaba para un arco concreto, así que las demás no encajaban. El primer emperador chino, Ying Zheng, estandarizó el diseño de las flechas y eso tuvo un impacto enorme en sus conquistas militares.
En los años 50, cada estación del sistema de metro de Nueva York tenía su propia señalética. Generaba mucha confusión porque cada estación indicaba la navegación a su manera. Como resultado, mucha gente dudaba en usar el metro porque no entendía cómo funcionaba. Massimo Vignelli y Bob Noorda crearon el NYC Transit Authority — Graphics Standards Manual, que documentaba cómo debían ser los rótulos y cómo colocarlos en las estaciones. Con el tiempo, este sistema se ha mantenido más o menos igual y todavía se usa activamente hoy.
¿Por qué necesitamos un sistema de diseño?
Cuando cada página se diseña de forma aislada, muchos componentes acaban duplicados o con variantes similares. Esto hace que el producto digital sea más difícil de entender para las personas usuarias y más difícil de mantener para ingeniería. En DataCamp, descubrimos más de 20 tipos de botones en todo el producto, cada uno con sus particularidades (estados hover distintos, estados deshabilitados inconsistentes, etc.). Es difícil llevar la cuenta cuando un producto crece rápido y mantenerlo se vuelve casi imposible. Ahí es donde entra en juego un sistema de diseño.
En un producto digital, un sistema de diseño describe los componentes de la interfaz que se pueden usar para construir una interfaz que resuelva un problema y ofrezca una experiencia coherente a la persona usuaria.
Cuando un sistema de diseño se ejecuta bien, provoca un efecto en cadena que …
- Reduce la falta de comunicación
- Reduce el tiempo de implementación
- Reduce el trabajo de mantenimiento
- Reduce los errores
- Reduce los tickets de soporte
- Aumenta la calidad
- Aumenta la eficiencia
- Aumenta la vida útil
- Mejora la facilidad de aprendizaje
- Mejora la usabilidad
- Mejora la accesibilidad
- Impulsa la innovación
- Mejora el enfoque
- Impulsa las ventas
No es fácil …
Crear, mantener e implantar un sistema de diseño requiere mucha disciplina y un esfuerzo continuo de todas las personas implicadas en el proceso de creación. No es solo diseño; ingeniería y product management también son actores clave. Todos deben poder hacer preguntas difíciles como: «¿Por qué estamos construyendo esto?», «¿Podemos reutilizar este componente en otro sitio?», «¿Ya tenemos algo parecido?», «¿Aporta este componente personalizado beneficios suficientes en comparación con el esfuerzo que supone?».
Design System 101 en DataCamp
1. Crear un inventario de componentes
Objetivo: asegurar que todo el mundo conoce la existencia y el estado de un componente.
Cuando me incorporé a DataCamp había un archivo de Sketch con colores, iconos, tipografías y algunos componentes básicos. Estaba lejos de estar completo, pero era un buen punto de partida. El equipo de front-end también tenía una colección de componentes que usaban en varios proyectos.
Juntos creamos un inventario en Airtable basado en los componentes que ya estaban en producción. Esto le dio al equipo de diseño visibilidad sobre lo que existía y nos evitó crear componentes nuevos sin darnos cuenta. También nos permitió ver cuántos componentes similares teníamos y lo grave que era la situación.
2. Usar convenciones de nombres
Objetivo: evitar malentendidos entre Diseño e Ingeniería.
Al comparar componentes, vimos que Diseño e Ingeniería no hablaban el mismo idioma. Por ejemplo, el «color primario» definido por diseño era el «color secundario» en código. Cosas así generan malentendidos cuando los equipos escalan y causan confusión y frustración. Nos aseguramos de usar la misma terminología en todos los equipos.
3. Optimizar el flujo de trabajo de diseño
Objetivo: no perder trabajo y tener un flujo transparente.
Trabajar juntos como equipo de diseño trae sus propios retos. Antes guardábamos los diseños en Dropbox, pero cuando el equipo empezó a crecer, el riesgo de perder trabajo y el esfuerzo para seguir los cambios aumentaron muchísimo.
El equipo estaba muy abierto a cambiar la forma de trabajar y empezamos a usar Abstract. Nos permitió versionar bien los diseños, tener un flujo de trabajo transparente y diseñar con más confianza.
4. Mejor documentación y onboarding
Objetivo: acelerar el onboarding y evitar sobrecarga de comunicación.
Empezamos a documentar nuestro proceso y el sistema de diseño con Slite. Si tenemos que explicar algo más de una vez, debe estar documentado y compartido con el equipo. Esto evita mucha comunicación innecesaria y previene que se pierda información.
5. Revisiones de diseño
Objetivo: alinear expectativas entre Diseño e Ingeniería.
Es importante que las revisiones de diseño se hagan en ambas direcciones. Las personas de diseño deben poder revisar el front-end, y el front-end también debe poder revisar el diseño. Quienes diseñamos tenemos esa tendencia a crear algo chulo y nuevo. Ingeniería debe poder plantear preguntas difíciles como: «¿Por qué estamos creando algo a medida?», «¿No podemos reutilizar este componente?», «¿Podemos mejorar este componente?», «¿Merece la pena este componente por el esfuerzo extra de desarrollo?». Se trata de justificar decisiones y alinear expectativas con todas las partes.
Conclusión
Acabamos de empezar a montar nuestro sistema de diseño y seguimos intentando dar sentido a todos los componentes duplicados que hemos encontrado en el producto. Queda mucho camino por delante, pero con cada componente que tocamos estamos creando un producto mejor, más coherente y más fácil de aprender para nuestros clientes.
Nos interesa saber cómo otras organizaciones dan forma a su sistema de diseño. Envíame un email si quieres compartir tu experiencia.
En DataCamp siempre buscamos talento para unirse al equipo. ¿Te interesa? Consulta nuestras vacantes.
