Debemos tener un buen proceso de diseño que asegure entregar la máxima calidad posible y estandarizar el proceso.
Tener un buen proceso de diseño te permitirá trabajar con tranquilidad, poder informar a tu jefe / cliente / quien sea de cómo se encuentra el proyecto en cada momento y, sobretodo, te permitirá continuar pasándolo bien con lo que haces.
El proceso que te describo a continuación es el que, en mi opinión, sería el ideal.
Naturalmente en una empresa te encontrarás con distintos tropiezos: el copy no te enviará los textos a tiempo, el feedback llegará tarde y te hará volver a empezar… pero como siempre, lo importante es tener un proceso.
Toma de requisitos e investigación
Obviamente, antes de nada es importante hacer una buena toma de requisitos para tener todo el equipo alineado y saber bien qué hay que hacer. Habitualmente -aunque no siempre- se hace con el product owner y/o los departamentos de marketing o tecnología.
Después es necesario hacer un mínimo de investigación para saber qué estás “atacando”. Así conocerás mejor a tu usuario y podrás empezar a detectar cómo resolver el problema.
Contenido
Lo ideal es que antes de empezar ni siquiera a bocetar, tengas el contenido que tendrá el producto. Quizás no será el definitivo (porque siempre hay cambios), pero cuanto mejor se acerce a la realidad, mejor.
Te permitirá planificar correctamente bloques de texto, espaciados, titulares, imágenes, etc.
Bocetos
Sí, bocetos. Y a mano. Nada de empezar directamente con Sketch. El diseño requiere reflexión y no la conseguirás utilizando el ordenador.
Básicamente porque te vas a distraer alineando cajas de texto, jerarquizando textos y añadiendo colores cuando no debes.
Prototipaje del boceto
Con POP (Prototyping On Paper) puedes hacer prototipos directamente de los bocetos hechos a mano: solo tienes que hacer fotografías de cada pantalla y enlazarlas entre sí.
corregir errores en una etapa temprana.
Wireframes con alma
Una vez tienes claro qué tendrá el producto, es hora de empezar a pasar los wireframes a digital. Te recomiendo Sketch y, sobretodo, que los hagas ya pensando en el tamaño y las proporciones que tendrá en el diseño final.
Si lo haces así, te prometo que irás más rápido cuando sea la hora de diseñar “de verdad” ^^
Presenta la propuesta
Te esto oyendo desde aquí. Sí, la propuesta debería poder presentarse sin diseño.
¿Por qué? Muy sencillo.
De este modo puedes empezar a poner todo el mundo en la misma página (desarrolladores, product owners, CEO, clientes o quien sea) y corregir y/o iterar de una manera muchísimo más rápida.
Imagínate tener que hacer cambios en un diseño que ya tiene toda la parte de UI cerrada. Por ejemplo, encajar un bloque de texto que legal pide de repente, priorizar un texto (requisito de marketing), cambiar un input por un dropdown (facilitará el desarrollo), etc.
Itera, diseña y presenta
Con el feedback recibido, es hora -por fin- de empezar a diseñar.
La mejor manera de atacar un diseño es partiendo de una buena guía de estilo e imágenes y comenzar a crear los símbolos, estilos de texto y estilos compartidos que te permitirán reutilizar componentes.
Cuando esté finalizado, no está de más volver a mostrarlo a los interesados en el proyecto. Primero, por deferencia y segundo, por si mientras desayunaban se les ha ocurrido otro cambio. Tener el OK de todos es primordial.
Desarrolladores y Zeplin
No les pases a los desarrolladores el archivo de Sketch as is. Te agradecerán enormemente que les envíes la guía de estilo especificando las características de las tipografías y paleta de colores (tamaños, hexadecimales o RGBA, etc.).
Y ya, si te enrollas y utilizas Zeplin, te amarán. Con Zeplin podrán ver fácilmente cuánto mide cada bloque, qué margen y padding tiene, cómo se relaciona con el elemento que tiene al lado, etc.
Una vez está en sus manos no puedes desentenderte del proyecto. Forma parte de tu trabajo controlar la calidad y que se programa como lo has diseñado y como ha sido aprobado.
Conclusiones
Es obvio que no hay un proceso de diseño ideal y que todos están sujetos a mil variables, pero no está de más tener uno y ceñirse a él.
Como decía al inicio, también es importante porque facilita el desglose de tareas y distribuirlas en el tiempo. Obviamente si no eres freelance y trabajas en sprints con Scrum, esta parte ya se hace “sola”… pero en cualquier caso, es básico controlarlo al máximo posible.
