Wireframes en una época ágil

Arquitectura de Información, General

Hasta hace algún tiempo, defendía la idea de que era imprescindible crear wireframes para todos los proyectos. Hoy creo que la situación ha cambiado considerablemente.

No se trata de un cambio de opinión respecto del valor de la herramienta en sí misma, sino de una realidad diferente, de condiciones distintas en la industria.

Disponer de semanas o incluso meses para elaborar y documentar wireframes es costoso, requiere de dedicación y de tiempos que no siempre están disponibles. Se justifica cuando los equipos que diseñan y definen la arquitectura de información de un producto son distintos. Se debe comunicar de modo claro qué hacer, entregar instrucciones de cómo construir el sitio o aplicación. Esas instrucciones deben ser precisas, no deben dejar dudas. Este escenario es cada vez menos frecuente.

Cuando el equipo que diseña y el que implementa es el mismo, o son equipos que están muy comunicados, el valor de los wireframes se diluye. Adquiere más valor la comunicación directa.

Los wireframes son tanto una herramienta de comunicación de diseño, así como de política interna. Como herramienta de comunicación, son la representación de un momento de un proyecto. Su rol político tiene que ver con la necesidad de respaldar decisiones, de contar con definiciones que servirán de referencia para contratar la implementación o para controlar su desarrollo.

El problema es que un diseño nunca está cerrado. Se marcan hitos, se cierran ciclos, pero los proyectos no se detienen. Y en estos momentos, el tiempo tiene un valor enorme. Un producto puede perder una oportunidad vital por no salir en el momento adecuado.

¿Qué alternativas hay? Si no vamos a elaborar wireframes, es necesario documentar los aspectos centrales de la arquitectura de información o de las interacciones. Las alternativas son varias, por ejemplo, alguna o una combinación de las siguientes:

  • Bocetos de pantalla de baja resolución. Es decir, dibujos en papel sin mucho detalle de las estructuras principales.
  • Prototipos semifuncionales. Simulaciones interactivas que documentan páginas, flujos e interacciones.
  • Flujos de pantallas. Llamados de diversos modos, se trata de diagramas de pantallas dispuestos en un flujo, que funde un diagrama de interacción con wireframes de diferente resolución.

Estas son sólo las alternativas más comunes. El punto más importante, es que siempre será necesario marcar un hito en que las ideas de diseño se comunican y traspasan a un equipo de desarrolladores. Mientras más cercanos —y mayor confianza tengan— ambos equipos, se requerirá de menos detalle en la documentación.

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.

Principios de diseño GDS

Reino Unido: principios de diseño del gobierno digital

Diseño Centrado en el Usuario, Gobierno Digital

El trabajo que está realizando el Government Digital Service (GDS) del Reino Unido es notable en muchos niveles. No por nada los ojos del mundo miran hacia allá, incluso asesoran al equipo de EE.UU., el 18F.

En este momento me quiero detener en un punto, los principios de diseño del GDS.

Originalmente publicaron 7 principios de diseño:

  • Digital por defecto
  • Poner a los usuarios primero
  • Aprender del camino
  • Construir una red de confianza
  • Hacer a un lado las barreras
  • Crear un entorno que permita que los líderes tecnológicos florezcan
  • No lo hagas todo tú mismo (no puedes)

Estos fueron actualizados con 10 nuevos principios, más precisos y concretos:

  1. Comienza con las necesidades (del usuario, no del gobierno)
  2. Haz menos
  3. Diseña con datos
  4. Haz el trabajo duro para hacerlo simple
  5. Itera. Itera nuevamente.
  6. Esto es para todos
  7. Comprende el contexto
  8. Construye servicios digitales, no sitios web
  9. Sé consistente, no uniforme
  10. Haz las cosas abiertas: las hace mejores

Cada uno de los principios de diseño está detallado y complementado con artículos que los apoyan y dan sustento.

Lo importante de estos principios, en mi opinión, es que dan en el clavo. Plantean una mirada centrada en el usuario, sus necesidades y la convicción de que el gobierno debe proveer servicios simples, fáciles de usar y para todos.

Por otro lado, promueve el que las instituciones públicas se dediquen a su negocio, entregando servicios en lugar de redundar con sitios web que replican esfuerzos.

Otro aspecto notable, es asumir el espacio para el error: iterar, iterar, fallar temprano, evitando el gasto de grandes proyectos fallidos.

Lo mejor de todo esto, es ver que quien ha desarrollado estos principios, es una unidad con la capacidad y autoridad de aplicarlos.

(foto: Ben Terrett)

Un Convenio Marco para la Innovación Digital

Gobierno Digital

Me encuentro con este artículo en Civic Innovations, GovTech is Not Broken, que me ha parecido muy interesante y creo que tiene varios puntos que vale considerar.

(…) while the procurement process for technology may not work well for governments or prospective vendors (particularly smaller, younger companies), it is not broken.

It works exactly as it was designed to work.

El punto central es que los procesos de compra en el sector público funcionan bien para compras tradicionales y grandes proveedores. Pero para compras no tradicionales y proveedores pequeños, la situación es muy distinta.

Para acercarlo a la realidad local, les cuento un poco de mi experiencia. Desde hace más de 12 años que mi foco ha sido trabajar en lo que podemos resumir como Diseño de Experiencia de Usuario para gobierno. Usabilidad, arquitectura de información, estrategia digital, procesos de innovación, entre otros temas. Siempre desde el mundo privado. Al inicio como consultor independiente, más tarde desde Amable. Me ha tocado ser testigo de muchos cambios y de la consolidación de estos temas.

