¿Existe el Diseño Centrado en el Usuario?

El Diseño Centrado en el Usuario (DCU) es un tema del que cada vez se habla más, pero que en la práctica parece ser más una declaración de buenas intenciones que un proceso definido, aplicable a la mayoría de proyectos de desarrollo.

This post is also available in English

La expresión “Diseño Centrado en el Usuario” (DCU, o UCD en inglés de User Centered Design) parece estar adquiriendo cada vez más popularidad, y no es de extrañar. ¿Quién va a oponerse a que el usuario, destinatario último del software, sea precisamente el centro del proceso de diseño? Pero rascando un poco bajo la superficie encontramos que no existe un consenso general sobre lo que entendemos precisamente como DCU.

Las definiciones más o menos formales como la de la Wikipedia o la de ISO 13407:1999 (no os voy a aburrir aquí con ellas) se refieren en términos muy generales a “filosofías de diseño”, “modelos”, “elementos que lo forman”,  “principios generales”, “recomendaciones”, … Todo eso está muy bien, pero no sirven en el momento de la verdad: cuando uno se enfrenta al desarrollo de una interfaz de usuario.

Proceso de DCU según ISO 13407El proceso de Diseño Centrado en el Usuario es, según la ISO 13407, algo tan genérico como esta figura.

¿Qué tenemos en la práctica?

En la práctica, la expresión DCU se refiere casi siempre a un conjunto de técnicas que se pueden aplicar a lo largo del ciclo de vida de una aplicación software, y que lo único que tienen en común es que, al menos en teoría, incluyen al usuario como principal protagonista. El número de esas técnicas puede ir desde seis (como en este artículo de Webcredible) a varias decenas (como en esta tabla interactiva de UsabilityNet). Entre esas técnicas suelen estar algunas tan dispares como los focus group, los tests con usuarios o el prototipado de interfaces.

Curiosamente, también se suelen incluir como técnicas de DCU algunas en las que no participan usuarios reales; por ejemplo, las evaluaciones heurísticas de usabilidad.

(more…)

“Haz fácil lo imposible”, el nuevo libro de Steve Krug

Una reseña sobre la nueva obra del autor de "No me hagas pensar", publicada en el blog de SQUaC.

Portada de 'Haz fácil lo imposible'En el blog de SQUaC hemos publicado una reseña de “Haz fácil lo imposible“, la discutible traducción (casi de manual de autoayuda) del título del libro “Rocket Surgery Made Easy“, la última obra de Steve Krug, autor también del popular libro de introducción a la usabilidad “No me hagas pensar” (“Don’t Make Me Think “).

A pesar de que el libro está en principio dirigido a personas no expertas en usabilidad que quieran incorporar técnicas de testeo con usuarios en sus desarrollos, la obra es muy recomendable también para cualquier profesional de la usabilidad; en mi opinión, su propuesta de dedicar periódicamente mañana al mes a las pruebas e involucrar a todo el equipo de desarrollo en ellas resulta más que interesante como un primer paso para integrar desarrollo de software y usabilidad, algo en lo que todavía hay mucho por hacer.

Las propuestas de Krug son muy pragmáticas; aboga, por ejemplo, por poner en común y centrarse únicamente en los problemas de usabilidad más graves detectados, y realizar las correcciones mínimas para corregirlos antes de la próxima ronda de pruebas.

Más sobre el libro “Haz fácil lo imposible” en el blog de SQUaC.

Lo que diseñadores y desarrolladores deberíamos aprender de Supernanny

Parecería que el popular programa de TV tiene poco que ver con el desarrollo de software y el diseño de interfaces... pero algo sí que podemos aprender de él (y no es que los desarrolladores seamos como niños).

Seguro que recuerdas Supernanny, ese programa de TV en el que una psicóloga aconsejaba a diferentes padres (habitualmente al borde de la desesperación) en cuanto a la educación de sus hijos.

Quizás te sorprenda, pero podemos extraer algunas lecciones de su modo de actuar aplicables al desarrollo de software. Y si no, veamos cuál es la estrategia de Supernanny:

  • Observar el funcionamiento actual, sin intervenir en él.
  • Anotar los problemas detectados y su posible solución.
  • Exponer y aplicar esas soluciones al caso real.
  • Comprobar la efectividad de las soluciones.

¿Creéis que Supernanny sería tan efectiva si, en vez de proceder así, esperara a que los padres acudieran a su despacho, le expusieran el problema, y ella les diera una solución sin ni siquiera conocer a sus hijos? Parece obvio que no.

