Quiero resumir en algunos puntos el proceso creativo y las pruebas de usabilidad que hay detrás de la creación de una nueva aplicación.
En realidad deberían ser más puntos, pero muchos se repiten, es un trabajo muy meticuloso que necesita muchas pruebas, a nivel de desarrollo y también de diseño.

Punto 1

Analizar la información que tenemos (briefing), en caso de no tenerla disponible, debemos recopilar toda la información necesaria, para tener perfectamente definidos los objetivos y la misión.

Punto 2

Investigar aplicaciones existentes y estudiar ideas que están funcionanando en la competencia.

Punto 3

Dibujar los primeros bocetos e ideas en lápiz y papel.

Punto 4

Una vez realizadas estas pruebas por tí mismo, llegando a la conclusión de que sí puede funcionar correctamente por tu experiencia personal y profesional, empezamos a pasar los bocetos a pantalla, con un programa de diseño. En mi caso utilizo el “Fireworks”.
Los bocetos generados en pantalla, van sin diseño, a modo de “WireFrame” . Simplemente son rectángulos colorados que me sirven para plasmar la idea y realizar una maqueta provisional sobre la que realizar pruebas.

Punto 5

Imprimimos y recortamos los “WireFrame” (como si fueran las páginas reales de trabajo), recortamos ventanas pop-up, pestañadores etc… todo lo que necesitemos, para simular una navegación dentro de una aplicación.

Puntos 6

Debemos encontrar un “observador”, en mi caso el responsable de desarrollo “Sgomez”.
Realizamos pruebas de usuarios, con gente de perfil diferente, tomando nota de todos los comportamientos, y damos las gracias a los participantes por ofrecernos su valioso tiempo. En nuestro caso utilizamos personal interno de la empresa, pero en el caso de que fuesen personas externas, deberíamos pagar la hora etc…

En esta fase descubriremos muchas cosas:
Por ejemplo, en esta ocasión nos sorprendimos mucho al ver que, al ver una rejilla vacía, los usuarios no hacían absolutamente nada. Sin embargo, nosotros estábamos convencidos, por costumbre, que sin dudar pincharían encima de una linea para acceder a ella, o al menos hacer algo y nos parecía lo más normal del mundo. Esto supuso una buena lección, que nos enseñó a ser más humildes y pensar que no siempre nuestras convicciones son ciertas.

Punto 7

Analizar los datos, encontrar soluciones eficientes, realizar nuevos Wireframe, imprimirlos.

• Para solucionar el problema mencionado antes, hemos puesto un botón “entrar” al final de cada línea de la rejilla y un check-list al principio de la linea para seleccionar. Funcionalmente a nivel de programación no sirve, en nuestro caso, pero fue muy útil para guiar visualmente a nuestro usario y que pinche en la rejilla.
• Otra mejora que realizamos está relacionada con los niveles de jerarquía. Nos dimos cuenta de que la pestaña “listado” no era necesaria y que los botones en la mismo nivel que la pestaña “listado” creaban confusión. Daba la impresión de que eliminaría toda la caja de contenido. Elaboramos una nueva propuesta en la que destacamos más los niveles de cada bloque de contenido. En cuanto a los botones, los colocamos justo encima de la rejilla, para hacer entender que actúan encima de ella y no de todo el bloque.

Punto 8

Otra prueba de usabilidad, recopilación de datos y volver al diseño a realizar cambios.

Punto 9

Ya tenemos una estructura más solida y usable, podemos empezar a diseñar, de verdad, cada uno de los elementos y componerlos.

Punto 10

Diseño y desarrollo, esta parte es donde se crea en real todo el diseño, realizando pruebas y solucionando fallos que se pueden encontrar por el camino.
Con mucha paciencia y muchas pruebas sobre la marcha, se sigue trabajando en equipo hasta alcanzar una maqueta que sea ya operativa.

Punto 11

Nueva fase de test de usabilidad, esta vez con diseño real y aplicaciones reales.
En esta prueba descubrimos problemas con los iconos (los botones de la aplicación).

