Archivo de Categoría «Experiencia de Usuario»

Breve reseña del concepto Experiencia de Usuario

Arquitectura de Información, Diseño de Interacción, Diseño de Interfaces, Experiencia de Usuario, Usabilidad

Comencemos por lo primero: ¿qué es Experiencia de Usuario? Aunque se puede definir desde diferentes perspectivas, podemos decir que se trata de un enfoque en el diseño de productos —en gran medida digitales, aunque no restringido a ellos— que se basa en la investigación de las necesidades y comportamiento de los usuarios para crear productos que, a la vez de ser funcionales, generan satisfacción en sus usuarios.

El concepto de Experiencia de Usuario —o User Experience, en inglés—, es relativamente nuevo. Digo relativamente, porque su uso extendido se observa recién desde los últimos 10 años.

El término, sin embargo, tiene una historia más extensa. Ya a mediados de los ’90 Donald Norman, mencionaba la «Experiencia de Usuario» y la describía como la forma en que

(…) cover some of the critical aspects of human interface research and application.

cubrimos algunas de los aspectos críticos de la investigación y aplicación de la interfaz humana.

What You See, Some of What’s in the Future, And How We Go About Doing It, Don Norman, Jim Miller, Austin Henderson

Esto como parte de los debates de CHI ’95 y en relación a su trabajo en Apple.

Otro hito relevante es la publicación en 2002 de «The elements of user experience» —Los elementos de la experiencia de usuario—, de Jesse James Garrett, que ordena la serie de disciplinas que se relacionan con la experiencia de usuario y lo visualiza en un conocido diagrama (PDF).

elements-of-user-experience

Pero no fue sino en 2005 cuando el concepto de User Experience comienza a tomar vuelo por sí mismo. El contexto era el rebote luego del desastre de las «.com» y la emergencia de la llamada «Web 2.0».

De hecho, en 2005 Garrett acuña el concepto de «Ajax», parte central de la web 2.0 y Adaptive Path —de la que Garrett es co-fundador— organiza la primera UX Week. De ahí en adelante, la UX fue mainstream.

IMG_1312

UX week de 2005, foto © Jared Spool

Quizá la señal más potente de lo que el concepto UX traía a la industria, fue el reconocimiento de la Usability Professionals Association —UPA—, una de las organizaciones profesionales con un perfil más académico, que en 2012, luego de una extensa y compleja discusión extensa, cambia su nombre a User Experience Professionals Association, UXPA.

Esto fue polémico y causó la irritación de las otras asociaciones y disciplinas profesionales, que acusaron a la UXPA de oportunismo, de monopolizar un concepto que incluía también a los profesionales de la Arquitectura de Información o el Diseño de Interacción.

Hubo reacciones indignadas de notables miembros de la comunidad, como Louis Rosenfeld, con su respuesta a la «Carta abierta a la comunidad de Experiencia de Usuario», con que Rich Gunther, Presidente de UPA a la fecha, anunciaba el cambio a UXPA.

Pero el concepto continuó extendiéndose, al punto que hoy es un concepto establecido y parte de la descripción laboral de muchos profesionales y equipos.

Al día de hoy, ya es un nombre establecido, difundido y, hasta cierto punto, comprendido por practicantes y clientes.

La pregunta de rigor es: ¿por qué «User Experience» se impuso por sobre las etiquetas previamente existentes? Creo que son dos las razones principales:

  • La facilidad de comprender un proceso más completo, en el que convergen diferentes disciplinas, con un concepto unificador;
  • Desde una perspectiva comercial, la facilidad de comunicar un concepto claro, con resultados concretos.

Un proceso unificado

Hasta antes de asimilar masivamente el concepto de UX, hablábamos de usabilidad, arquitectura de información, diseño de interacción, diseño de interfaces, diseño visual, etc. Si bien existen diferencias entre las diferentes disciplinas, el tener una visión unificada del resultado, y una cierta visión sobre el proceso, tiene ventajas. Ha contribuido a entender que cada disciplina aporta al resultado, y que el resultado es mucho más que sólo la suma de las disciplinas.