Entonces ¿por qué no seguimos el mismo esquema en el desarrollo de software? Habitualmente esperamos que el cliente nos cuente sus problemas, y nosotros desarrollamos la solución, muchas veces sin conocer en entorno de trabajo ni a los usuarios.

La técnica equivalente a lo que hace Supernanny en el ámbito del Diseño Centrado en el Usuario (y en otras muchas disciplinas) suele ser conocida como estudio de campo“.

Y es que, si bien es cierto que no hay dos niños iguales, lo mismo ocurre con los usuarios y sus situaciones. Y sí, seguro que Supernanny nos ayudaría con muchos clientes. 🙂

Mis tropiezos con Google App Engine

¿Es Google App Engine una plataforma suficiente para desarrollar aplicaciones "serias"? ¿O son sus limitaciones demasiado restrictivas en algunos casos?

Logo 'roto' de Google App EngineHace bastante tiempo que tengo en mente una idea para desarrollar una aplicación web y, cuando me decidí por fin a implementarla, elegí Google App Engine, a pesar de que no conocía Python, el único lenguaje que soporta ahora mismo (aunque ha sido una buena excusa para aprender) y a pesar de algunas limitaciones propias de un servicio gratuito y en pruebas.

Al fin y al cabo, esos inconvenientes parecían quedar ampliamente superados por las ventajas de usar la misma infraestructura que usa Google para sus propias aplicaciones: robustez, existencia de un entorno de desarrollo, APIs de gestión de usuarios, de almacenamiento de datos, etc.

(more…)

METAeuFORiAS: Desarrollar software es como realizar una película

Tal como se explica en algunos artículos disponibles en la red (como este, este, o este) existen diversas similitudes entre los procesos de desarrollar un determinado software, y la realización de una película desde su concepción inicial. En esta entrada…

Tal como se explica en algunos artículos disponibles en la red (como este, este, o este) existen diversas similitudes entre los procesos de desarrollar un determinado software, y la realización de una película desde su concepción inicial. En esta entrada vamos a reunir esas analogías, así como descubrir algunas nuevas.

Rodaje grabando a un programador

 

[…] seguir leyendo en METAeuFORiAS (1421 palabras)

Programar y escribir para la web: no tan diferentes

Leo un artículo en el blog de Ricardo Galli titulado Tratar al código fuente como un ensayo que me ha vuelto a crear una conexión entre dos temas que en principio parecen poco relacionados pero de los que se puede…

Leo un artículo en el blog de Ricardo Galli titulado Tratar al código fuente como un ensayo que me ha vuelto a crear una conexión entre dos temas que en principio parecen poco relacionados pero de los que se puede extraer alguna enseñanza común; en este caso, la programación y la redacción de textos para la web.

Código fuenteRicardo habla de un libro (Beautiful Code) y, más concretamente, de un capítulo titulado como su artículo: Treating Code As an Essay. En él se señala la similitud entre el código fuente de un programa y un ensayo, en el sentido de que, si bien en ambos casos su propósito es lo fundamental (“¿de qué se trata?”; “¿qué hace?”), no debe descuidarse el estilo en que están escritos, ya que no sirven de nada si no pueden ser interpretados por seres humanos.

A continuación rescata algunas reglas generales para escribir código de calidad:

  • Brevedad: La brevedad es una virtud, definitivamente hay un coste de lectura para el ojo humano, el código debe eliminar la información redundante
  • Familiaridad: Las personas son más conservadoras de lo que pensamos. Las curvas de apredizaje elevadas creean estrés y reducen productividad. Un lenguaje no debe obligar a los progamadores a trabajar con conceptos nuevos y complejos. No ser demasiado innovador es también una ayuda para el “código bello”.
  • Simplicidad: Si un programa es complicado de entender no puede tener belleza.
  • Separar bloques: Separar los bloques lógicos en cada función, así se facilita la lectura más rápida y en “diagonal”.
  • etc.

Inmediatamente me han venido a la memoria las reglas que da Jakob Nielsen para escribir para la web; de hecho, algunos de los puntos son prácticamente idénticos: simplicidad, brevedad, lenguaje familiar, etc. Y es que, pensándolo un poco, las situaciones no son tan diferentes:

(more…)

Microsoft Access: cinco consejos para tus bases de datos

