Five Prevalent Pitfalls when Prototyping
- Pitfall #1: Focus on the Deliverable, not on the Learning
- Pitfall #2: Too Much Converging; Not Enough Diverging
- Pitfall #3: Working in the Wrong Fidelity
- Pitfall #4: Too Little Evaluating
- Pitfall #5: Fixating On A Single Prototyping Tool
Must-read…
A color matching game
Learn, play and test yourself
Tips for Structuring Better Brainstorming Sessions
By Catriona Cornett
Related link to this resource: Design Studio – más que una herramienta
La técnica de Design Studio ha sido introducida por primera vez en el contexto de desarrollo ágil como una herramienta de colaboración para ideación de soluciones mediante sketching. Con el paso del tiempo, he tenido la ocasión de poner esta técnica en práctica en múltiples ocasiones con equipos de diferente naturaleza: programadores y diseñadores, analistas y expertos de dominio, sólo diseñadores, etc.
Durante cada una de las sesiones, he ido experimentando cómo los participantes no sólo aportaban sus ideas, criticaban o recogían nuevo conocimiento sobre el problema, sino también, cómo se destapaban las ambigüedades, incertidumbres y las conjeturas erróneas acerca de qué es lo que necesitan los usuarios y de si las propuestas iban en algún momento encaminadas a resolverlas.
La Design Studio es, más que una herramienta de colaboración, una técnica necesaria en una metodología de Diseño Centrado en el Usuario. En este artículo me gustaría recoger algunas de las claves para llevarla a la práctica y sacarle partido. Si quieres saber más sobre cómo planificarla te recomiendo el artículo The Design of a Design Studio y el siguiente recurso.
Como es conocido, en la metodología de Diseño Centrado en el Usuario se parte de la base de que los usuarios que van a utilizar la solución saben mejor que nadie cuáles son sus necesidades.
Independientemente de la capacidad de cada uno de saber expresar verbalmente lo que necesitan o no, las entrevistas a usuarios bien ejecutadas son una fuente directa y rica de información que debe dirigir el resto del proceso de diseño. Obviamente, no es la única fuente, la observación de campo, la comparación de productos, el análisis estadístico de comportamiento previo, o el user testing también proporcionan mucho conocimiento sobre cómo se comportan nuestros usuarios.
Las entrevistas requieren de un ejercicio de análisis posterior donde buscar cómo se expresan los objetivos, las expectativas, las restricciones, el contexto, las preocupaciones, las ideas y los problemas a los que se enfrentan los usuarios. De todos esos aspectos, se busca identificar también patrones de comportamiento para armar lo que se conoce como modelo mental del usuario.
Esta es una información de partida útil para alimentar la sesión de diseño durante una Design Studio.
Las personas y los escenarios suelen ser los grandes olvidados a pesar de que toda solución debe partir de un problema bien formulado como una historia real que ocurre en un contexto real con un usuario real. O digamos, al menos, realista. Sin embargo, en el momento de idear soluciones y, sobre todo, de defenderlas, tendemos a olvidar para quién se estaba solucionando. La persona y el escenario deben también dirigir la historia que se cuenta, puesto que no estamos en una fase de diseño final, detallado, o de alta fidelidad, sino, todo lo contrario, estamos conceptualizando posibles soluciones y planteando nuevas hipótesis a explorar.
Existen múltiples formas de valorar las propuestas de los participantes, aunque lo que es una constante es que, después de una larga jornada de diseño y creatividad las “mentes pensantes” estén poco motivadas a recibir críticas. Puntuar según criterios puede parecer a priori una forma objetiva de valorar el conjunto de las ideas pero se corre el riesgo de descartar demasiado pronto ideas que son geniales por el mero hecho de no haber convencido a la audiencia. Por otra parte, expresar críticas sin el propósito de buscar debilidades para mejorarlas suele minar la actitud de los participantes.
La mejor opción en mi opinión es buscar la validación de las propuestas según los supuestos que se han analizado anteriormente ¿satisface o no los requerimientos que se habían asumido? Posteriormente se puede hacer un planteamiento de en qué punto está la propuesta, es decir, qué haría falta para llevarla a cabo más que asociarle una nota o una ‘prioridad’. Las prioridades son de hecho la forma más macabra de acabar con las grandes ideas después de una Design Studio. Lo ideal, en este caso, es ser capaz de identificar qué supuestos siguen siendo válidos, qué aspectos hay que volver a investigar con o sin usuarios, y cuál es el beneficio que de ejecutar esa idea podría obtenerse al respecto.
Como decía, la técnica de Design Studio es más que una simple herramienta de colaboración e ideación, resulta convertirse en una representación de una parte del proceso de Diseño Centrado en el Usuario y de la formas de cooperación y estrategias de producto que va a diseñarse. Más allá de las complejidades de entrevistar usuarios, sketchear y criticar, lo que se persigue con esta técnica es mostrar las fortalezas y flaquezas de las que se parte.
Con un poco de suerte, puede convertirse en una práctica que cambie la forma de desarrollar productos digitales, no por lo ágil, sino por su orientación a desarrollar soluciones que apasionen a sus usuarios.
I’m not an expert in Scrum methodology, but after working and collaborating for 3 years as part of a Scrum team, here are some ways we’ve a got to introduce User Experience practices into agile development:
How do you design engaging applications that people love to use? This book demonstrates several ways to include valuable input from potential clients and customers throughout the process. With practical guidelines and insights from his own experience…
Recommended to developers who really want to create user meaningful applications.
The best point in it: the author is a Microsoft .Net developer which give him a practical and interesting viewpoint.
Conocer las prácticas fundamentales del Diseño Centrado en el Usuario (DCU), como desarrollador, diseñador, o manager, es el primer paso para conseguir invertir los esfuerzos del desarrollo en crear aplicaciones que de verdad supongan un valor para las personas que van a usarla.
Esas personas, los usuarios, transformarán nuestra visión convirtiéndose en aliados para reducir incertidumbre y como fuente de inspiración, más allá de la experiencia y la personalidad con la que nosotros afrontemos las decisiones.
El DCU no es una metodología exclusiva de los diseñadores, sino que supone una estrategia común para conseguir resultados que realmente responden a necesidades de usuario. Con ella, podremos acercarnos siempre a soluciones más usables que mantendrán una buena experiencia a lo largo del tiempo de vida del producto o servicio.
El libro User-Centred Design el autor Travis Lowdermilk ofrece una interesante guía para desarrolladores, desarrolladores como él, para la construcción de aplicaciones user-friendly.
Llama la atención tanto el enfoque como los ejemplos que expone, que hacen muy fácil entender conceptos básicos usando situaciones a las que muchos nos hemos enfrentado. Y lo hace fácil porque realmente no es complicado, otra cosa es que como el autor dice
Creativity requires us to be courageous and vulnerable. Although trying new things may be risky and embarrassing, it’s the key to discovering new insights.
No podemos negar que las expectativas de los usuarios son cada vez más altas, que tienen más referencias que nunca sobre el valor del diseño y que la industria clásica de desarrollo de software no puede continuar anclada en procesos y metodologías que ignoren las necesidades y requerimientos de los usuarios.
Existen otras referencias interesantes que podrían serte útiles tras echar un vistazo a este libro:
El pasado 6 de Mayo, el equipo de BalsamiqNext incluyó, por fin, el estado ‘indeterminado’ para el control de Checkbox.
New features! Dashed and dotted lines/rules, indeterminate checkboxes, & bug fixes. Check it out! balsamiq.com/products/mocku…
— balsamiqNext (@balsamiqNext) 6 de mayo de 2013
El uso de este estado es muy marginal, pero sigue siendo sin embargo necesario cuando queremos mostrar checkboxes anidados, en concreto cuando el elemento padre contiene alguno de sus elementos hijos en estado ‘seleccionado’ y al menos uno en estado ‘normal’.
Sin embargo, esta representación tri-estado es considerada en ocasiones demasiado confusa para los usuarios, probablemente porque un estado indeterminado es de por sí ambiguo y poco específico ¿cuántos y qué elementos están realmente seleccionados?
Otra problemática es que este estado a veces no es activado por interacción directa del usuario sobre el control, sino por el estado de los elementos hijos, con lo cual, la representación visual puede despistar.
Incluso cuando es el usuario quién lo acciona de forma directa, continúa siendo difícil entender qué significa un estado intermedio entre seleccionado y no seleccionado.
No obstante, su uso sigue viéndose en ciertas aplicaciones, por ejemplo cuando debemos hacer selección múltiple sobre muchos elementos que además vienen agrupados para su mayor legibilidad y cuando la selección/deselección del elemento padre se usa para seleccionar/deseleccionar todos los elementos hijos de una vez.
En cualquier caso, no se trata de evitarlo sin más sino de reducir su uso sólo para las ocasiones en las que tenga de verdad sentido y a partir de ahora además podrás sketchearlo con la futura release de Balsamiq Mockups.
Si quieres saber más sobre el buen uso del Checkbox una buena referencia es la guía de Microsoft y el Nielsen’s Alertbox dedicado a este control.
Como sabéis y comentamos hace unas semanas en este vídeo de introducción, Balsamiq permite la configuración de un directorio compartido para los recursos (assets) de todos tus proyectos a través del directorio denominado “Account assets”.
Generalmente, cada proyecto mantiene una estructura de dos niveles como se muestra en la captura.
Sin necesidad de configuración, los símbolos guardados bajo el directorio “assets” son accesibles bajo la categoría “Project assets”. De forma adicional a este directorio, Balsamiq permite configurar otro directorio para ser compartido no sólo entre tus proyectos, sino incluso entre varios usuarios si éste se encuentra en un directorio en red.
Para ponerlo en funcionamiento tendremos que seguir los siguientes pasos:
<config><documentsPath> C:Documents And SettingsAdministratorDesktop </documentsPath><config>
Existen otras opciones de configuración que pueden añadirse a este archivo, como, por ejemplo, elegir el código de color exacto para los elementos resaltados o activos, la tipografía o el uso de cookies.
Con el uso de recursos compartidos por fin podremos reutilizar elementos generados entre varios miembros de un equipo incluso si éste está deslocalizado. Otro uso interesante es la creación de una librería propia de patrones, muy útil para mantener un mismo vocabulario visual entre varios proyectos.