Desarrollo y diseño: Todas a una, Fuenteovejuna

Todavía existe un gap importante entre diseño y desarrollo. ¿Por qué nos llega un diseño construido, aprobado por cliente y «cerrado» a las desarrolladoras? ¿Qué ocurre en estos casos? Que la realidad debería de ser otra puesto que, la mayoría de las veces, manejamos tiempos y presupuestos que penalizan al desarrollo. Y luego viene Paco con las rebajas.

Poco se habla en el mundo del software sobre la importancia que tiene como desarrolladoras estar presentes en el inicio, aterrizaje, conceptualización y posterior diseño de un proyecto. Pues os vengo a decir, señoras mías, que la tiene y mucha. ¿Por qué? Atentas que aquí os lo cuento:

Pongámonos en situación. Cuando como equipo nos encargamos en su totalidad de un proyecto, el flujo natural y habitual de trabajo (muuuuy resumido) suele ser:

  1. UX hace su magia. Diferentes técnicas, talleres y metodologías bajan a tierra y se conceptualiza el proyecto. La UX entiende el negocio, las necesidades del cliente y con sus innovadoras ideas es capaz de plasmarlas en sus bocetos.
  2. Diseño saca la paleta de colores y el pincel (virtual). Recibe todas esas ideas y conceptos materializados en unos moqups a los que debe dar vida y color.
  3. UX/diseño presentan su creación a cliente. Se revisa, se retoca, se da el visto bueno. Generalmente se presentan un par de visualizaciones: Mobile, Desktop (bien grande, que luce mejor) suficientes para hacerse la idea de lo cuqui que va a quedar y con esto ¡a funcionar!
  4. Desarrollo saca pico y pala y a cavar. Ya tenemos el ok de cliente (¡bien!) Se da el pistoletazo de salida para el desarrollo del proyecto, un verdadero reto, entonces y solo entonces se involucra a desarrollo en el proyecto, ¿en serio? ¿no tenemos nada que decir en todo esto previamente?

“Ok, si, eh, ¿Habéis pensado cómo se va a ver en tablet? ¿y en desktop pero en pantallas pequeñas? ¿y esto para cuando tiene que estar?”

“Anda, ese pop up que escupe purpurina, ¿lo tenemos que hacer Ad hoc? Se me ocurre utilizar una librería que ya dominamos, espera, uff, que tiene sus limitaciones de personalización, no sé si cumplirá con el diseño, pero nos facilita muchísimo el desarrollo, ¿cuando habías dicho que se entrega el proyecto?”

“Lo guay sería poder configurar un tema con ciertas pautas visuales a seguir, lo habéis tenido en cuenta, ¿verdad?“

“Ostras, que bonito, de verdad, eh! pero sabes que eso es imposible tenerlo para esas fechas, ¿no? ¿cliente lo sabe?”

¡BOOM! ¿Y ahora qué?

(Toda similitud con la realidad es mera coincidencia, ninguna desarrolladora fue dañada en este proceso) 😉

Bajo mi experiencia, involucrar a desarrollo en el proceso de consultoría y diseño no solo es una grandísima idea, si no que es fundamental para el buen funcionamiento y el equilibrio del proyecto y del equipo. Pero sobre todo para poder contemplar un millón de cosas que a perfiles menos técnicos se les pueden escapar.

A veeer, no paniquing, María, para eso están luego las reuniones de planificación en las cuales aterrizamos las historias de usuario, hacemos un repaso de las implicaciones de la tarea, revisamos diseños, ponemos en común, estimamos, etc. Ahora sí que sí podemos darle a cliente una fecha final de entrega «real». 

Tras este ejercicio, si nos han surgido grandes incertidumbres, podemos trasladarle qué implicaciones tienen,  en qué consisten, dónde podemos encontrarnos mayores dificultades, etc. 

Peeeroo, yo pregunto: ¿y si contemplásemos de inicio dichas incertidumbres? ¿No evitaríamos darle al cliente sensación de desconfianza porque le estamos recortando alcance al no tener en cuenta ciertos puntos críticos (que es normal que surjan)?

Y como equipo, ¿no seríamos todas más felices, iríamos más a seguro y yendo todos a una (fuenteovejuna) nos ahorraríamos sensaciones de pánico al inicio de un proyecto? ¿no tendríamos también la sensación de estar todas más involucradas, de ser escuchadas y de tener más contexto y conocimiento global del proyecto (y visión de negocio de nuestro cliente)?

