Diseñador conoce a desarrollador: El control de versiones
Todos hemos sido conscientes de la brecha que existe entre los departamentos de diseño y desarrollo. Parece que hablamos lenguajes diferentes. Como veremos a continuación, muchas veces es por una falta de desconocimiento de las herramientas que tiene el otro perfil.
Es evidente que cuanto más se reduzcan las diferencias entre estos dos perfiles más eficientes serán departamentos y mejor se reflejará en el producto.
Por ello, como diseñadores, si queremos que el producto final que estamos diseñando sea satisfactorio, tenemos que entendernos con el desarrollador para evitar que la oficina se convierta en un nuevo escenario del Tekken.
Los dos perfiles están condenados a entenderse.
El diseñador tendrá que encontrar un sistema que pueda facilitarle la vida a desarrollador como este último tendrá que reflejar al máximo posible la idea inicial.
Estos dos perfiles usan tanto herramientas en común, como propias de cada uno. Pero, si quieren que su proyecto sea escalable, van a tener que usar una misma metodología junto con una organización y documentación en conjunto.
En ese proceso, es donde necesitamos un control de versiones.
Tener un control de versiones es una buena práctica tanto para trabajar en conjunto como para llevar un control de las diferentes estados por las que pasa un producto en un proceso iterativo. Es un gran paso integrar el control de versiones en un departamento de diseño y empatizar con el método de trabajo de quién va a llevar ese diseño a un proyecto funcional y viable.
Un control de versiones bien implementado ayuda enormemente en un departamento de diseño. Los desarrolladores en eso nos llevan una clara ventaja. Aprendamos pues de ellos.
¿Cómo hemos llegado hasta aquí?
Es algo curioso en el mundo del diseño digital que históricamente no se haya tenido un control de versiones organizado e integrado con otros departamentos para proyectos escalables, quizá debido a las herramientas que heredamos antes de la revolución del UX.
Illustrator y Photoshop no estaban adaptadas para la realización de productos digitales ni facilitaba el trabajo entre los dos perfiles, entre otras cosas porque no facilitaban la tarea de llevar un registro integrado con las diferentes versiones del diseño ni el trabajo colaborativo.
Para explicarlo en un contexto real, normalmente un desarrollador se enfrentaba a esto cuando le pasaban los diseños:
Todos los diseñadores hemos pasado por esto…seamos honestos. Por regla general los desarrolladores mantienen un orden y una documentación más actualizada. No obstante, como todo hay excepciones…
¿Que es GIT?
Recurrimos a Wikipedia para leer lo que dice sobre el tema que nos ocupa:
“Git (pronunciado “guit”2) es un software de control de versiones diseñado por Linus Torvalds, pensando en la eficiencia y la confiabilidad del mantenimiento de versiones de aplicaciones cuando éstas tienen un gran número de archivos de código fuente. Su propósito es llevar registro de los cambios en archivos de computadora y coordinar el trabajo que varias personas realizan sobre archivos compartidos.”
¿Mmm suena muy teckie y complicado verdad? bueno, pues no lo es tanto. A grandes rasgos, GIT es una excelente solución para gestionar los diferentes cambios que se producen entre los perfiles involucrados en la ejecución de un mismo proyecto. Es el control de versiones más utilizado.
Es decir, si tenemos varios desarrolladores tocando el código de una misma página, es de cajón que hay que tener un sistema para llevar un registro y sobre cada elemento cambia. Esto mismo puede aplicarse en diseño si hay varias personas involucradas en un mismo proyecto.
Por lo tanto, GIT es un sistema que nos permite guardar un registro de las modificaciones que realizamos sobre un fichero a lo largo del tiempo.
Esto supone una ciertas ventajas, las más destacadas según mi criterio:
- Un registro de modificaciones de archivos a lo largo del tiempo. Esto nos permite además ver los comentarios asociados a cada modificación y la persona que ha realizado dicha modificación.
- La posibilidad de volver al estado anterior de un archivo o conjunto de archivos si algo fue mal.
- Creación de ramas para gestionar cambios/diseños de un apartado en concreto del producto que eventualmente se juntarán con la rama principal (rama Máster) que indica la evolución oficial del producto.
- Facilidad para etiquetar modificaciones concretas a través de commits, para ver la evolución del producto y que facilite su documentación. Siendo escalable con el tiempo independientemente del desarrolladores que los crearon.
Por lo que las ventajas de usar este sistema serían:
- Facilita la colaboración entre diferentes y mismos perfiles a la vez.
- Puedes tener un histórico de cambios
- Su objetivo es compartimentar el producto en diferente versiones y apartados para poder probar funcionalidades nuevas de manera aislada sin perjudicar el producto final.
- Ayuda en la documentación y escalabilidad del producto.
Un ejemplo de las estructura de un proyecto con GIT
- La linea horizontal azul sería el Master (el proyecto en producción y el MVP).
- La linea horizontal morada sería el proyecto en desarrollo, con las implementaciones de funcionalidades que se están probando o con diseños alternativos de algunos componentes.
- La línea roja es un cambio puntual de algún bug del Máster
- Las verdes serían ramas paralelas de funcionalidades que se están testando y eventualmente se suben a desarrollo.
- Si esas features o funcionalidades están aprobadas por el equipo, se realiza un release.
Es una aproximación sencilla basada en GitFlow, aunque por supuesto, hay muchas otras alternativas.
¿Por qué no se ha generalizado GIT entre los diseñadores?
Es de destacar, que hasta hace bien poco, no existía un buen GUI basado en GIT y que estuviera adaptado para gente que no sabe usar el terminal del ordenador.
No obstante, hay mucha gente espabilada que se ha dado cuenta de esto. Actualmente contamos con varias soluciones a este problema. Herramientas como Abstract, Plant, Trunk o Figma difieren un poco entre sí, pero resuelven un mismo problema. Son soluciones visuales para el control de versiones. Veámoslas paso a paso.
GUI compatibles con Sketch basados en GIT
Abstract
Actualmente es el estándar en la industria, la herramienta en control de versiones basado en GIT que más éxito está teniendo. Mucho de ello se lo debemos a su cuidada interfaz. El video comercial de Abstract resume perfectamente el problema de escalabilidad de un equipo de diseño a largo plazo, y ayuda a explicar la utilidad de la herramienta:
Pros ✅
- Una de las mejores interfaces gráficas con control de versiones.
- Aprendizaje muy escalable. Al principio abruma pero luego es muy rápido e intuitivo.
- Está basado en GIT y se aprecia también en el GUI (indicando que son Commits, merge, etc)
- Buena documentación y comunidad.
- Se está convirtiendo en el estándar para el control de versiones en diseño.
- De momento no funciona con Adobe XD, está en beta
Cons ❌
- Es de pago y cuesta un riñón
- Actualmente no es compatible con herramientas como Photoshop o Illustrator.
Plant
Una alternativa muy usada en el sector empresarial, rival directo de Abstract. Lo bueno de Plant es su integración con Sketch. A través de su plugin puedes subir los cambios al diseño para que se les notifiquen a los desarrolladores. Funciona un poco diferente, ya que no se basa en el sistema de ramas de GIT en su interfaz gráfica sino que prefieren centrarlo como un timeline.
Pros ✅
- Comunicación de nuevos cambios entre diseño y desarrollo
- No hace falta bajarse de nuevo el .sketch si ya te lo has bajado
- Los conflictos al mergear se resuelven dentro de Sketch
- Hay prueba gratuita
Cons ❌
- No hay un status de los cambios en cada actualización de proyecto
- No es compatible con otro programa que no sea Sketch
- Es de pago
Versions
Una herramienta muy prometedora, que no he tenido tiempo de usar a fondo.
En su web, explican su funcionamiento a través de vídeos para que te hagas una idea.
Pros ✅
- Al poder integrarse con GitHub, podrás diseñar a través del código conectando los repos de diseño y desarrollo.
- Integración con Jira
- Según nos cuentan, parecen bastante comprometidos con la seguridad
Cons ❌
- Sólo soporta Sketch
- Diseñado para macOs
Homenaje a un caído: Oda a Trunk
Para mí Trunk era la joya de la corona, la herramienta que usaba en mi día a día y en mis proyectos freelance. Es por eso que me quedé bastante triste cuando anunciaron que iban a dejar de dar soporte el primero de Noviembre. En menos de tres minutos, te hacías con él.
Esperemos que su colaboración con Invision permita integrarse en su plataforma.
Pros ✅
- Válido tanto para Sketch como para Photoshop
- Interfaz limpia, minimalista y cuidada
- Extremadamente sencillo de usar
- Si tenías una cuenta de InVision era gratuito
Cons ❌
- Inestabilidad algunas veces en la plataforma ya que estaba en fase beta
- Consumía una cantidad de recursos exagerada en el disco duro
El futuro: Figma
Cada vez son más los diseñadores que se pasan a Figma y motivos no les faltan.
En el tema que nos ocupa, el hecho de ser una herramienta basada en el navegador permite que distintos diseñadores estén trabajando a la vez en un mismo proyecto. Esta herramienta es diferente al resto, ya que se parecería más a Sketch, pero con todas las ventajas de ser una aplicación basada en web. Es colaborativa, está orientada a desarrollo y tiene un control de versiones integrado.
Pros ✅
- El trabajo en equipo colaborativo directamente en la herramienta
- Puedes hacer commits de manera manual
- La opción de integrar librerías en los proyectos
- Muy orientado a la creación de sistemas de diseño
Cons ❌
- Más que conocer la herramienta, necesitas entender las posibilidades que aporta y saber organizarte.
- La integración con herramientas de terceros (Zeplin, InVision) no está tan desarrollada como en Sketch.
La tendencia en la industria parece dirigirse a una herramienta general para diseñadores y desarrolladores adaptada a cada perfil y que tenga en cuenta valores como el control de versiones, la colaboración, el feedback, la opción de diseñar en cualquier position (absolute, fixed, etc) y los artboards responsive. Aquí es donde Figma está dando pasos de gigante para ir en esa dirección.
Si has llegado hasta aquí, enhorabuena. Estás a un pasito más de reducir la brecha entre diseño y desarrollo.
Este artículo pretendía explicar la importancia del control de versiones y ser un pequeño compendio de las diferentes opciones para los diseñadores. Por supuesto, siempre todavía quedan aún más opciones, como Kactus.
Ahora te toca a ti, ¿Cuál herramienta con control de versiones crees que se adapta mejor a los diseñadores?
¡Gracias por leerme! 🤓
Para más temas relacionados con diseño y UX, consulta mi canal de Telegram
No dudes en contactar conmigo si tienes alguna pregunta😉
