Diseñar pensando en el rendimiento web

Rendimiento web, ¿Cómo diseñar pensando en él?

Si dividiésemos por áreas todas las tareas que componen la creación de un producto digital, a priori, el cuidado por el rendimiento web iría vinculado al área de desarrollo.

Es muy lógico pensar que la calidad del rendimiento va ligada directamente al desarrollo del producto a nivel de programación pero, en Redbility, tenemos claro que es algo que debe tenerse muy en cuenta en las fases de conceptualización y diseño, no sólo en las de desarrollo.

A título personal, cuando evalúo un producto, el rendimiento es algo que tengo muy en cuenta. Puedes tener un visual muy cuidado, un contenido de calidad, un front muy bien acabado… pero si la experiencia es mala a causa del rendimiento, difícilmente podremos decir que el producto es bueno. No lo digo yo, ni lo decimos en Redbility, creo que es algo innegable.

El rendimiento puede marcar la diferencia en si un producto es bueno o no.

En Redbility tenemos claro que debemos estar involucrados con el producto en todas sus fases y desde todas las áreas. Debe seguirse la evolución del producto durante todo el proceso, independientemente de nuestro rol. Es así como se construyen productos de calidad, siendo un equipo de profesionales que actúan como artesanos y que ponen mimo en todas las fases del proceso.

Partiendo de esta base, no es descabellado pensar que el rendimiento debería ser algo a tener en cuenta de principio a fin. Una mala conceptualización del producto, o diseñar sin tener en cuenta el rendimiento, puede hacer tanto daño como un código sucio y mal estructurado.

Hay muchos factores que pueden mejorar el rendimiento, pero en este post me centraré en qué se puede hacer desde el área de diseño.

¿Qué hay que tener en cuenta?

El jueves, 6 de julio de 2017, en el #RedbilitySkills de «Diseñar pensando en front» hicimos hincapié en muchos de los aspectos a tener en consideración desde visual.

Lo primero, para mi, es que un diseñador debe ser consciente del medio para el que diseña. Si creamos un producto web, tenemos que ser plenamente conscientes de que ese producto se va visualizar o consumir a través de un navegador web.

Hay que tener muy en cuenta la repercusión que puede tener el diseño en el rendimiento. Diseñar para dribbble no es lo mismo que diseñar para un producto real. Nuestra animación o interacción no va a reproducirse en un .GIF, puede que se reproduzca en un smartphone mientras se viaja en metro con una mala conexión y, recalco, en un navegador. Diseñamos para dispositivos móviles pero no tenemos de nuestro lado el rendimiento que ofrece una app nativa.

Tener en cuenta el rendimiento no se remite a esto último, a no excederse en materia de animaciones, eso es solo un ejemplo entre los muchos factores que pueden influir.

En el día a día de un diseñador hay muchos elementos que se pueden cuidar sin ningún esfuerzo y que pueden marcar la diferencia. Algo tan simple como no cargar fuentes en exceso a un proyecto puede suponer una gran mejora.

Simplemente con marcarnos unas pautas de “ahorro” conseguiremos aportar muchísimo a la mejora del rendimiento:

• ¿No puedo conseguir el mismo resultado con menos tipografías?
• ¿Podría cargar imágenes de menor tamaño?
• ¿Tiene sentido esa transición?
• ¿De verdad necesito esa animación en esta página?

Estos son sólo algunos ejemplos de cómo un diseñador puede aportar gran valor a la hora de cuidar el rendimiento, simplemente valorando si algo es verdaderamente necesario para el proyecto.

¿Tengo que saber programar?

Me gustaría arrojar algo de luz a ese debate existente sobre si un diseñador debe saber programar o si un desarrollador debe saber diseñar.

Mi opinión respecto a esto es que no hay que obsesionarse y que no es necesario especializarse en ambas áreas para ser un profesional más completo. Basta con adquirir conocimientos del otro área.

En el futuro me gustaría hablar sobre qué es para mi un desarrollador front y la importancia que debería tener el diseño en su profesión pero, por el momento, hablaré sobre lo que (en mi opinión) debería añadir a su skilling un diseñador.

No creo que un diseñador deba saber programar, pero sí tratar de comprender la lógica de un lenguaje de programación orientado a objetos, como es JavaScript.

El JS es el que va a dotar de funcionalidad y “vida” al diseño. Creo que es necesario entender cómo lo hace.

Conocer los distintos eventos que se producen en una web, por ejemplo, es algo que ayudará muchísimo al diseñador a la hora de cuidar el rendimiento, conocer los costes que suponen algunas reglas o simplemente diseñar sin desestructurar el marcado.

• El coste en performance que tiene un click no es el mismo que tiene realizar funcionalidades en un scroll.
• Hay reglas CSS con más impacto que otras.
• Obligar a cambiar el marcado en HTML por replantear estructuras distintas según las vistas, obliga a escribir código que podría ahorrarse.

Son solo un par de ejemplos sobre conocimientos que un diseñador podría adquirir sin esfuerzo y que ayudarían de forma muy considerable.

En esta sesión de #RedbilitySkills profundizamos en cómo llegar a alcanzar estos conocimientos y muchos otros gracias a colaborar con el equipo de desarrollo. También hablamos sobre los beneficios que supone para el equipo trabajar unidos en tareas de este tipo, tareas que hacen que las distintas áreas deban colaborar para afrontar retos, incluso hablamos sobre metodologías propias y de la forma que tenemos en Redbility de enfrentarnos a todo esto como equipo.

Siento no poder reflejar en estas líneas todo lo que dio de si nuestra charla y las cervezas de después, solo espero que pueda ayudar a hacer click y buscar ese cambio de mentalidad sobre que el rendimiento es solo competencia de los equipos de desarrollo. Espero que sea al menos una aproximación y que nos ayude a hacernos la vida más fácil en nuestros puestos de trabajo los unos a los otros.

¡Hagamos equipo!