Un término fácil de comunicar

Hasta antes de que se acuñara y se asimilara la UX como concepto, abundaban los nombres para describir procesos y resultados similares. Pero la confusión para los clientes era grande. Y el esfuerzo para intentar explicar lo que proponías a un cliente, era mayor.

De hecho, las etiquetas para las descripciones laborales reflejaban esa confusión: podías ser un Arquitecto de Información, Experto en Usabilidad o Diseñador de Interacciones, pero en la práctica hacías lo mismo, o cosas muy similares. O las hacías todas en diferentes momentos.

En suma, el concepto de Experiencia de Usuario ha venido a resolver un clásico problema de significante y significado, en el que teníamos un contenido —las disciplinas, métodos y procesos—, pero no había un denominador que facilitara su comunicación.

UX ha facilitado eso. Claro, ahora surgen otros problemas, como la de-significación del concepto —ya se quejaba de ello Norman en 2007 en una entrevista con Peter Merholz— o la trivialización de la práctica, pero esas son otras batallas.

API de Notificaciones, Facebook y experiencia de usuario

Diseño de Interacción, Experiencia de Usuario

HTML5 pone a disposición una serie de API que permiten mejorar la experiencia de usuario, agregando funcionalidades que hasta hace poco sólo estaban disponibles para aplicaciones nativas en móviles.

Geolocalización y notificaciones son ejemplos de ellas. Si embargo, requieren de aprobación del usuario para hacerlas disponibles a cada sitio. Eso está bien, es protección de la privacidad, nadie quiere que un sitio registre indiscriminadamente su posición sin una autorización de por medio.

En el caso de las notificaciones, para algunos sitios web es un muy buen complemento contar con la posibilidad de agregar avisos nativos del sistema. Si usas Gmail, probablemente has autorizado el uso de notificaciones de escritorio, con lo que ya te has familiarizado con la funcionalidad de esta API.

Todo esto, para comentar un muy buen ejemplo con el que me crucé hoy, de manejo de las preferencias de notificaciones. La cosa va así: para poder mostrar notificaciones, un sitio debe pedir autorización al usuario. Este proceso lo maneja el navegador, junto con las preferencias para revocar o aprobar el permiso. Como cada navegador lo maneja de modo diferente, es complejo soportar estos flujos.

Pero Facebook lo maneja de modo muy interesante.

Manejo de preferencias de notificaciones

En primer lugar, si rechazas que el sitio utilice notificaciones, Facebook muestra un mensaje justo bajo el candado de la URL —esto al menos en Chrome—, informando que puedes modificar las preferencias de uso de notificaciones desde este lugar.

preferencias-notificaciones

Si pinchas el candado asociado a la barra de ubicación, el navegador despliega las preferencias de privacidad, entre las cuales se encuentran los permisos, uno de ellos corresponde a Notificaciones.

En suma, si vas a usar las API de notificaciones o de geolocalización, cuida estos detalles, que son una parte importante de la experiencia de usuario.

Diseño de Experiencia de Usuario en entornos ágiles o lean

Diseño Centrado en el Usuario, Experiencia de Usuario

Las metodologías ágiles y lean responden a una serie de necesidades del desarrollo de productos digitales, pero principalmente a tiempos breves para el diseño, producción y lanzamiento. Simplificando al máximo, tanto en lean como en agile se busca minimizar el riesgo y salir rápidamente con un producto.

Eso me parece perfecto. Sin embargo, esto se hace normalmente a expensas de una buena investigación de usuarios y de un foco excesivo en el desarrollo de software —en el caso de agile— o en la gestión de un producto —en el caso de lean.

Respecto a agile, En Nielsen & Norman lo plantean como:

Agile teams are more proficient in executing the development process, but the compressed timescale forces some to abandon user research and degrade the resulting user experience

Los equipos ágiles son más productivos ejecutando el proceso de desarrollo, pero las escalas de tiempo comprimidas fuerzan a algunos a abandonar la investigación de usuarios y degradan la experiencia de usuario resultante

