Se lee en 3 minutos

El reto

En esta ocasión, os traigo un manual básico que sirve a la vez como UI Kit y como referencia de buenas prácticas para desarrolladores. El contexto y uso consiste en disponer de dicho manual en una intranet o algún otro lugar al que tengan acceso los desarrolladores y programadores de una Compañía. Se trata de un proyecto de consultoría para el cual ideé los contenidos del manual y también diseñé toda la parte gráfica.

La solución

El aspecto visual de este manual se inspira en los manuales de instrucciones típicos de electrodomésticos, muebles de Ikea, etc. precisamente para provocar en el usuario una sensación de familiaridad. Estamos acostumbrados a encontrar en un manual de instrucciones impreso un acceso rápido a la solución de un problema (montar una estantería o una nueva tarjeta gráfica, por ejemplo) y ese es precisamente el efecto que queremos conseguir en los usuarios de nuestro manual. Que lo lean rápidamente y sean capaces de entenderlo, asimilarlo y aplicarlo a los proyectos en los que participen.

El manual viene acompañado (aunque no se muestra en las capturas) de un UI Kit básico, basado en principios de ‘Atomic Design’ que los desarrolladores utilizarán para montar sus aplicaciones. 

Wireframes del manual

Se muestran a continuación wireframes de las primeras iteraciones que se llevaron a cabo.

Consejos finales

Por último, se muestra una lista de consejos que añadí en modo texto y como documentación ampliada, aparte del manual visual  en PDF que os he mostrado. 

Cabecera  (Logo + Menú):

Logo: La mitad izquierda se usará siempre para logo y claim (si hay).

Menú: Horizontal por defecto, submenús intentando no pasar los 3 niveles. Caso contrario revisar estructura (card sorting). Centrado o a la izquierda. En algunos casos  puede ir a la derecha el login / datos de usuario / settings. Como norma, los menús no deben tener más de 7 opciones principales, incluyendo login, user y settings. Evitar menús adicionales verticales.

Contenidos: usamos todo el ancho disponible del viewport, con unos márgenes por defecto. Sin containers de width máximo, sobre todo cuando hay mucha información que mostrar (paneles de control, dashboards). Ancho máximo (container) solo para pantallas muy grandes (1280 y superior?), para evitar problemas de legibilidad (párrafos demasiado largos).

Tablas: usar todo el ancho siempre. Que las tablas sean responsive, ya sea haciendo fijas ciertas columnas (acciones) + scroll horizontal o mediante conversión a formato vertical. En casos de tablas o contenidos muy difíciles de mostrar adecuadamente en mobile, mostrar mensaje de “es mejor verlo en desktop”. Misma idea para navegadores viejos o no soportados.

La edición de datos (celdas) se consigue usando el icono del lápiz. Como norma general usaremos ventanas modales (no escapables pulsando fuera). Si al pulsar el lápiz hay muchos datos que editar de esa fila, usaremos modal grande o como alternativa página nueva (menos recomendado por perder contexto).
En general, para desktop usaremos un máximo de 4 columnas (pantallas muy grandes) y un mínimo de 2.

Iconos: se recomienda el uso de iconos distintos a font-awesome, glyphicons etc. Según requisitos de compatibilidad, se podrán usar jpgs/pngs para navegadores legacy, y svgs con posibilidad de animación para navegadores más modernos.

Para otro tipo de elementos, se recomienda revisar criterios de Material Design y/o Human Interface Guidelines (mac).

 

Y esto ha sido todo. Como siempre, espero que os gusten los nuevos contenidos y sobre todo que os sea útiles. Pronto tendréis disponibles nuevos proyectos para analizar. Stay tuned!

 

 

 

Suscríbete a tonalidad.es