Krypton Solid

8 formas de hacer que DesOps funcione para usted

8 formas de hacer que DesOps funcione para usted

¿Qué es DesignOps? ¿Por qué su equipo necesita esto? ¿Y cómo puede DesignOps ayudar a su equipo de diseño / desarrollo a tener éxito? Este artículo responde a estas preguntas y también le brinda consejos útiles sobre cómo comenzar a implementar este nuevo concepto en su equipo de desarrollo.

En el mundo moderno, es la velocidad del equipo de desarrollo lo que a menudo define la viabilidad de un producto. Al mismo tiempo, hay un elemento clave que es más importante y más problemático: el diseño.

El diseño a menudo se convierte en un cuello de botella y tiene un impacto significativo en todo el proceso de desarrollo, sin importar el tamaño de su equipo. A veces, los esfuerzos sobrehumanos de un líder de diseño ayudan a impulsar el proceso de diseño, pero tan pronto como aumenta la carga de trabajo, debe escalar su equipo.

¿Con qué frecuencia has visto:

  • desarrolladores inactivos, esperando obras de arte;
  • desarrolladores que carecen de activos de diseño;
  • misteriosos componentes nuevos que se parecen sospechosamente a duplicados de componentes existentes;
  • diversos elementos de diseño de diferentes diseñadores, para un mismo proyecto.

Si alguno o todos estos le suenan familiares, entonces es hora de implementar DesOps (operaciones de diseño).

Especialistas en DesOps

El término DesOps o DesignOps es una réplica del término DevOps que es una práctica de ingeniería de software que tiene como objetivo unificar los procesos de desarrollo para crear una mayor eficiencia. Al igual que los especialistas en DevOps, los especialistas en DesOps son diseñadores experimentados con habilidades de gestión que comprenden el proceso de diseño dentro del contexto más amplio del desarrollo de productos.

Si bien es posible que no todos tengamos el término «DesOps» en el título de nuestro trabajo, muchos diseñadores senior ya son responsables del mismo rol. Desde el establecimiento de procesos de diseño hasta el desarrollo de sistemas de diseño, la creación de estrategias y la gestión de equipos de diseño, DesOps es un rol cada vez más solicitado.

8 formas de iniciar DesOps

Lo que realmente importa es que este enfoque es escalable y relevante incluso en equipos con un solo diseñador. Entonces, ¿cómo empiezas a implementar DesOps?

1. Desarrollar un criterio para un diseño completo

Los diseñadores necesitan saber cuándo su trabajo está completo y listo para pasarlo al equipo de desarrollo. Por ejemplo, los diseñadores necesitan una comprensión clara de qué estados debe tener cada pantalla y qué activos serán necesarios para que el equipo de desarrollo cree esos activos.

Puede parecer que esta es un área que los diseñadores deben comprender de manera inherente. Pero en realidad es uno de los puntos de fricción más comunes en un proyecto y no debe ignorarse. Si articula claramente lo que se requiere, reducirá los conflictos y se asegurará de que todos comprendan sus responsabilidades.

Los beneficios de esto son: permite mantener un ritmo de desarrollo constante; reduce el tiempo total de desarrollo; reduce el número de discusiones necesarias entre diseñadores, desarrolladores y clientes potenciales.

2. Definir los requisitos de diseño y entrega

Para el último punto, estábamos considerando específicamente lo que el diseñador debería transmitir a los desarrolladores. Este punto trata sobre qué forma debe usar el diseñador para transmitir el diseño (maquetas, diseño pulido, prototipos, moodboards) qué debe proporcionar el diseñador para transmitir eficazmente sus intenciones en un formato que los desarrolladores puedan comprender.

Existen numerosas opciones, como Zeplin o InVision pero una de las quejas más comunes de los desarrolladores es que estos formatos no proporcionan todo lo que necesitan (como activos exportados). Sin embargo, esto suele deberse a que los diseñadores no han exportado correctamente sus diseños. Al aclarar a los diseñadores lo que se espera que produzcan, pueden transmitir los activos correctos fácilmente.

Debe crear un documento interno que contendrá requisitos técnicos específicos para activos, herramientas de diseño, colaboración con desarrolladores y otros miembros del equipo; finalmente, este documento debe definir claramente cuándo y cómo deben entregarse los diseños.

