Not a single design process

We spend years and years exploring, trying and following guidelines about what’s right and wrong to do when “doing UX”. We look for the perfect process, the one that tells you: yes, you’re following a user-centred design methodology that will ensure the best user experience possible.

But let’s face it: there’s no one single process that helps you to solve any and every single problem, and not all designers can and must follow the same creativity path to build good solutions.

So what shall we do then? My suggestion, follow principles, not processes and get alignment, not agreement.

Always learning about users

In my experience, I’ve seen different designers working in a very different way, those who need to start playing around with high-fi prototypes to start questioning the problem, and those who need to start asking people around before moving a single pixel.

Research comes in different ways, and that’s good as long as we wonder who are our users, how do they behave, and what do they expect. We can look for the answers while speaking with them or while building a prototype. We can learn about them while testing a wireframe and while picking the ideal colour palette if you really consider their needs.

The key thing is to be open to make design decisions based on this information at any stage of the process. It shouldn’t be too late to use a piece of knowledge for the good of the product.

Use the tribe

Agile methodologies might be the golden egg or the most toxic ‘member’ of your team. Only very senior designers really know how to adapt the methodology to their own process and way-thinking, and how to be flexible enough to move forward at the development pace. However, the process doesn’t depend only on me as a designer, but me as part of a tribe.

We should use the tribe more to provide and receive feedback, to delegate and transform ideas, and to lead the design thinking process. We’re not always the best executing a design, but we can seed other’s people minds to generate better solutions.

Using the tribe is more than sitting on a room to agree on what to do and how to do it, but to facilitate the conversation around design to find an alignment of objectives. Designers, like other stakeholders, have their own principles and priorities and they should be respected, not simply transformed, that’s when alignment makes sense.

Diverge and Converge

Always learning about users and using the tribe are just two examples of how design processes can be deconstructed into principles. Whether you are redesigning a product or starting from scratch you know that there are some activities that are needed:

  1. Understanding users and their context of use.
  2. Modelling user requirements into something actionable.
  3. Creating usable and convenient solutions.
  4. Getting cool things done and evaluated against requirements.

It’s not about their sequence, but their value. When I design a product, I like to think that at any point in time we can apply any of those principles and get benefit from them, that any time is the right one to speak to a developer or to a user and get clarity about the solution or the problem.

So if you’re trying to define your perfect design process I’d suggest you wondering about how you believe it should be done and write down those principles first.

So what’s a good solution?

As a doctor working in an Emergency Department and seeing patients (sic: people) with largely preventable conditions/diseases alot of the time, I really like the idea of personalised medicine and involving patients and empowering them to take control of their healthcare. Brushing teeth is an excellent example that I wouldn’t have thought of before. However, I would echo some of the previous comments on the dangers/naivety of providing some of this info. Lab results are only relevant when married to the clinical information (i.e. the pateint’s history, symptoms, past history and examination findings). This information is far more important and lab tests should only then be done to confirm or rule out your findings from the clinical info. Therefore providing patient information printouts based on the lab results alone is foolish and dangerous.

Also the speaker makes a good point that fear does not work in health education/promotion. I think that giving a patient a printout saying that you have 15% (or whatever) chance of getting prostate cancer/breast cancer/arthritis/whatever is probably one of the most fear-inducing things you can do to a patient. Especially considering it is almost impossible to generate that kind of accurate prediction of any condition based on a blood test or even group of blood tests.

The speaker also says that they have used colour (as if to say “Duh why hasn’t this been done before”). The dept I work in has been told by hospital management to stop ordering more paper as the hospital acn’t afford it. We have had to totally rationalise the amt we are printing and handing out. I know this happens alot of places in the public health system. So we have barely enough paper to put in printers let alone colour printers and the cartridges to keep them running. he may be aiming his comments at the lab companies that make all that money but I feel his talk doesn’t take into account the practicalities that exist in an ED / other healthcare settings