Doing UX in an Agile World: Case Study Findings

Ese mismo foco en el desarrollo, hace que los problemas de ingeniería se sobredimensionen en relación a los demás. En lugar de investigar y desarrollar estrategias basadas en el conocimiento de los usuarios, se escribe software.

Lo curioso es que lean, que tiene el eje desplazado hacia el diseño y gestión de productos, también tiende a cometer el mismo error. La lógica de comenzar construyendo antes de investigar, tampoco permite definir una estrategia que permita guiar un proceso de investigación, evaluación y aprendizaje. En Cooper comentan acerca de esto así:

Framing the problem before you start solving it is not only wise, but major opportunities for innovation often arise before anyone proposes a design solution.

Definir el problema antes de comenzar a resolverlo no sólo es sabio, sino que grandes oportunidades de innovación surgen frecuentemente antes de que alguien proponga el diseño de una solución.

More, better, faster: UX design for startups

Por lo mismo, e independientemente de si trata de un entorno agile o lean, realizar investigación de usuarios y definir una estrategia —o al menos hipótesis informadas— al inicio, es lo más razonable. En Cooper proponen un modelo que cambia el «Build – meassure – learn» de lean, por «Learn – build – meassure», que busca incorporar más espacio para la investigación. Esto cambia el modelo y contribuye a diseñar y construir de un modo más informado.

modelo-lean-cooper

En cualquier caso, creo que además de integrar tanto perfiles, como actividades asociadas al diseño de la  experiencia de usuario, se debe comenzar investigando y trabajando con usuarios. Si no, el riesgo de no acertar con las expectativas de tu cliente/usuario será mayor.

Personas y empatía con los usuarios

Diseño Centrado en el Usuario, Experiencia de Usuario

El uso de personas como herramienta en el diseño de interacción y el diseño de experiencia de usuario no es algo nuevo. Alan Cooper lo describió en 1998 en su clásico «The inmates are running the asylum» y en adelante los detalles sobre su uso y aplicación abundan.

Personalmente he usado personas en muchas oportunidades, pero hace poco una modificación en la forma de presentarlas generó un importante impacto en un proyecto.

Todo partió con la integración de técnicas ágiles de definición de personas —eso será otra historia. El trabajo de definición fue gradual, en la medida que obteníamos más información sobre nuestros usuarios, a partir de la investigación de diversas fuentes.

El cambio ocurrió en el momento en que pensaba en cómo producir un impacto mayor con las personas en las que estábamos trabajando. ¿Cómo hacer que el equipo técnico se interiorizara realmente con este grupo de usuarios representativos, y lograran empatizar con sus necesidades?

¿Por qué no invitarlos a la presentación?, pensé.

Y comencé a bocetar algunas ideas de cómo hacerlo. La idea fue incluir una imagen representativa para cada una de las personas definidas, con su historia y necesidades, en un formato impreso que pudiera ser plegado y ubicado en la mesa de reunión y después en los escritorios.

personas-02

Adaptamos el formato que teníamos para las personas y el resultado es el de la foto. Durante la presentación con todo el equipo, en el momento preciso, sacamos las piezas y las distribuimos en la mesa. El resultado fue notable: los participantes comenzaron a mirarlos, revisarlos y a familiarizarse con ellos. Los nombres y características quedaron grabados y permitió que se comenzara a hablar de nuestras personas como los destinatarios reales del proyecto.

personas-03

El aprendizaje detrás de esto es simple, pero potente: contamos con muchas herramientas para describir nuestro trabajo, pero a veces es necesario pensar en cómo socializarlo, cómo acercarlo a los demás para que tengan un impacto real.

La documentación en el diseño de experiencias de usuario

Arquitectura de Información, Experiencia de Usuario

Hace unos días escribí acerca de los wireframes y la necesidad de reducir la documentación en los proyectos de UX. Y aunque me concentré en hablar de los wireframes, no se trata de condenarlos al olvido ni de negar su utilidad. De lo que se trata es de optimizar los procesos de trabajo y mejorar la comunicación entre equipos.