Sin embargo, dado que todo esto se trata de disciplinas que buscan introducir herramientas de diseño e innovación en un mundo tradicionalmente conducido por la ingeniería de software, el proceso de convencimiento y luego los mecanismos de compra, son complejos. Más aún cuando eres parte de una empresa relativamente pequeña.

Actualmente las cosas son así: los grandes proyectos de innovación digital en el sector público son conducidos y ejecutados desde la tecnología, no desde la innovación y el diseño. Y sabemos que los ingenieros resuelven requerimientos, no necesidades de usuarios.

En Chile, los mecanismos de compras públicas disponibles son las licitaciones y convenios marco. Las licitaciones son complejas, y toman tiempo y recursos a todas las partes. Y tienen poca flexibilidad. Los convenios marco facilitan muchas cosas en el proceso de compra. Claro, cuando hay uno que cubre tu área de trabajo.

Hasta hace un mes, se encontraba vigente un convenio marco que cubría al menos parte de estos temas, pero su período terminó. Lamentablemente, el nuevo convenio que debía absorber parte de esa demanda, sólo se pensó desde el mundo del software.

De este modo, la situación nuevamente queda a merced de las licitaciones.

El problema, finalmente es éste: ¿Cómo se compran procesos de innovación digital en el sector público? La necesidad de un convenio marco que cubra innovación en el sentido más amplio —investigación, experimentación y diseño—, se hace evidente. Los mecanismos de financiamiento actualmente disponibles, como GIP, aunque ayudan, no son suficientes por el alcance y su formulación.

Afortunadamente hay algunos pocos espacios en el gobierno, donde la experimentación y la innovación digital han ganado espacio: Modernización y Gobierno Digital en SEGPRES y el Laboratorio de Gobierno. Es de esperar que sean ellos quienes puedan impulsar un marco de compras que faciliten la innovación en el Estado.

Así que desde acá, va una petición para SEGPRES y el Laboratorio de Gobierno: ¡un convenio marco para la innovación digital!

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.

 

Retomando «el factor humano»

General

Durante varios años publiqué «el factor humano» —ver el factor humano en archive.org—, mi blog personal sobre diseño centrado en el usuario, hasta que el tiempo se hizo escaso, la frecuencia de publicación fue cada vez menor y finalmente cayó en el abandono.

Desde hace algún tiempo extraño el ejercicio de mantener un blog y finalmente he decidido retomarlo.

Este será un espacio en el que escriba sobre Experiencia de Usuario (UX) y algunas disciplinas asociadas: Arquitectura de Información, Diseño de Interacción, Usabilidad, a partir de 15 años de experiencia práctica. Ocasionalmente tendré digresiones y hablaré acerca de otros intereses, como el uso de la bicicleta para una experiencia urbana centrada en las personas y a escala humana. Pero creo que en el fondo, no son temas demasiado diferentes.

Podrán ver en el archivo que he recuperado y republicado algunos de los artículos del antiguo blog. Sólo he traído aquéllos que me parecían de interés, por lo curioso, anecdótico o porque me parecen interesantes. Algunos ejemplos:

Bienvenidos a este espacio, espero que nos leamos seguido.

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.

Diseño de Formularios para el Web

Diseño de Interfaces, Usabilidad

Este era un libro que venía esperando desde hace ya tiempo, y apenas estuvo disponible compré la versión electrónica. Se trata de Web Form Design: Filling In the Blanks, de Luke Wroblewski. La calidad del libro cubre las expectativas, pero lo que me parece particularmente notable es la apuesta de la casa de publicación de Louis RosenfeldRosenfeld Media: el libro fue publicado en formato papel y en digital. Pero la versión digital no es cualquiera, es una versión especialmente preparada para ser leída en pantalla. Otro aspecto destacable, es que todas las ilustraciones y capturas de pantalla del libro están disponibles vía Flickr.

Hechas ya las notas respectivas, no me queda sino invitarlos a leer Web Form Design. Los formularios electrónicos del mundo te lo agradecerán.

Modelos Mentales, Proyectores y Candidatos Presidenciales

Diseño de Interacción

Hace un par de semanas fui a un seminario sobre Modernización del Estado y Democracia Digital, en el que participaron un par de tempranos pre-candidatos presidenciales (digo, si consideramos que falta más de un año y medio para las elecciones presidenciales en Chile). Todo esto es más bien materia del blog de e-Gobierno de Amable (que en gran medida es responsable del estado de abandono de este blog), pero lo que me llamó la atención fue un detalle peculiar, que sí tiene que ver con interfaces. La anécdota se las cuento ahora.

La apertura del seminario estuvo a cargo de uno de los precandidatos, Sebastián Piñera, quien utilizó un presentación en PowerPoint para apoyar su discurso. Tras de él, un proyector dibujaba las diapositivas en un enorme telón. El personaje en cuestión tenía un control remoto en su mano, que tenía como objetivo manejar el paso de las diapositivas. Aquí viene lo interesante: un problema de modelos mentales.

pinera

El pre-candidato presidencial Piñera en el momento en que intenta resolver su conflicto con el control remoto.

El señor Piñera para cambiar de página apuntaba el control remoto al telón, en lugar del portátil que contenía la presentación. Evidentemente la lógica es: quiero controlar lo que pasa en la proyección, por lo tanto apunto a donde está la proyección. El problema está en que el dispositivo no funciona de esa manera, lo que nos permite mirar el problema desde dos perspectivas:

  1. El conflicto entre el modelo mental que el usuario tenía en su cabeza y la forma en que el objeto funciona
  2. Las expectativas que uno pudiera tener de un personaje tan visible, que se vende como moderno y digital y sus aptitudes reales en el mundo digital.

El juicio de valor se los dejo a ustedes.