John Cronin (Posted 3 years ago) on Thomas Goetz’s TEDMED talk titled: It’s time to redesign medical data.

I found this comment as a perfect example of the real challenge on Information Design in Healthcare still Today.

We have to think and design for real practice with its context, its users, its information quality. Colour sometimes is a luxury and ranges, percentages and reference values could mislead instead of giving support.

 

User Feedback

image

¿Cuándo fue la última vez que hablaste con un usuario? ¿Has improvisado alguna vez una reunión para enseñarles algún concepto en el que estabas trabajado?

No siempre se tiene la oportunidad de planificar una sesión de testing formal ya sea por la falta de tiempo, de recursos, o la inaccesibilidad de los usuarios. Sin embargo, hay veces en los que ‘secuestrar’ usuarios durante un tiempo limitado resulta la única gran oportunidad de recibir de primera mano algo de ‘feedback’.

Recibir ‘feedback’ espontáneo de un concepto en  marcha o sin terminar debe hacerse teniendo en cuenta algunos detalles importantes para que éste nos aporte algo útil. Allá van unos cuantos factores que yo siempre trato de tener en cuenta.

Qué significa ‘Feedback’

‘Feedback’ en inglés significa simplemente ‘comentario’ u ‘opinión’, si es negativo es una crítica, si es positivo es un incentivo, un reconocimiento. En otros contextos puede traducirse como retroalimentación, aunque eso es un tipo de ‘feedback’ que no nos interesa, ya que de un usuario necesitamos sus ideas y su experiencia, y no saber simplemente que está ahí.

Recibir ‘feedback’ debe servirte para seguir adelante con alguna idea o echar marcha atrás. Pero siempre quien debe decidir es quien diseña y no quien opina.

Conoce a tu usuario y demuéstralo

Si estás pidiendo opinión es importante saber a quién se la pides y por qué ¿Necesitas que te ayude a cerrar un circuito? ¿A completar con contenidos que no aparecen? ¿Quieres que valide una de tus hipótesis?

En cualquiera de esas situaciones debes mostrarle cuáles son los supuestos de los que partes y éstos a su vez deberán estar basados en algo que tenga que ver con él o ella.

Si has llegado hasta esa idea es porque se supone que buscabas satisfacer las necesidades de un usuario muy parecido a él o ella.

Concreta

Ve al grano con tus preguntas, no des varias opciones, espera a que se explique y nunca le interrumpas para hacerle ver que no entendió tu pregunta. De la forma en la que se exprese puede que halles una respuesta aún más útil.

Tampoco es el momento de hacer un despliegue de conocimientos técnicos así que pregunta cosas sencillas y espera su reacción.

Siempre positivo

No des opiniones negativas de tu diseño. Más que parecer un gesto de humildad ante una solución no muy buena lo único que consigues es influir en una percepción negativa de la misma. Es preferible un comentario como ‘parece inacabado’ (algo que ya sabes y que tiene solución) a incentivar a los usuarios a pensar que ni si quiera tú estás convencido/a de ir por una buena dirección. Si los usuarios dudan, tenderán a reforzar la visión negativa en lugar de ayudarte a concluir tu idea.

Hay otro detalle que puede que sea simple sugestión pero que a mí me ha ayudado mucho siempre. Generalmente, cuando pedimos ‘feedback’ tendemos a alertar y a justificarnos dando demasiadas explicaciones sobre lo que significa ‘wireframe’ o ‘inacabado’. Es preferible introducir las ideas con dos recursos básicos: el sentido del humor y animarles a imaginar.

No es lo mismo ‘pedirles tiempo para que te ayuden’, a ‘darles la oportunidad de ver algo impresionante’.

En conclusión…

Nunca pierdas la oportunidad de hablar con un usuario, cuéntale lo que haces pensando en las personas como él o ella, demuéstrale que la solución está basada en pequeñas decisiones y que ese pequeño momento es una excelente ocasión para ambos de avanzar en la definición de tus ideas.