Las áreas de Tecnología y Sistemas de Información de las grandes empresas son conscientes de los beneficios de la "normalización" de interfaz en cuanto a su aspecto.

En grandes departamentos de tecnología formados por equipos variados y numerosos cada uno con sus propios usos y metodología normalizar supone un cambio de metodología de trabajo que debe abordarse desde una perspectiva global e integradora.

La demanda de aplicaciones de negocio de interfaz web y su apertura tanto a usuarios internos como externos (entranet, internet) y la situación de inconsistencia entre entornos ha despertado una especial sensibilidad por el diseño gráfico y la normaliziación.

El primer paso hacia la normalización suelen ser los "Libros de Estilo" y los mal llamados "Manuales de Usabilidad".

Qué es una Guía de estilo

Es un documento que recoge normativas y patrones básicos relacionados con el "aspecto" de un interfaz para su aplicación en el desarrollo de nuevas "pantallas" dentro de un entorno concreto. (sitio web de contenidos, nuevas secciones, entorno de aplicaciones de negocio).

Hemos dicho "aspecto". ¿Desde qué otras perspectivas debería abordar una "Guía de Estilo"?

Conceptualmente, el interfaz de usuario descansa en 3 puntos:

• Significado (qué): es la base del interfaz. Recoge el contenido o información de la pantalla. Textos, campos de formularios, botones, menús...
• Comportamiento: trata el funcionamiento del interfaz. Cómo se comporta cuando un usuario envía un formulario (validaciones), hace clic en un enlace...
• Aspecto: apariencia final de un sistema: colores, tipografía, dispocición de los elemepntos en pantalla (layout).

Las Guías de Estilo, generalmente se centran en el "Aspecto". Puntos como diseño y maquetación (colores, tipografías y píxeles), y apenas incluye criterios o casuística para aplicar en el proceso de diseño de interfaz ("Significado").

Las Guías de Estilo no son Manuales de Usabilidad

A menudo se confunde el término "Guía de Estilo" con "Guía de Usabilidad" y un cambio de diseño lleva a definirse como una "nueva usabilidad". ("Necesitamos adaptar las aplicaciones antiguas a la nueva usabilidad" (sic)).

Hay personas que identifican "aspecto" y "usabilidad": esto lleva a que dos aplicaciones pueden ser radicalmente opuestas en usabilidad cumpliendo ambas las pautas de una "Guía de Estilo".

Poniendo por ejemplo un coche: Desde una perspectiva de "significado" un coche se adapta a un uso por sus características (carretera, familiar, pequeño, todoterreno, descapotable) y no por su color ("aspecto").

Identificar "usabilidad" y "diseño" equivale a decir:

- "Quiero un coche rojo."
- "¿Para que lo quieres? Carretera, montaña, niños..."
- "¿Qué más da? Que sea rojo."

Para que una Guía de Estilo pueda convertirse en un manual de usabilidad debería tocar puntos relacionados con "significado" ofreciendo criterios para, dentro de un estilo definido, seleccionar las características que se adapten al destino final de una aplicación (objetivos+usuarios+contexto).

Destinatarios de las Guías de Estilo

Las "Guías de Estilo" son creadas inicialmente como documentos voluminosos muy vistosos que ilustran sobre la apariencia del interfaz de un sistema.

Su problema más grave es su falta de usabilidad:

Están pensadas desde una perspectiva de diseño y márketing y no tienen en cuenta las necesidades de sus verdaderos destinatarios: *Diseñadores y Programadores de interfaz*.

Una buena Guía de Estilo, debe integrarse de manera eficiente en el proceso de trabajo de un programador ofreciendo criterios y ayudando en la toma de decisiones en aspectos de diseño de interfaz.

No deben ser una carga: han de ir acompañadas por acciones de promoción y formación y materiales de apoyo que ahorren trabajo al programador.

Características de una Guía de Estilo útil

Una Guía de Estilo debería abordar la perspectiva del "significado" del interfaz.

• Usable: invitar al uso. Debe integrarse de forma cómoda en el proceso de trabajo de un desarrollador dándole respuestas a situaciones propias dentro de la construcción del interfaz de una aplicación.
• Visual: huir del texto. Por experiencia, una Guía de Estilo no se usa, y esta probabilidad se reduce drásticamente cuando se basa en texto lo que lleva a una desactualización y abandono.
• Educativa: rica en ejemplos aplicables Y RAZONADOS que permitan desarrollar criterios mínimos de usabilidad y estética al personal técnico.
• Actualizada: debe contener ejemplos útiles, actuales y materiales para su aplicación directa disponibles a través de repositorios.

Problemas de las Guías de Estilo: nadie lee

La experiencia demuestra que los equipos de desarrollo no se apoyan en las "Guías de Estilo" para realizar su trabajo.

Razones:

• Resultan demasiado abstractas y simplistas: se crean desde áreas (márketing, negocio...) que carecen de visión de la complejidad del trabajo del desarrollador obviando su problemática cotidiana.
• Falta de adecuación a los métodos de desarrollo: El desarrollador no tiene tiempo para leer ni asimilar una documentación que además de ser voluminosa, le resulta ajena.
• Demasiado detalle: la documentación entra en cuestiones de detalle (pixels de separación entre elementos, tipografías, colores y valores hexadecimales) impropias del trabajo de un desarrollador.
• Falta de mantenimiento consistente: no existe una política de mantenimiento del Manual con una visión integradora de todo el proceso de desarrollo.
• Falta de apoyo: la Guía se publica sin acciones de promoción, formación y apoyo. La documentación caduca por no uso con lo que se vuelve a una situación similar a la de partida.
• No tienen utilidad real: no se promueve la reutilización de soluciones (conocimiento, componentes) entre los diferentes equipos de desarrollo.

Crear una Guía de Estilos

Desarrollar una "Guía de Estilo" es un primer paso hacia un cambio cultural en las metodologías de desarrollo que deriva en la adopción de técnicas de Diseño Centrado en el Usuario.

Es necesario un equipo único de especialistas en interfaz de usuario con visión horizontal integradora del conjunto de sistemas y procesos de desarrollo que garanticen un entorno de aplicaciones consistente.

Los cometidos de este equipo son:

• Documentar: crear documentación de carácter visual, compuesta de literatura esencial, ejemplos razonados.
• Formar: dar charlas introductorias, cursos breves periódicos con el objetivo de desarrollar un criterio de usabilidad.
• Dar soporte: desde el arranque hasta el cierre del proyecto resolviendo dudas, detectando nuevas necesidades que se puedan plantear e incorporándolas a la Guía.
• Detección de patrones: identificación de patrones que puedan derivar en componentes de interfaz reutilizables para su uso por los diferentes equipos de desarrollo.

Para abstraer al programador de tareas de diseño, estos objetos deben llevar embebidos aspectos visuales y estéticos. Deben ser puestos a disposición de los equipos de programación a través de un repositorio único actualizado.
• Investigación e innovación: tener identificados patrones reutilizables y componentes libera recursos de realizar tareas repetitivas y de escaso valor añadido para la detección de líneas de mejora del interfaz, metodología y procesos de desarrollo. (Adecuación a estándares técnicos, accesibilidad, mejoras, tecnologías alternativas).
• Programar y realizar tests y pruebas con usuarios: conocer la apreciación de los usuarios de las soluciones incorporadas permitirá realizar correcciones e introducir mejoras.