El problema es el siguiente: los wireframes documentan un sistema interactivo o de información en un momento determinado. E incluso en un estado determinado.

Un momento porque los wireframes son la foto de una etapa en el desarrollo del sistema. Pero sabemos que los sistemas son dinámicos y evolucionan permanentemente. La documentación que los describe, del mismo modo,  debe ser actualizada o queda obsoleta. Esto es un esfuerzo que, con el dinamismo que se requiere cada vez más, se hace difícil.

Además, los wireframes sólo son capaces de representar un estado de una interfaz a la vez. Pero también sabemos que los sitios y aplicaciones tienen muchos estados diferentes.

Así, los wireframes no son capaces de evolucionar junto a los sistemas que documentan, ni son capaces de representar todos sus estados. Por lo mismo, no siempre son efectivos en su resultado —documentar y comunicar un sistema— o eficientes en su ejecución —considerando el tiempo y esfuerzo que requieren.

Otro aspecto del problema, es que en un proyecto interactúan diferentes equipos, con objetivos y necesidades particulares. La comunicación entre ellos y la forma en que ésta se produce, varían según la relación que tengan los equipos y la naturaleza de los proyectos.

¿Cuáles son las alternativas?

Las opciones son varias, pero existen diferentes escenarios:

  • Escenario 1: si un equipo incluye tanto a investigadores, como a diseñadores de experiencia y a desarrolladores —el escenario ideal—, lo mejor es realizar bocetos rápidos, prototipar, evaluar con usuarios y pasar rápido a desarrollar. Y evaluar con usuarios nuevamente.
  • Escenario 2: si los equipos de diseño de experiencia de usuario (UX) y desarrollo son áreas distintas de la organización, se deberá documentar más. El equipo de desarrollo necesita precisiones; el de UX necesita respaldos de lo que ha definido. Aún así, se pueden documentar muchos aspectos en prototipos complementados con flujos de interacción, y sólo cuando sea necesario, wireframes. Pero el propósito será pasar lo más rápidamente posible a desarrollo.
  • Escenario 3: si el equipo de desarrollo y el de UX corresponden a empresas diferentes colaborando en un mismo proyecto, se hará necesaria documentación más detallada. En este caso, los prototipos documentados y los wireframes serán centrales. Deberán sustentar las definiciones de UX cuando el equipo no esté presente. Y tendrán que ser precisos para facilitar el desarrollo.

Por sobre todas estas consideraciones y escenarios, debemos tener presente que el tiempo disponible para los proyectos es reducido y en muchos casos la competencia y la carrera por el time-to-market son críticos. Con lo cual debemos calibrar todos los aspectos para asegurar un diseño de UX y un desarrollo fluido.

Otra forma de reducir tiempos, costos y esfuerzos, es pasar rápidamente desde el prototipado al desarrollo. En lo posible, prototipar en herramientas lo más cercanas al lenguaje final: HTML, CSS, JavaScript en el caso del web. La idea de generar prototipos detallados, con herramientas especializadas (como Axure, InVision, etc.), que luego deberán ser reconstruidos durante el desarrollo, parece superflua en la mayoría de los casos. Gastar recursos en aprender los trucos de las herramientas de prototipado, que luego serán desechados, no parece una forma eficiente de avanzar.

En conclusión, tenemos muchas herramientas de definición y comunicación a nuestra disposición, sólo debemos saber cuándo usarlas para beneficio de cada proyecto.

El difícil camino de la transformación digital del gobierno

Experiencia de Usuario, Gobierno Digital

Hace tiempo vengo siguiendo —como muchos— el trabajo del Reino Unido en la innovación de los servicios de gobierno y su proceso de transformación digital. Pero desde hace unos días, lo que desde el exterior se ve como un proceso impecable, digno de la madurez británica, ha mostrado algunos matices interesantes y con los que es más fácil relacionarse. Van algunas ideas y preguntas que surgen a partir de esto.