• El primer problema era a nivel cromático: el contraste entre desactivado y activado era demasiado ligero y provocaba incertidumbre para algun usuario.
• Otro problema estaba en la estética del icono, que no era tan clara como a nosotros nos parecía, , en particular el icono papelera.
• Además de descubrimos algunos fallos de programación.

Punto 12

Analizamos los nuevos datos y buscamos la solución más correcta a cada problema.
Se cuidan los detalles, y se prueba todo lo que se puede para que no haya fallos de ningún tipo, ni a nivel de diseño ni tampoco a nivel de código.

• En esta fase solucionamos los fallos, mejorando el efecto de activado y desactivado con colores (azul como activado y gris desactivado), y los iconos se dibujaron con más detalles y más intuitivos.

Punto 13

Presentación del producto internamente.
Fue todo un éxito, y surgieron algunas ideas de mejoras para la aplicación.

Punto 14

Aplicamos las mejoras propuestas en la presentacion interna y aquí tenéis el resultado de la aplicación.

La moraleja es que para realizar un buen desarrollo y un buen diseño, debemos realizar muchas pruebas con diferentes usuarios, durante todo el procedimiento de creación y hasta al desarrollo, pensando en las personas reales que trabajarán con el producto final, y no desarrollar un producto hecho a medida para nosotros, que sólo sabremos utilizar nosotros.

Punto 15

Quiero que os fijéis en los elementos clave para hacer accesible nuestra aplicación a todos los usuarios, dejándole moverse con tranquilidad en nuestro entorno gráfico sin perderse.
Todo lo que añadimos o modificamos, surge de preguntas y dudas lógicas que nos hacemos de manera automática en nuestra mente. Por lo que lo que debemos hacer es tratar de solucionar todas estas preguntas de la manera más simple y eficaz.

Os dejo un listado para aclarar mejor las ideas, cada elemento responde a una pregunta logíca.

• Identificador Sitio: ¿Que aplicaciones estamos ejecutando?
• Identificador Usuario: ¿Quien soy, que rol tengo aquí?
• Nombre apartado: ¿Donde estoy, que estoy viendo?
• Nombre rejilla: ¿Como se llama lo que veo?
• Navegación local: ¿Que puedo hacer, como tengo que actuar?

Quiero dar las gracias a todo el magnifico entorno de trabajo, a todas las personas que participaron en este proyecto directa e indirectamente.
No menciono los nombres de todos para evitar que se me escape alguno, prefiero mencionar solo a quien luchó codo con codo conmigo en todo este proceso, Sgomez (Santiago Gómez Seoane) responsable de desarrollo en Velneo V7.

Usabilidad Desarrollo

Vinculación Link

Los vínculos constituyen una parte importante del hipertexto y podemos dividirlos en 3 tipos principales:

De navegación.

Aquellos vínculos que te permiten moverte por las páginas de una web, botones de menú principal, vínculos de páginas secundarias etc…

De contenido de la pagina.

Aquellos vínculos que te llevan a más contenido de la página, suelen ser texto subrayado o img (más info).

Listas de referencia externa.

Son listas que Ayudan el usuario a encontrar lo que quiere si la página no es la adecuada.

Reglas básica de como debería ser un vínculo.

Páginas enlazadas cortas.

Las páginas enlazadas desde un vínculo no deberían ser muy largas, porque como en una revista impresa, estas páginas son un sitio donde descansar la vista mientras examinas un artículo.

Ejemplo:
página enlazada corta

No usar “Haga clic aquí”.

Evitar enlazar un vínculo con el texto “Haga clic aquí” utilizado como hipertexto.
La razón es que sólo los usuarios que usan los ratones harán clic, mientras que los discapacitados que tengan dispositivos especiales no harán clic.
Otra razón que las palabras “Haga clic aquí” no aportan mucha información, como tal no hay que aplicarlas como elemento de diseño.

Ejemplo:
Incorrecto > Para saber más sobre Namron, haga clic aquí
Correcto > Tenemos más información sobre Namron

