El diseño de interacción en Drupal 7

El trabajo que están haciendo en Drupal 7 es realmente bueno. De todas las mejoras que traerá tengo especial interés en la nueva capa de abstracción de base de datos y el diseño de interacción. Para saber más sobre el diseño de interacción en Drupal 7 recomiendo este blog que no tiene desperdicio.

Viendo la siguiente galería de imágenes nos podemos hacer a la idea de las sorpresas que nos encontraremos. Hoy precisamente he mantenido una interesante conversión con algunos de mis compañeros de trabajo sobre el valor de trabajar con prototipos (storyboards, wireframes) y modelos conceptuales, y lo que están aportando en nuestros proyectos. Aun nos queda mucho por aprender, pero creo que lo importante es tener convinción sobre lo que uno está haciendo. Incluso, aunque los resultados no sean todo lo satisfactorios que deseemos.

En el próximo proyecto en el que tengamos la oportunidad, voy en poner en práctica ciertos cambios que no implican un cambio en la metodología de desarrollo pero sí en la ejecución y enfoque de ciertas tareas. Algunas notas previas:

  1. En el roadmap del proyecto no aparecerán milestones con palabras como análisis, diseño, codificación o verificación
  2. El desarrollador de interfaces de usuario trabajará desde el primer momento con el analista, no esperaremos a que los objetivos y funcionalidades estén algo avanzadas.
  3. Ni hablar de domino o modelo de datos hasta que las historias de usuario estén maduras. Con eso me conformo. Conseguir la validación es -casi- una utopía y dar la sensación de que se están cerrando las puertas al cambio.
  4. Los ingredientes: una wiki, un buen móvil para sacarle fotos a los bocetos y la pizarra, rotuladores de colores y un buen taco de A4 y A3 (reciclables por favor).
  5. No sé por qué pero casi todos los diagramas sobre arquitecturas lógicas que he visto representan la persistencia de los datos en la parte inferior y ascienden hasta el lado del cliente pasando por la capa de acceso a datos, modelo, lógica de negocio y controlador. Pues bien, nosotros queremos empezar por arriba. Comenzando por codificar los interfaces de usuario a partir de los prototipos y descender. Habrá un momento en el que habrá gente trabajando en paralelo en las distintas capas. Eso será buena señal.
  6. Vamos a definir un glosario de términos que NO podemos usar delante de los usuarios que nos ayudarán (o no) a conocer lo que necesitan. También hay situaciones en las que los usuarios sólo tienen claros objetivos de muy alto nivel y necesitan que tú les guíes.

Si un arquitecto es capaz de transmitir una idea creativa mediante la proyección, nosotros tenemos que ser capaces de diseñar la interacción entre los usuarios y la información que necesitan gestionar. En más de una ocasión me he encontrado en reuniones para presentar los trabajos realizados (total o parcialmente) y tras presentarlos el cliente te dice claramente que eso no es lo que el tenía en mente o lo que él necesita. Qué le pasaría a un arquitecto si tras construir una vivienda el cliente le dice que eso no es lo que quiere.

2 thoughts on “El diseño de interacción en Drupal 7

  1. Hola Manu, estoy impaciente por comenzar el experimento.

    Solo una pregunta, ¿qué pasa con el catálogo de requisitos?, ¿desaparece?. En ese caso necesitaremos una herramienta que facilite la gestión del cambio a nivel de prototipos ¿no?, es decir, necesitamos relacionar prototipos, clasificarlos según prioridad, etc. No podemos olvidar que estamos llevándonos los requisitos a prototipos.

  2. Hola Antonio:

    Bueno, en realidad no es algo nuevo, quizás sí para el departamento, pero no estamos inventando nada, simplemente trabajando por adoptar una metodología.

    Los requisitos tal y como los tenemos concebidos ahora sí deberían desaparecer, especialmente la clasificación que hacemos de los mismos (sistema, de información, funcionales, no funcionales, etc). Los prototipos formarán parte de las historias de usuario, y éstas, sí tendrá valores del tipo: prioridad, madurez, nivel de dependencia, etc…

    Ojo, nadie ha dicho que nos llevemos los requisitos a los prototipos. Dejamos a un lado los requisitos, que seguirán estando presentes pero con otro aspecto, para usar otro lenguaje de comunicación más cercano al cliente, más intuitivo, comprensible y ágil a la hora de revisarlo. Todo esto dará como resultado unas historias de usuario en las que el equipo de diseño habrá participado muy activamente.

    Un saludo

Leave a Reply

Your email address will not be published. Required fields are marked *