¿Cómo puede enfrentar el Estado la innovación pública de modo efectivo?

Uno de los espacios de innovación del gobierno es la transformación digital, entendida como la forma en que los gobiernos se modernizan, para proveer servicios a los ciudadanos, de modos más efectivos y eficientes.

Esta transformación no sólo tiene que ver con la forma en que se desarrollan los servicios digitales, sino que, fundamentalmente, cómo se generan condiciones para que sea permanente y real.

En Chile hay algunas iniciativas que promueven la innovación en ciertas áreas del Estado, pero se trata de buenas intenciones, aisladas y sin institucionalidad o mecanismos para la instalación permanente. Me refiero a concursos y premios a proyectos específicos de innovación. Esto está bien, pero es más importante que estas iniciativas puedan generar espacios permanentes.

Como un ejemplo de esto, ¿por qué proyectos innovadores como el Laboratorio de Gobierno y otros se instalan en Corfo? Porque tienen más autonomía y libertad de acción, dadas las características de Corfo. En otros espacios del Estado no existen esas condiciones.

Por otro lado, ¿por qué el importante trabajo que ha realizado el equipo de Modernización y Gobierno Digital no es replicado con más fuerza en todo el Estado?

¿Qué hacer para que la transformación digital del gobierno sea real?

Permanentemente leemos y conocemos del caso exitoso del Government Digital Service (GDS) del Reino Unido, pero aparentemente los resultados obtenidos no están garantizados y tampoco han sido exentos de costos. La renuncia de Mike Bracken a la dirección del GDS luego de 4 años, junto con otros miembros del equipo así lo evidencia. En sus palabras,

We need to say, as public administrators, that we need to work differently and more collaboratively in a system that is not set up to do that. Whitehall was described to me when I started as a warring band of tribal bureaucrats held together by a common pension scheme, and there is something in that.
http://www.computerweekly.com/news/4500251662/Interview-Government-digital-chief-Mike-Bracken-why-I-quit

En parte, las palabras de Bracken apuntan a la dificultad de realizar cambios en el gobierno y de luchar contra los incentivos que apuntan al inmovilismo.

Una de las características del GDS —y otros servicios con un modelo similar, como el USDS—, es la posibilidad de incorporar la experimentación dentro de su proceso de trabajo, lo que permite probar diferentes ideas y avanzar con ellas si demuestran ser viables, o descartarlas tempranamente si no funcionan. Este espacio para la experimentación es fundamental para la innovación. De acuerdo al World Development Forum —WDF— en el artículo What is government’s role in sparking innovation?,

If failure is an unavoidable part of the innovation game, and if government is crucial for innovation, society must be more tolerant of “government failure.” But the reality is that when government fails, there is public outcry – and silence when it succeeds.
https://agenda.weforum.org/2015/04/what-is-governments-role-in-sparking-innovation/

El punto es claro: la innovación requiere experimentar. Y la experimentación requiere espacio para fallar. Para esto se requieren modelos de incentivos diferentes, mecanismos de financiamiento que no se limiten a ejercicios presupuestarios de ciclos anuales y estructuras de organización tolerantes y flexibles.

¿Qué estamos haciendo en Chile para lograr esto?

Hay compromisos declarados, pero no se ven avances en el corto plazo. El 21 de mayo de 2014, en la cuenta pública la presidenta anunciaba que “Debemos ir un paso más allá de la modernización y potenciar un Estado innovador”. Esta frase da respaldo a la creación del Laboratorio de Gobierno, iniciativa importante, pero la modernización del Estado va mucho mas allá de su alcance. Debe estar incrustada en todos los servicios, ser parte de la operación normal.

¿Qué podemos esperar? ¿Quién retomará el impulso modernizador que generó el instructivo presidencial de 2001? ¿Qué se necesita para replicar —y mejorar— iniciativas como las del GDS y el USDS?

créditos foto: GDS

Demanda y necesidad

Diseño Centrado en el Usuario, Experiencia de Usuario