En Biko tenemos clara la importancia de esto y llevamos tiempo trabajando en ello, no es tarea fácil, pero estamos viendo las ventajas que supone. ¿Alguien técnico decidiendo diseños? ¿WTF? Pues sí, ¡es posible! Gracias a ese trabajo conjunto hemos conseguido reducir el GAP existente entre el mundo del color y de los 0 y 1, y hemos podido comprobar que nos ayuda, ¡y mucho!

¿Que cómo lo hacemos? Pues es más sencillo de lo que podáis pensar

¡Diseño y desarrollo hablan! Generan una relación de comunicación directa, un entorno seguro en el que la escucha activa, el trabajo en equipo y la exposición de ideas tiene lugar durante el proceso de creación y diseño.

Y cuando hablo de diseño involucro también a UX, que es quien se encarga de que todos tengamos clara la idea de negocio, el flujo de navegación, posibles interacciones con el usuario, etc.

Manteniendo dichas conversaciones se genera un lenguaje común a todos para poder hablar el mismo idioma y entendernos teniendo siempre presente y sin perder el foco en que el usuario siempre es lo más importante. Que estas conversaciones no penalicen la experiencia de usuario final y que tampoco penalicen el proceso creativo de diseño, sino que, todo lo contrario, sirven para nutrirlo, para hacerlo más completo y conseguir que la persona encargada del diseño sea más consciente de las implicaciones que conlleva diseñar de una manera u otra. No es un ejercicio para cortar las alas a nadie. 

Para poder ayudarnos a crear ese lenguaje común es de gran utilidad generar un buen sistema de diseño. No solo facilita ese entendimiento si no que nos ayudan a generar un diseño limpio y coherente y una construcción y mantenibilidad del proyecto óptima, ¡todos salimos beneficiados! 

Por suerte, a día de hoy contamos con infinidad de herramientas colaborativas que facilitan mucho esta labor de comunicación entre ambos perfiles, como lo son  Figma o Zeplin y en dichas herramientas nos apoyamos en Biko en nuestro día a día, ¡pero hablar de las bondades de las mismas da para otro post!

Un ejemplo de cómo enfocamos este proceso inicial de lo que podría ser un comienzo de dichas conversaciones podría ser así:

  1. Diseño/UX y desarrollo analizan los moqup conjuntamente prestando especial atención a lo que puedan considerar puntos críticos a la hora de la implementación, casuísticas a tener en cuenta, interacciones con el usuario (efectos de hover, animaciones), etc. poniendo encima de la mesa posibles soluciones. Trabajar en la creación del sistema de diseño. Establecer pautas a seguir en espaciados, tipografía, tamaños de fuentes, iconografía, etc. Sacar posibles patrones comunes que puedan ser componentes transversales, botones, links, tags, etc.
  2. Diseño materializa dichas ideas teniendo presentes las decisiones tomadas entre todos, sacando su lado más creativo pero siendo consciente de las implicaciones de sus decisiones.

Y a partir de aquí se da lugar una comunicación más fluida, no dirigida en la que se van sacando las ideas y cerrando diseños en un proceso de colaboración continua. 

No hay una fórmula mágica para que esto funcione más allá del uso del sentido común, ganas trabajar en equipo y de querer construir un proyecto de una manera eficaz y cómoda para todos pero sin olvidarnos de la calidad. 

Entonces parece que con hablar mucho al inicio bastaría y ya si eso a otra cosa mariposa

Noooo, para nada. Este es un proceso vivo y en continuo cambio. Como todo, vivir con incertidumbre no es algo que se pueda evitar al 100% (si no que se lo digan al 2020) pero sí que es algo sobre lo que se puede actuar en la medida de lo posible. Siempre van a surgir dudas, casuísticas no contempladas, somos humanas.

El proceso de trabajo conjunto sigue siendo vital para poder seguir desarrollando el proyecto, la diseñadora no se desvincula del proyecto una vez «termina» sus diseños, su labor no consiste en: ahí te dejo mis diseños, ¡suerte con el desarrollo amiga! No, sigue implicada, sigue trabajando en ello y sigue de cerca la evolución del mismo para poder estar al día y lo más alineada posible con las desarrolladoras (para eso tenemos agile no?) ¡Y más le vale! que somos quienes damos forma a su preciosa creación.

Y eso es lo bonito de todo esto porque trabajando así queda demostrada la eficacia de los equipos multidisciplinares ¡Y mola mucho! 🙂