Un link de hipertexto no debe contener más de 4 palabras

Dato que debería tener sólo 4 palabras*, se aconseja añadir texto sin ancla que explique el vínculo.

Ejemplo:
Incorrecto >Tenemos más información sobre Namron
Correcto > Tenemos más información sobre Namron

*Este punto es muy debatido en usabilidad, esa es la versión de Jacob Nielsen, pero sobre la “longitud” de un vínculo y el “número de palabras” hay diversas opiniones. Desde mi punto de vista, lo que dice Nielsen tiene sentido, pero hay que añadir siempre, un poco de sentido común dependiendo del caso específico.

Diferenciar los vínculos iguales.

Si los vínculos con ancla se parecen, hay que diferenciarlos con textos descriptivos.
De esa forma el usuario, antes de acceder, ya sabrá previamente lo que va a encontrar.

Ejemplo:
Para ir a la página principal > …podemos verlo en la página de inicio de Jakob Nielsen
Para ir a la biografía > Jakob Nielsen es una de las personas más respetadas en el ámbito mundial sobre usabilidad

La costumbre del Title.

Una buena costumbre a la hora de maquetar código html para crear un vínculo, es describir correctamente el comando “title” para denominar nuestro vínculo.

Ejemplo:
<a href=”http://namron.es/2009/11/22/usabilidad-como-crear-un-enlace” title=”Como crear un enlace”>Este artículo</a>
Con este código si pasamos el cursor encima del vínculo, transcurrido un segundo, nos aparecerá “Como crear un enlace” indicando dónde enlaza, podéis probarlo: Este artículo

Colorear los vínculos

Azul aquellos vínculos que el usuario nunca ha visto
Morado o rojo los vínculos que un usuario ha visto antes.

Ejemplo:
Vínculo nunca visto > Vínculo
Vínculo ya visto > Vínculo

* Jacob Nielsen aconseja no utilizar colores no estándar, pero está claro que desde que Nielsen dijo eso, los tiempo evolucionaron y las web cada vez son más variadas. Así aconsejo más que utilizar estos colores, intentar mantener una coherencia: si en vuestra web en la “pagina de inicio” los enlaces son de color naranja (cuando no están visitados) y de color verde (cuando están visitados), mantener esta gramática en todas la páginas de vuestra web, para facilitar el aprendizaje a los usuarios.

Utilizar la misma URL

Es un fallo bastante común, hago una web de contenido y hago una vez un vínculo a una pagina con una URL, después hago otro vínculo que enlaza a la misma página con URL diferente. Por ese pequeño fallo, el enlace nos aparecerá como (no visitado, color azul por ejemplo) cuando seguramente ya lo hemos visitado anteriormente.

Ejemplo:
<a href=”http://www.namron.es/”> o <a href=”http://namron.es/”> enlaza a la misma página, pero por el simple echo de estar escrito de formas diferentes, los lee como dos vínculos distintos.
Prueba 1
Prueba 2

Vínculos externos

• Si hacemos un vínculo externo asegurarnos que la calidad de la página valga la pena para salir de nuestra web.
• Asegurarnos de no vincular páginas temporales.
• No utilizar en código html target=”blank”, se ha estudiado que hacer que al pinchar en un vínculo se abra otra ventana o pestaña, resulta incómodo a la hora de volver atrás, porque es más simple volver atrás si lo carga en la misma ventana.

Vínculos internos (o entrantes)

Es cuando otro sitio enlaza al tuyo, esa es una de las mejores formas para generar tráfico en tu web.
Una de las formas para provocar que tu web sea enlazada es no creando páginas temporales para que se puedan enlazar.
Reallizar contenidos de calidad, para que las personas te utilicen como referencia.
Otra forma es especializarse en un tema, así mucha gente hará referencia a tus páginas

Vínculos publicitarios

Caso especial de vinculo entrantes.
Se aconseja crear un vínculo con páginas que sigan el mensaje del anuncio en vez de crear vínculos directos con su página de inicio.
Los estudios de publicidad web han descubierto que entre el 20% y el 30% de los usuarios web que hacen clic en un banner y comprueban que están conectados con una página corporativa de inicio, hacen clic en el botón Atrás.