Hay un episodio clásico de los Simpsons —Oh Brother, Where Art Thou?— en que Homero se entera de que tiene un medio hermano, y sucede que éste tiene una fábrica de autos. Su hermano lo pone a diseñar un automóvil para el americano promedio, qué mejor idea que poner a un usuario real a diseñar su vehículo ideal. Todo un equipo a disposición del usuario que diseña lo que quiere. Pero el problema es que los usuarios no saben lo que necesitan, o al menos no tienen las herramientas para sistematizar esas necesidades.

El resultado de ese ejercicio de diseño es un engendro que sólo podría salir de la cabeza de Homero. Porque es muy diferente diseñar con los usuarios, que los usuarios diseñando. Y es muy diferente un deseo de una necesidad.

Por ahora, detengámonos sobre esto último.

La demanda es algo que quiero o que creo que me gustaría, pero que no resuelve, necesariamente, una necesidad.

Una necesidad, es algo que debo lograr, un objetivo. La necesidad se expresa desde el resultado: lo que quiero conseguir.

Un servicio en línea, sea éste un sistema de información, una herramienta, o cualquier sistema interactivo —al menos entre personas y máquinas—, debe construirse en torno a las necesidades de los usuarios. Y eso sólo se consigue haciendo investigación de usuarios. Observando usuarios reales, entrevistando, revisando el uso.

Por eso, hay que repetir como mantra: no se puede diseñar sin conocer las necesidades reales de los usuarios.

Gestión de Proyectos Digitales y Desarrollo Continuo

Experiencia de Usuario, Gobierno Digital

A propósito de la reedición de el factor humano, he estado los últimos meses recuperando y reeditando contenido antiguo, armando un nuevo diseño y preparando un tema para el CMS prácticamente desde cero. Y siendo el tiempo un recurso escaso, es fácil perder la perspectiva y pretender tener una versión 100% lista para publicar. Esto hace que los hitos se aplacen y la fecha de lanzamiento se aleje.

Pues bien, paradójicamente, esto es uno de mis temas de trabajo en el último tiempo: la modernización de los procesos de gestión y desarrollo de proyectos web, pasando de proyectos caracterizados por hitos fijos, cerrados, a la concepción del desarrollo continuo y del producto mínimo viable, o MVP.

Actualmente, no es posible pensar en ciclos de definición y desarrollo de proyectos web que tarden muchos meses e incluso años antes de publicar una nueva versión del producto o servicio. La competencia no lo permite, y la demanda de los usuarios tampoco.

Pero esto no es sólo un tema que afecte a la implementación tecnológica, sino que también incluye a los tiempos requeridos para la investigación de usuarios, la definición de estrategias digitales y el diseño de la experiencia de usuario.

Es por esto que las soluciones que hasta ahora han procurado enfrentar esto, no siempre son satisfactorias: las metodologías ágiles, provenientes del mundo de la ingeniería de software, se enfocan en el desarrollo, y en ellas los procesos y roles vinculados a la experiencia de usuario son secundarios, subordinados a la visión de ingeniería.

Los procesos Lean, por otro lado, provienen del mundo start-up, y buscan comprobar rápidamente si un producto o servicio es viable, antes de invertir más en él. Lean UX busca cerrar la brecha, incorporando la experiencia de usuario como eje de la definición del producto. Sin embargo, se reduce mucho el espacio de investigación y el trabajo con usuarios suele estar enfocado en comprobar la viabilidad del producto y no su usabilidad.

En general, la necesidad de ciclos de desarrollo más breves es muy presente en el mundo privado, pero recientemente está siendo considerado en servicios pioneros del mundo público. Un ejemplo de esto es el Government Digital Service del Reino Unido —GDS—, que incorpora metodologías ágiles. Una publicación interesante sobre este tema lo vi esta semana en el sitio de Transport for London: Agile continuous delivery in the cloud – Part 1.

En Chile, en el sector público, la Unidad de Modernización y Gobierno Digital, utiliza metodología ágil y entiendo que el Laboratorio de Gobierno también. Pero claramente, son excepciones.