Después de desarrollar varias aplicaciones utilizando Microsoft Access, uno descubre que existen algunas prácticas y formas de trabajo que simplifican su desarrollo y el mantenimiento, sobre todo cuando la aplicación empieza a crecer más de lo que tenías previsto (cosa…

Después de desarrollar varias aplicaciones utilizando Microsoft Access, uno descubre que existen algunas prácticas y formas de trabajo que simplifican su desarrollo y el mantenimiento, sobre todo cuando la aplicación empieza a crecer más de lo que tenías previsto (cosa que suele pasar casi siempre).

Seguramente Access no es una base de datos que pueda soportar una gran aplicación con multitud de usuarios accediendo al mismo tiempo, que maneje una gran cantidad de datos, o con requisitos complejos de rendimiento o seguridad. Pero como herramienta que permite implementar una aplicación completa (desde las tablas de datos hasta interfaces de pantalla o informes impresos) para unos pocos usuarios de manera rápida, hay que reconocer que tiene pocos rivales. Los desarrollos con Access son tan rápidos que puede utilizarse como una herramienta de prototipado que ayude a definir claramente los requisitos de usuario antes de pasar a un sistema más potente.

1. Define bien las tablas y sus relaciones

Los desarrolladores conocen lo importante que es tener un buen modelo de datos en su aplicación. Y en Access, eso se convierte en la pantalla de Relaciones (dentro del menú Herramientas):

Pantalla de Relaciones de Microsoft Access

Es decir, define globalmente los campos de cada tabla y las relaciones entre tablas, para toda la aplicación, tal como son en la realidad (no como deberían ser). No definas tablas, campos y relaciones para necesidades puntuales que puedas tener en un formulario o informe concreto.

En concreto, evita las listas de valores y conviértelas en tablas. Si vas a guardar todos tus CD y libros en la base de datos, no introduzcas el “tipo de objeto” como una lista de valores en un campo de la tabla “Objetos” o de un formulario; mejor crea una tabla “Tipos de objeto” y guarda los valores “libro” y “CD” como registros. Si más adelante quieres añadir un nuevo tipo de objeto (como “DVD”), bastará añadirlo a la tabla y te evitarás tener que buscar todos los puntos donde está especificada la lista de valores.

[Actualización 03-mar-2008]

Detalle de diseño de un campo en AccessTal como indica javieran en un comentario, es conveniente crear las relaciones desde el diseño de tablas. Para eso, basta con seleccionar la pestaña “Búsqueda” y la opción “Mostrar control” > “Cuadro combinado”, seleccionando una tabla como “Origen de la fila”; todo esto cuando se defina un campo que obtiene los valores de otra tabla previamente creada (lo que se conoce como “clave externa“).

Siguiendo con el ejemplo anterior, se trataría de utilizar esa opción cuando se defina, dentro de la tabla “Objetos”, el campo “Tipo de objeto” para que indique si cada registro es un libro, un CD o un DVD.

Esta acción tiene dos efectos:

  • En vez de un cuadro de texto, la interfaz de Access mostrará automáticamente un cuadro combinado para seleccionar uno de los valores existentes.
  • Se crea una relación entre ambas tablas (por defecto, sin integridad referencial)

(more…)

Kroonos: un banco… ¡de tiempo!

Me escribe Jesús Hurtado, CEO de Kroonos, solicitándome que le ayude en la promoción de su web ya que pronto (el 31 de octubre) dejará de estar abierto el registro de usuarios; a partir de entonces, será necesaria una invitación.…

Me escribe Jesús Hurtado, CEO de Kroonos, solicitándome que le ayude en la promoción de su web ya que pronto (el 31 de octubre) dejará de estar abierto el registro de usuarios; a partir de entonces, será necesaria una invitación. Una mención en este blog no le va a causar ninguna avalancha de visitas, pero aquí queda esto. 🙂

Logo de Kroonos

El sitio web se autodefine así:

Kroonos es una web 2.0 que te permitirá sacarle partido a tu tiempo libre. Un banco del tiempo global donde podrás dar y recibir ayuda de forma gratuita de otros miembros de la comunidad.

Por el momento no se puede acceder directamente a ninguna funcionalidad específica del sitio; ésta se puede intuir buceando en el foro, en el blog, etc.; pero la falta de algo más tangible posiblemente le resta cierto atractivo a la hora de registrarse. Eso sí; el concepto de una comunidad en la que los usuarios intercambian tiempo para obtener otras cosas a cambio suena lo suficientemente interesante como para tomar nota y seguir su evolución. Yo ya me he registrado.

En lo que respecta al diseño, sin hacer un análisis profundo (es decir, echando un vistazo), el aspecto de la página es bastante claro y agradable. En el caso de una web con un propósito tan original es de agradecer el texto que lleva por título “¿Qué es Kroonos?”, en el que se describe su objetivo, aunque como comenté anteriormente se echa de menos una visión más concreta de la funcionalidad que ofrecerá el sitio.

Por último, no puedo evitar que me venga a la memoria Momo, la novela de Michael Ende en la que unos misteriosos hombres grises se fumaban el tiempo de la gente. Seguiremos el desarrollo de Kroonos, aunque sea sólo para comprobar de qué otros extraños modos consume la gente su tiempo.

Patrones de software, MVC y los teléfonos móviles

Casi todos los que nos hemos dedicado en algún momento al desarrollo de aplicaciones reconocemos la importancia de mantener separados el contenido y la presentación; es decir, independizar qué hace la aplicación de cómo lo muestra al usuario. Yendo un…

Casi todos los que nos hemos dedicado en algún momento al desarrollo de aplicaciones reconocemos la importancia de mantener separados el contenido y la presentación; es decir, independizar qué hace la aplicación de cómo lo muestra al usuario. Yendo un paso más allá, el patrón MVC propone una separación del software en tres partes:

  • Modelo (model): la información con la que trabaja la aplicación (“los datos”). Habitualmente esta parte está soportada por un sistema de base de datos.
  • Vista (view): cómo interacciona el usuario con la aplicación (“la interfaz”). En una aplicación web suele utilizarse HTML y CSS.
  • Controlador (controller): las acciones que realiza la aplicación (“el comportamiento” o “la lógica”).

Esquema MVC (Model-View-Controller)

Muchos frameworks de desarrollo siguen este patrón, ya que las ventajas de esa separación son múltiples: la aplicación resulta más modular, más flexible, facilitando cambios en una de las partes sin necesidad de modificar el resto.

Por ejemplo, una aplicación desarrollada siguiendo ese patrón permitiría fácilmente cambiar el gestor de base de datos (el modelo) sin necesidad de modificar el resto de la aplicación; o desarrollar cada una de las partes de modo independiente; o acceder a la misma aplicación desde diferentes dispositivos como navegadores web o móviles, simplemente creando diferentes vistas.

¿Este patrón no queda del todo claro? ¿Sus ventajas no resultan tan evidentes? Puede que lo comprendamos mejor si establecemos un símil con algo que casi todos conocemos: la estructura de los teléfonos móviles.

(more…)

Nueva página de SQUaC y blog; experiencias en JTS 2007

La semana pasada, del 2 al 4 de mayo, estuve en las Jornadas sobre Testeo de Software 2007, organizadas por el grupo SQUaC, en el que estoy trabajando actualmente; así que me tocó colaborar como ayudante de organización 🙂 Este…

La semana pasada, del 2 al 4 de mayo, estuve en las Jornadas sobre Testeo de Software 2007, organizadas por el grupo SQUaC, en el que estoy trabajando actualmente; así que me tocó colaborar como ayudante de organización 🙂 Este tipo de eventos son interesantes, no sólo por las ponencias, sino por su “aspecto social”: charlas informales, conocer a gente interesante. ¡Ah!, y es una ocasión de practicar (el oxidado) inglés (no queda otro remedio cuando en una misma mesa se encuentra gente de Holanda, Estados Unidos, Alemania… ¡e incluso algún que otro español!)

Una de las ponencias durante JTS 2007

Todas las ponencias trataron temas relacionados con el testeo; es decir, cómo encontrar errores en las aplicaciones que se desarrollan (porque, igual que las meigas, haberlos, haylos). Podría parecer que no hay mucho misterio en eso: se comprueba que el programa hace lo que debe, ¡y listos!

Pero los sistemas reales son demasiado complicados para verificar todas las maneras posibles de utilizarlos, así que existen multitud de técnicas y herramientas que ayudan a buscar los fallos allí donde puedan estar con mayor probabilidad. De eso precisamente han tratado las jornadas.

Nueva página y blog

Poco antes de que se iniciaran estas jornadas pusimos en marcha la nueva página del grupo SQUaC, que incluye un blog en el que hemos publicado información sobre las ponencias. Todavía estamos añadiendo contenidos y refinando su aspecto, aunque de momento estamos preocupándonos más de los temas de usabilidad y accesibilidad (hay que predicar con el ejemplo); el primer artículo del blog habla con un poco más de detalle de esos aspectos.

Página inicial del nuevo sitio del grupo SQUaC

¡Por supuesto, estáis todos invitados a visitar la página y participar en el blog!