Alinear el diseño, desarrollo y programación de una aplicación es, sin duda, uno de los mayores retos a los que me he enfrentado. Conseguir convertir en realidad una aplicación tal y como se planteó y se diseñó en un principio, mantener un proceso de depuración y evolución fluido y continuo, o, en definitiva, que el producto final cumpla las expectativas marcadas al principio, es un proceso realmente complejo.
¿Pero por qué es tan difícil? Se podría pensar que es únicamente un problema de comunicación o cualquier otro punto más superficial, sin embargo, se trata de algo un poco más profundo.
En este artículo vamos a ver y comprender los puntos más débiles del workflow de desarrollo de un producto para así poder descubrir en profundidad las peculiaridades de cada fase. Todo ello nos ayudará a desarrollar una estrategia capaz de alinear los actores protagonistas del desarrollo de cualquier producto.
¿Cuáles son las fases de desarrollo de un producto?
Antes de ver cuáles son los problemas que podemos encontrarnos a la hora de alinear diseño y desarrollo, primero vamos a hacer un repaso rápido de las fases de desarrollo de un producto estándar. Las principales son:
- Arquitectura de la información: el primer paso se centra esencialmente en organizar, estructurar y etiquetar la información para que esta sea fácil de entender y utilizar. Esta fase consiste en analizar, investigar y detectar las necesidades.
- Wireframing y UX (User experience): el siguiente paso se centra en esquematizar toda la información recogida con el objetivo de diseñar una experiencia de usuario excelente. Incluye diseño visual de wireframes, storyboard o sketches.
- Diseño UI (User interface): la tercera etapa consiste en diseñar la capa externa del producto o servicio digital. Es decir, la interfaz con la que los usuarios podrán interactuar.
- Desarrollo front-end: en este punto, el equipo de front-end empieza con el desarrollo de la parte gráfica, utilizando los lenguajes de programación y frameworks más adecuados en cada caso.
- Desarrollo Back-end: por otro lado, tenemos el desarrollo del back-end, es decir, donde se encuentra la lógica y las funcionalidades del producto que estamos desarrollando.
- Fase de testeo y control de calidad: por último, antes de lanzar el producto y ponerlo en producción, es necesario comprobar que cumple con los estándares de calidad y que funciona como es debido.
Sin entrar en muchas concreciones, podemos ver cómo las diferentes fases pueden resultar complejas e implican muchos actores. Si no existe un punto de unión claro entre ellos, el desarrollo del producto será inconsistente y empezarán a aparecer los problemas.
Ejemplos comunes de problemas al desarrollar un producto
Si en algún momento has intentado construir en equipo un producto digital, es posible que te hayas encontrado con alguno de los siguientes problemas. Se trata de ejemplos muy comunes que suelen aparecer cuando no se sigue un procedimiento de desarrollo claro y no somos capaces de alinear diseño y programación.
Pérdida de elementos durante el proceso
Un problema bastante común es que el comportamiento de un elemento (una animación, por ejemplo) concebido en la fase de UX y UI no llega a implementarse en la fase de front-end. Esto suele suceder habitualmente porque no hay tiempo y porque se priorizan otras funcionalidades más clave para el funcionamiento del producto.
Bien, lo que suele pasar es que ese comportamiento que se planteó en las fases iniciales queda en el olvido y nunca llega a implementarse, con la debida frustración del equipo creativo que lo planteó.
El diseño final no es fiel a las propuestas
Otra de las cosas que te puedes encontrar es que, cuando miras el producto final y lo comparas con las propuestas de diseño, estos no encajan. Aunque todos los elementos están ahí, los colores coinciden o los botones tienen un ese borde redondeado, hay algo que no encaja y no sabes muy bien por qué.
En definitiva, ves que el producto final no queda como se había diseñado. Eso es algo realmente muy frustrante.
Falta de comunicación entre departamentos
Es también muy habitual recibir quejas, sobre todo del equipo de desarrollo front-end, de que los diseños que les están enviando son imposibles de implementar o requieren mucho tiempo de implementar, o que les falta información de, por ejemplo, efectos hover o de cómo tiene que ser el comportamiento response.
Podríamos estar infinitamente enumerando ejemplos como estos. La cuestión es: ¿podemos crear un sistema para desarrollar un producto donde podamos evitar la gran mayoría de estos problemas?
La respuesta rápida es sí, pero hay que tener un equipo alineado, una buena planificación, y un sistema de alineamiento y seguimiento constantes.
La figura del product manager es clave
Una vez vistos los principales problemas que pueden surgir durante el desarrollo de un producto, la pregunta sería: ¿cómo podemos implementar un sistema capaz de alinear los equipos de diseño y desarrollo? ¿Cómo podemos hacer que exista esa unión necesaria para que todo funcione tal y como debería?
Sin duda alguna, lo mejor para que el sistema funcione y crear un punto de unión claro es disponer de un buen jefe de producto. Se trata de una persona (normalmente, senior) con la experiencia necesaria para conocer en mayor o menor medida lo que supone cada uno de los pasos del proceso que hemos visto al principio de este post.
Este perfil es la clave para alinear diseño y desarrollo, ya que hay muchas cosas que convergen entre los diferentes departamentos que se encargan de dar forma a un producto.
La realidad es que cada uno tiene su propio idioma para decir las mismas cosas. Por eso un jefe de proyecto resulta clave. Este puede hablar con todos en su mismo idioma para, más tarde, poder traspasar la información de forma transversal con el fin de que todos lo entiendan de la misma manera.
Las reuniones semanales y un buen project manager pueden mantener al equipo alineado y unido
Es responsabilidad del project manager que cada semana se avance y que se mantenga la estrategia a corto, medio y largo plazo. Este es el encargado de plantear las acciones semanales a partir de una hoja de ruta.
Programar reuniones semanales ayuda mucho a mantener al equipo alineado. Según mi experiencia, hacer una reunión matinal los viernes para ver cómo ha ido la semana y dejar planificada la siguiente es lo que mejor funciona.
Lo que me he dado cuenta con el tiempo es de que estas reuniones a primera hora los lunes se hacen más pesadas y consumen bastante energía.
Hacerlas a final de semana también resta ansiedad, porque te vas de fin de semana sabiendo ya lo que has de hacer la semana siguiente, y, si había algún tema delicado a tratar, ya se ha tratado, por lo que te quitas ese peso de encima.
En definitiva, todo el mundo acaba la reunión alineado con los siguientes pasos a realizar y una misma fotografía a medio y largo plazo.
Cómo alinear diseño y desarrollo para construir un producto único
Para seguir con los ejemplos, no puedes estar hablando de la misma manera del comportamiento response a un front-end que a un diseñador UI, ya que este segundo probablemente no entienda las complejidades técnicas que comporta y no le puedes hablar de plantear las media query para que sea response first. O a un front-end de plantear el diseño partiendo de una retícula de 8 px y construir todos los elementos a través de múltiples de 8. Pero la realidad es que, al final, el desarrollo front-end debe verse como diseño.
El alineamiento no solo es cuestión de cómo se comunican los departamentos, sino de cómo se construye el producto. La clave de todo esto es deconstruir el producto desde el principio, y todo lo que se cree en las fases iniciales de UX y UI no puede ser trivial.
Algo tan sencillo como poner un título en una sección no puede colocarse de forma aleatoria; es necesario que se generen los puntos vectores transversales entre los departamentos. Imaginemos que este título tendrá un color verde, será un tag H3 y tendrá un tamaño de 26 px.
Bien, todo esto tiene que estar definido como un estilo de título, el color tiene que corresponder a una paleta de colores definida y, al ser un H3, hay que ver si sería un H3 genérico definido o sería alguna variante.
¿Por qué es tan importante? Lo que suele pasar es que el equipo de diseño genera sus estilos, y el equipo de front-end los suyos propios, por lo que no siempre han de coincidir, así que un cambio de estas características podría no tener el comportamiento esperado en la planificación final, ya que los criterios para decidir qué tipo de título es han podido ser diferentes.
Es por eso por lo que el equipo de desarrollo front-end y el equipo de UI y UX necesitan tener los estilos definidos exactamente de la misma manera. Cuando se genera un estilo en diseño se genera en desarrollo, y el jefe de proyecto se tiene que asegurar que así sea.
Ahora imaginemos que desde diseño se ve necesario cambiar el tamaño de estos títulos a 32 px por un tema de legitimidad, pues es muy fácil indicar al equipo front-end en qué estilo se tiene que aplicar.
Trabajar por módulos, otra de las claves
Otra de las claves para mantener al equipo alineado es trabajar por módulos. Por poner un ejemplo sencillo, imaginemos una zona de suscripción: esta zona tiene un título, un formulario, un botón de suscripción y una imagen de fondo. Además, es una zona que se repetirá en distintas páginas. Bien, ahora hemos de pensar en esta zona como un módulo estanco, que se plantea, diseña y desarrolla como tal.
Así pues, a este módulo se le nombra de la misma manera en todo el proceso, por ejemplo, BlogSubscription, y así todos saben a qué se refieren cuando se nombra. Este módulo tiene que ser un elemento estanco en UI y UX (como un símbolo en Sketch, por ejemplo), también en el front-end (como, por ejemplo, un componente de ReactJS) y sus funcionalidades en Back-end (por ejemplo, en un objeto Class).
Conclusiones
Como todos los métodos, en la teoría siempre funciona mejor que en la práctica, y aunque entrar en detalle requeriría que me extendiera mucho más, en mi experiencia, si se dedica un mínimo de tiempo inicial para planificarlo bien y alinear al equipo en la forma de trabajar, es un método fácil de implementar y mantener en el tiempo.
A pesar de que inicialmente esto puede conllevar más trabajo, la realidad es que, cuando los equipos de diseño y desarrollo están alineados, el trabajo diario es mucho más productivo y eficiente. Si utilizamos una metodología como esta, el mantenimiento y la evolución del producto son mucho más sencillos.
También podemos obtener muchísimas ventajas en la parte de control de la calidad. Este proceso se vuelve mucho más ágil, puesto que existe un orden evidente, algo que permite detectar los puntos débiles fácilmente o sobre qué elementos hay que hacer un mayor control.
Mejorar la comunicación, hacer énfasis en los puntos clave o trabajar por módulos es, sin duda, elemental en el desarrollo de un producto. Todos estos factores deben estar bajo la supervisión de un product manager experimentado. Este es el punto de unión clave entre los distintos departamentos.
Dedicar el tiempo necesario a la planificación y a encontrar el método de trabajo más eficiente es algo que la experiencia y el tiempo me han enseñado. Gracias al uso de esta metodología, no solo conseguiremos un desarrollo de producto más ágil y dinámico, sino también un resultado final de mayor calidad.
Espero que este artículo te ayude a mejorar el proceso y, por ende, el resultado de los productos. ¡Si tienes alguna sugerencia o duda sobre el artículo, no dudes en escribirme a través de los comentarios!