3. Desarrollar un sistema de diseño

Un conjunto de soluciones de diseño e ingeniería, así como guías para su implementación, garantizarán una serie de ventajas: integridad del producto; incorporación más sencilla y rápida de nuevos miembros del equipo; trabajo más eficiente de diseñadores y desarrolladores (ya que pueden comunicarse en un lenguaje definido por el sistema de diseño).

Los beneficios de esto incluyen: mejora de la calidad general del trabajo; reduce el «hundimiento» cuando escala el equipo; aumenta la velocidad tanto del diseño como del desarrollo.

4. Seleccionar, supervisar y restringir la caja de herramientas del equipo

A todos nos encantan las nuevas herramientas geniales, pero un equipo eficaz trabaja con un conjunto uniforme de herramientas, y garantizar esta unidad es su responsabilidad.

Todas las herramientas deben estar actualizadas, pero si se omite una actualización por cualquier motivo, todos deben omitirla.

Los beneficios de esto incluyen: mayor compromiso del equipo; mayor velocidad de diseño y desarrollo; colaboración en equipo mejorada.

5. Desarrollar un enfoque para el control de versiones

Los desarrolladores tienen más suerte en términos de esta tarea, porque el control de versiones del código es una industria madura con muchas opciones. Es difícil producir un enfoque similar para los diseñadores, ya que los procesos son muy diversos, pero en el último año herramientas como Resumen, Kaktus, y Planta han sido cada vez más populares. Incluso puede tener varios diseñadores trabajando en un solo diseño con algo como Figma.

Los beneficios de esto son: comunicación mejorada; escalado de equipo simplificado; Acelera los procesos de diseño, ya que varios diseñadores pueden trabajar en un solo proyecto de forma productiva.

6. Implementar prototipos y documentación visual

Para describir toda la funcionalidad relacionada con los diseños, intente utilizar «documentación visual» en lugar de escribir especificaciones técnicas. En la mayoría de los casos, es suficiente que un desarrollador tenga un prototipo interactivo para comprender la lógica básica y encontrar respuestas a la mayoría de las preguntas.

Los beneficios de esto incluyen: tiempo reducido para escribir especificaciones técnicas; reduce la escala de trabajo de los escritores técnicos; los desarrolladores dedican menos tiempo a leer documentación y más a escribir código; los diseñadores son más productivos; ritmo de desarrollo acelerado.

7. Integra a los diseñadores en tu marco de desarrollo

No hay absolutamente ningún lugar para el diseño en muchas metodologías populares de desarrollo de software; sea ​​cual sea el proceso de desarrollo que esté utilizando, busque espacio para los diseñadores.

Los beneficios de esto son: un equipo unido con una mejor comunicación; mayor velocidad de desarrollo; reducción del retrabajo y del tiempo de inactividad del desarrollador.

8. Presentar indicadores medibles de mejoras a todo el equipo

Debe demostrar constantemente el crecimiento de los indicadores cuantitativos y cualitativos gracias a los cambios implementados, tanto para los miembros del equipo como para la alta dirección. Sin esto, un equipo será reacio a cambiar, mientras que la alta dirección no podrá entender dónde y por qué se gastan recursos adicionales. La recopilación y presentación constante de resultados positivos después de implementar los cambios lo ayudará a obtener la credibilidad y la autoridad necesaria para realizar más cambios en el flujo de trabajo del equipo.

Los beneficios incluyen: mayor motivación y un equipo más fuerte; facilitación de nuevas reglas y prácticas; apoyo a la innovación futura.

Resumen

El término «DesOps» es bastante nuevo y apenas comienza a adquirir su significado; la primera conferencia DesOps solo se llevó a cabo en noviembre, en Nueva York.

Por ahora, simplemente llamaría a esto una cultura que tiene como objetivo desarrollar y facilitar procesos de diseño sólidos. Pero creo que en un futuro próximo tendremos esto como una función de diseño separada en cada equipo de producto. Sin embargo, creo que ya podemos hablar con seguridad sobre la importancia de introducir estas prácticas para mejorar la eficiencia del flujo de trabajo de diseño y el desarrollo de productos en general.

Deja un comentario