¿Qué es DesignOps? ¿Por qué tu equipo necesita esto? ¿Y cómo puede DesignOps ayudar a su equipo de diseño / desarrollo a tener éxito? Este artículo responde 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 la que a menudo define la viabilidad de un producto. Al mismo tiempo, hay un elemento clave que es el más importante y el 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.
Cuantas veces has visto:
Si alguno o todos estos le suenan familiares, entonces es hora de implementar DesOps (Operaciones de diseño).
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 de DesOps son diseñadores experimentados con habilidades de gestión que entienden 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 de la misma función. Desde el establecimiento de procesos de diseño hasta el desarrollo de sistemas de diseño, la creación de estrategias y la administración de equipos de diseño, DesOps es un rol cada vez más solicitado.
Lo que realmente importa es que este enfoque sea escalable y relevante incluso en equipos con un solo diseñador. Entonces, ¿cómo empiezas a implementar DesOps?
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 construya esos activos.
Puede parecer que esta es un área que los diseñadores deberían comprender inherentemente. 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, entonces reducirá los conflictos y se asegurará de que todos entiendan sus responsabilidades.
Los beneficios de esto son: permite mantener un ritmo de desarrollo constante; reduce el tiempo total de desarrollo; reduce la cantidad de discusiones necesarias entre diseñadores, desarrolladores y clientes potenciales.
Para el último punto, estábamos considerando específicamente lo que el diseñador debería transmitir a los desarrolladores. Este punto es sobre qué forma debe usar el diseñador para transmitir las maquetas de diseño, el diseño pulido, los prototipos, las tablas de estado de ánimo; qué debe proporcionar el diseñador para transmitir sus intenciones de manera efectiva en un formato que los desarrolladores puedan comprender.
Hay 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 los activos exportados). Sin embargo, esto se debe 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 pasar 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.
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 simple y rápida de los nuevos miembros del equipo; un trabajo más eficiente tanto de diseñadores como de desarrolladores (ya que pueden comunicarse en un idioma definido por el sistema de diseño).
Los beneficios de esto incluyen: mejora en la calidad general del trabajo; reduce el "hundimiento" cuando escala el equipo; aumenta la velocidad de diseño y desarrollo.
A todos nos gustan las nuevas herramientas geniales, pero un equipo eficaz trabaja con un conjunto uniforme de herramientas y asegura que esta unidad es su responsabilidad.
Todas las herramientas deben estar actualizadas, pero si se omite una actualización por alguna razón, entonces todos deben omitirla.
Los beneficios de esto incluyen: mayor compromiso del equipo; mayor velocidad de diseño y desarrollo; mejor colaboración en equipo
Los desarrolladores tienen más suerte en términos de esta tarea, porque el control de versiones para el 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 Abstracto , Kaktus y Planta han sido cada vez más populares. Incluso puede tener varios diseñadores trabajando en un solo diseño con algo así como Figma .
Los beneficios de esto son: comunicación mejorada; escalamiento de equipo simplificado; Rastrea procesos de diseño de pistas ya que varios diseñadores pueden trabajar productivamente en un solo proyecto.
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: especificaciones técnicas de escritura de tiempo reducido; reduce la escala de trabajo para escritores técnicos; los desarrolladores pasan menos tiempo leyendo documentación y más tiempo escribiendo código; los diseñadores son más productivos; ritmo de desarrollo acelerado.
No hay absolutamente ningún lugar para el diseño en muchas metodologías populares de desarrollo de software; cualquiera que sea el proceso de desarrollo que esté utilizando, encuentre espacio para los diseñadores.
Los beneficios de esto son: un equipo unido con comunicación mejorada; mayor velocidad de desarrollo; retrabajo reducido y tiempo de inactividad del desarrollador.
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 gerencia. Sin esto, un equipo será reacio a cambiar, mientras que la alta gerencia no podrá entender dónde y por qué se gastan recursos adicionales. La recopilación constante y la presentación de resultados positivos después de implementar los cambios le ayudarán a obtener la credibilidad y la autoridad necesaria para futuros 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; soporte para la innovación futura.
El término "DesOps" es bastante nuevo y recién está comenzando a adquirir su significado; el primera conferencia DesOps solo se realizó 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 el futuro cercano lo tendremos como un rol de diseño separado 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.