En fin, hay diferentes estrategias para enfrentar el desarrollo continuo, que permiten de una forma u otra, lanzar versiones parciales, pero funcionales de un producto, sin tener que esperar completar ciclos extensos. El desafío es integrarlos con una adecuada investigación de usuarios que permita definir estrategias digitales adecuadas y diseñar experiencias de usuario efectivas.

Dejo el tema abierto para seguirlo tratando en próximas publicaciones.

 

Una Pesadilla con la Mesa de Ayuda

Experiencia de Usuario

Hoy he tenido una experiencia de esas que te dejan al borde del colapso nervioso, con la plataforma de ayuda telefónica de un servicio público. La situación es típica: no podía recuperar la clave para acceder a los servicios del sitio y al pinchar el clásico “Olvidó su clave?” me aparecía una página de error. Los dejo para que se deleiten con el diálogo, transcrito lo más literalmente que pude:

Operadora:
Hola mi nombre es Daniela, en qué lo puedo ayudar
Yo:
necesito recuperar la clave de acceso al sitio, no puedo hacerlo desde el sitio
Operadora:
¿Intentó hacerlo desde el sitio?
Yo:
… sí, intenté hacerlo, la página de recuperar clave me muestra un error
Operadora:
entonces puede ser un problema de ruta o de cookies
Yo:
Eeeh… soy experto en web, sé que no es un problema de ruta o de cookies. Es un problema del sitio.
Operadora:
Sí, usted puede ser experto en web, pero yo conozco mucho el sitio. He estado hablando con varias personas durante la mañana y no han tenido problema para hacerlo.
Yo:
… Te explico que hice click en “olvidó su clave” en la portada y me aparece una página de error de Java, del servidor.
Operadora:
A ver, haga lo que yo le digo: haga click en “Regístrese aquí”, luego ingrese el RUT
Yo:
OK, lo voy a hacer …
Operadora:
¿Qué le aparece?
Yo:
Me aparece un mensaje “el cliente ya existe”, cosa que yo sabía, la cuenta está creada.
Operadora:
Entonces ahora haga click en “olvidó su clave”
Yo:
OK… ahora sí me aparece el formulario. Ingreso el RUT y me dice que me envió por email la clave. Pero insisto, desde la portada hago click en “olvidó su clave” y me aparece un error.
Operadora:
A ver… veamos…
Yo:
Anda a la portada y haz click en “olvidó su clave”…
Operadora:
Mmmm… sí, pero es que usted tiene que hacer click primero en “regístrese aquí” pa… (interrumpo)
Yo:
Daniela, dejémoslo hasta aquí, gracias.

error-recuperar-clave

Al hacer click en la portada del sitio a “Olvidó su clave?” me mostraba este error de servidor.

Si la alternativa para recuperar una clave perdida u olvidada es ésta, nos demuestra la importancia de diseñar correctamente este tipo de interfaces.

Pizarras Muro a Muro

Diseño de Interacción, Diseño de Interfaces, Experiencia de Usuario

Una de las cosas más útiles cuando uno está trabajando en equipo boceteando diagramas o realizando cualquier actividad de arquitectura de información o diseño de interacción, es una buena pizarra. Pero en la medida que las cosas se van complicando, y los diagramas crecen, las clásicas pizarras se hacen pequeñas. Por eso, desde hace tiempo que soñaba conpizarras gigantes, y eso es lo que armamos en la nueva oficina de Amable en Santiago. Son paneles de fibra de madera aglomerada de alta densidad con una cubierta lacada blanca, en dimensiones de 2,44 x 1,52 metros. Los invito a ver los resultados:

pizarra-01

Incluso una pizarra así de grande se hace pequeña a veces. Este es un panel completo adosado a la pared.

pizarra-02

Esta es una pizarra de dos paneles… y también está llena.

Además de lo simple, estos paneles son muy baratos, así que la única excusa para no armar algo así, es no tener suficiente espacio.