Llevas un rato mirando el componente. El estado hover no está diseñado. El disabled tampoco. El diseñador no está. Y tú tienes que decidir.
Un poco de contexto no viene mal
Un día cualquiera, en un lugar cualquiera, tal vez en una videollamada: un diseñador muestra su obra al cliente. Es un gran profesional en el arte de presentar su trabajo, de comunicar, de demostrar la calidad de su diseño, y el cliente queda maravillado. La propuesta es aceptada. ¡Qué bien, tenemos proyecto, arrancamos motores!
Ahora sí
El equipo de desarrollo se pone en marcha y llega el desafío de implementar la interfaz a código, añadir interacción con el usuario e intercambio de información con el back. En esta fase comenzamos a traducir a código un lenguaje de comunicación muy importante: el Design System o la guía de estilos.
Dentro del diseño de interfaces digitales, sea cual sea la herramienta —en su gran mayoría Figma, pero si os mola la IA, Pencil (está pegando fuerte)—, existe un concepto muy importante directamente conectado con la implementación en el front: los componentes y su componentización.
La característica principal que diferencia a un componente del resto de elementos que constituyen un diseño es su reusabilidad y la capacidad de responder a distintos estados: varias formas de mostrar información según la acción que realiza, el feedback que recibe o cómo interactúa con el usuario. Es, en definitiva, la comunicación que existe entre la interfaz y el usuario.
Por ejemplo, un botón puede llegar a tener un estado hover que indica que es pulsable, un estado focus para la navegación por teclado, puede estar deshabilitado o puede estar esperando una respuesta. Y es aquí donde muchos frontends nos encontramos con un problema: tenemos que implementar estos estados pero no están diseñados. Y no solo en botones. Los inputs tienen el mismo problema: el estado de error es uno de los que más frecuentemente falta en los diseños y tiene que resolver el frontend solo.
¿Cómo decido qué hacer? ¿Tengo algún criterio o proceso, aunque sea informal?
Cuando me encuentro con este caso y no tengo diseñador o no está accesible, lo que hago es tirar siempre del Design System. Nunca inventar nada. Si el Design System está bien implementado, será muy sencillo utilizar los tokens ya existentes y crear o modificar el componente añadiendo los distintos estados que luego se implementan a código.
¿Qué pasa cuando no hay Design System? ¿O cuando el Design System existe pero está a medias? ¿Qué haces entonces?
Cuando no hay Design System o está a medias, la forma de actuar es similar: ir a los elementos más básicos y primitivos del diseño (los tokens —valores nombrados de color, espaciado y tipografía que forman la escala base—) y aplicar desde ahí.
En ambos casos lo más importante es no inventar, porque inventar puede ocasionar falta de cohesión y coherencia en el diseño cuando ya partimos de una base. Piensa que el diseño es la comunicación que existe con el usuario para trasladar y compartir información técnica y relevante de la forma más sencilla posible, tenemos que respetar las normas ya creadas.
En mi caso, tener conocimientos y formación de diseño me ha permitido resolver estos casos con facilidad. He vivido circunstancias donde compañeros con perfiles más técnicos se han visto en esta encrucijada y les ha costado resolverlo.
En muchos casos por querer hacerlo bien, han tirado de creatividad cuando ya había material para continuar el diseño sin inventar. Tenemos el concepto erróneo de que el diseño de producto digital es crear una obra de arte. Pero las decisiones de diseño deben ser sistemáticas y con propósito, no caprichos estéticos. Es crear una interfaz óptima, capaz de ser utilizada por cualquier usuario sin apenas conocimientos técnicos, cuyo objetivo es obtener un resultado o resolver un problema de la forma más sencilla posible.
El diseñador debe entender que un producto digital siempre tiene interactividad, está vivo, se comunica con el usuario. Hay escucha y respuesta, y en esa comunicación hay muchos estados que deben tenerse en cuenta y estar bien diseñados para comunicarse con el usuario correctamente.
El programador no debe tener miedo a diseñar, porque no tiene que ser creativo: ya existe un lenguaje creado por el diseñador. Si no existe un Design System en Figma y trabaja con un template, el criterio es el mismo: observa cómo el template resuelve patrones similares y extiende de forma consistente desde ahí.
Es importante construir equipos donde tanto el frontend como el diseñador entiendan de producto y sean conscientes de que la interfaz es un lenguaje de comunicación entre el usuario y la app, que se inicia en el diseño y termina en el front cuando el usuario ha completado la acción de forma satisfactoria.
Si eres frontend y tienes que diseñar un estado que no existe, no hay que inventar nada, solo hay que ir a la parte más primitiva del diseño o template y replicar ese diseño al componente. Esto permite que mantenga el mismo lenguaje de comunicación.
Si necesitas un perfil que entienda el producto digital desde el diseño hasta la implementación de la interfaz, contacta conmigo.