P.D.
Es una buena norma, utilizar las cosas que funcionan a la hora de generar vínculos, más es un estándar mejor es…

Se vemos que en muchas web ponen para acceder a más informaciones de esa forma “más info” o “saber más”, ¿por qué tenemos que re-inventar la rueda y llamarlo “descubre más”? utilizar lo que ya la gente conoce es una gran ventaja.

Usabilidad

En primer lugar, quiero aclarar que el título está hecho para provocar un poco. Yo, personalmente, no tengo nada en contra de las betas, suelo utilizarlas y trabajar con ellas. Lo único que quiero decir con este artículo es que debemos valorar bien los riesgos que tienen a la hora de implementarlas en los clientes.

Unos de mis últimos descubrimientos en la Usabilidad es, el consejo de no utilizar las beta.

Se aconseja esperar un mínimo de un año tras la salida de la versión oficial de un producto.

El porqué es muy simple y lógico:

• 1º Hay que pensar que la tecnología beta es muy inestable, puede aportar más problemas que beneficios.
• 2º La tecnología beta, normalmente no es accesible para los usuarios finales hasta que deja de ser beta, por tanto después de la salida oficial. Aún así pasará un mínimo de un año hasta que muchos usuarios la conozcan y la tengan disponible.
• 3º Esperar un año después de que salió la versión oficial es una buena estrategia, porque después de la salida oficial se siguen encontrando errores y trabajando en mejoras.
• 4º Esperar un tiempo desde la versión oficial es también una buena forma para aprovechar y formarse en la nueva tecnología y no implementar algo que no sabemos utilizar bien.

Para entenderlo mejor: hay que pensar que cada semana sólo un 2% aprox. de los usuarios se actualiza a lo último. Así que, de acuerdo con las estadísticas se tardará un mínimo de un año para que más del 80% de los usuarios tengan la nueva tecnología instalada. Éste es el gran motivo por el cual tomarse con calma la salida de una nueva versión.

Está claro que todo eso no vale en caso de que seas el promotor de la nueva tecnología. En ese caso, tendrás que utilizarla desde la fase beta, pero teniendo particular cuidado en facilitar la accesibilidad a personas que no tienen los mismos avances.

Usabilidad Beta

La tecnología debería ser tan sencilla como la caja que la contiene.

Creemos que la tecnología puede ser muy avanzada y sencilla al mismo tiempo.

Debe ser fácil de utilizar y diseñada para todos. La sencillez debe ser su objetivo principal.

Para Philips lo es. Tiene sentido.

Reflexiones:
Esta publicidad me encanta. En pocas palabras explica la importancia de lo usable para una empresa importante como Philips.

Usabilidad Philips

Hablando con el propietario

Cuando conocí a Tomás el propietario de la tienda Climalis.
Unos de los aspectos que más me llamo la atención es su filosofía de venta, caracterizada por un gran factor humano entre vendedor y cliente.

Los productos de esta tienda son eminentemente técnicos y por lo tanto necesitan de una ayuda especializada a la hora de su elección.

Su objetivo no es simplemente vender un producto de gran calidad, es también realizar la difícil tarea de consultor y acompañar el cliente en todos los pasos para la realización de la compra.

Hablando por teléfono, me comentaba que la tienda online no quería ser una web de comercio cualquiera, su finalidad es ser una exposición de productos, para que los clientes llamar para obtener asesoramiento sobre sus necesidades. La tienda busca tener productos que difícilmente el cliente encontrara en la calle, producto en su mayoría técnicos que de otra forma han de ser comprados a profesionales.

Importante también es el argumento del precio, se hacen descuentos a partir de 2 o 3 unidades.

Lo especial de los productos lo indican que la mayoría se fabrican por pedido y suelen tardar unos 15 días.

Target

El tipo de “target” es un cliente que le gustan las cosas bellas y exclusivas, que no tiene miedo a gastar para un producto verdaderamente bueno.

Revisando la web

Esta es la captura de la web actual, puede que desde que publico este articulo la web valla cambiando.

Empezando a estudiar la web en seguida noté algunos puntos flacos:

Problema 1

Los detalles de las imágenes tienen un malo acabado, de esa forma bajas la calidad global de la web, unas de las cosas que resalta estos defectos es el color de fondo de la web en contraste con los banners publicitarios y los contenidos.

Problema 2

Dentro de la cabecera está poco estructurado las opciones de compra y el cuadro de búsqueda

Problema 3

Poner informaciones de promociones de la web a modo gif animado es una desventaja porque parece un banner publicitario externo y además el gif en cuestión no teniendo espacio entre lineas y una fuente de tamaño tan grande dificulta la lectura del mensaje.

Problema 4

Los productos vienen presentados en la web con poco importancia, cuando son el elemento más importante, equivocación en la jerarquía visual, se da más importancia al precio que no al nombre del producto

Problema 5

Nos es aconsejable dar un mensaje de bienvenida repitiendo la ruta URL de la web, es demasiado redundante.

Problema 6

Quitando la imagen del centro no me trasmite ser una página de inicio, en una página de inicio, tienes que trasmitir a tus clientes, tus puntos fuerte, porque tiene que comprar en tu tienda, esa pagina no me trasmite nada de eso

Problema 7

El píe de página pasa por desaparecido y tiene algunas funciones importantes.

Solucionando los problemas

Esta es mi versión para la web.

Propuesta para corregir los puntos débil de la web:

Problema 1

• Dato que toda la web se estructura sobre la plataforma Magento, u intentado realizar los mínimos cambios posible en la estructura de la web.
• Simplemente le y puesto un fondo blanco con un pequeño degradado gris en la parte de arriba, de esa forma los contenidos que se cargan en la página, no parecen como algo pegado artificialmente y se integran de forma mejor.

Problema 2

• Maquetado de forma más simple las opciones de compra.
• Simplificado algún nombre de las etiquetas (de las opciones de compra), (el nombre elegido habrá que utilizarlo en toda la web, los nombres no deberían superar 4 palabras para ser fácil da localizar y memorizar, un ejemplo es “Mi lista de artículos de interés” que yo cambié por “Artículos de interés”).
• Realizado un cambio en la búsqueda, lo puse de la forma más optima, formulario izquierda y botón derecha.

Problema 3

• Quitado los banners que había y realicé algunos nuevos que se integran con el diseño de la web.

Problema 4

• Aumentado un poco el tamaño de las imágenes de los productos (120px | 120px).
• Creado capturas del producto que no pierdan fuerza a verlos pequeños.
• Realizado una jerarquía funcional para identificar de un simple vistazo los producto:
  “Nombre producto” en azul e tamaño grande,”Que es” en azul tamaño normal, “Precio” en gris tamaño mediano negrita, “Productor” en gris tamaño normal.
• Añadido un icono representativo por cada “función de compra” que aparece abajo del producto (añadir al carrito, Añadir a Comparar Prd., Añadir Art de Interés).

Problema 5

• Cambiado la imagen.
• Cambiado el mensaje, el mensaje debería representar en pocas lineas el porque las personas tienen que comprar en esta web.

Problema 6

• Puesto en el menú principal la opción “inicio”, porqué non todas las personas saben que pinchando en el logo de la empresa vuelves a la página de inicio.
• Marcado de forma evidente la opción activa del menú, para que se vea claramente donde estamos.
• Cambiado el tipo di letra del menú para una fuente más pequeña, así queda más fino y elegante, “nos es el tamaño de letra que facilita la lectura, es el contraste es su colocación”.
• Cambiado el tamaño de fuente del titular de la categoría “Nuevos Productos” por un tamaño más grande, tiene que verse con claridad el identificador de un bloque de contenido.

Problema 7

• Cambiado diseño del píe

Comparar propuestas

Usabilidad Consulta web