Diamond Tools

Alas, the final post to the Co-design for Digital Health Course. In this post, I go a bit more in-depth for each phase of the Double Diamond. Some of these I already knew under different names, and some I had never heard of!

Discover

The instruction here is simply: be curious. You are trying to find an issue or opportunity worth solving and understand it in all its contexts, by spending time with the people it affects.

The methods:

  • Mind mapping. A.K.A Brainstorm. Useful for generating a lot of ideas quickly.
  • Observation. “A day in the life of”, where you watch someone interact with products, services, environments and other people, and note where things break.
  • Interviews. In-depth is one researcher with one participant. Expert is the same setup but with a subject-matter specialist. Group interviews are one interviewer asking questions of several people at once.
  • Focus groups. I had been using this interchangeably with group interviews, wrongly. A focus group is moderated so that people build on, react to and argue with each other. The point is watching opinions form socially rather than collecting answers in parallel.
  • Diaries and journals. You hand people a notebook, or ask for photos, video or voice notes etc.
  • Crowdsourcing. An open call online, usually questionnaires or microprojects, where a “crowd” volunteers responses. Cheap and fast, which is the whole appeal.

The course then split health and care problems into the obvious and the subtle ones, which I thought was a useful way to look.

Obvious healthcare problems look like a service that is understaffed or unsafe, a condition that damages someone’s physical or mental health (a person with dementia losing memory and sinking into depression), a device that underperforms, a drug with serious side effects, or a paper-based process nobody can keep up with.

Subtle healthcare problems look like a service that does not exist yet, such as genomic screening. Or the social determinants, which is housing and employment and transport and justice and everything else that decides how healthy you get to be. Or a clinician struggling in their role. Or the unglamorous work of keeping infrastructure that already functions from falling over, watching for trends to feed into policy, and maintaining good health in people who currently have it.

What stayed with me were the examples of where ideas come from, whether it is the professional who sees the same problem forty times a week or the patient living inside it. They mentioned Immersive Rehab, founded by Isabel Van De Keere, which builds VR environments for people going through physical rehabilitation. I want to read more about the research behind that one, specifically the psychology of it, and also why it closed down.

Define

This is the converging half of the first diamond. You analyse what you collected, filter it, and end up with a workable brief.

  • The 5 whys. Root cause analysis by asking “why?” repeatedly until you hit something real.
  • Journey maps. A visual of someone’s path through a service over time, with every interaction on it. You are looking for magic moments and pain points.
  • Affinity diagrams. Grouping findings into themes and ranking them.
  • Participatory analysis. Bringing the people from the Discover phase back in to help interpret what you collected. Participatory analysis is the one I would want to work on most to improve my methods.
  • Hackathons. Putting clinicians, carers, patients, technologists and designers in one room on one problem. Apparently these produce more than demos, including trials, business plans and funding.

The problem definition template is worth writing down as well:

This project addresses the issue or opportunity of (what, which situation), which is shaped by (social, economic and other factors), and which matters because (insights).

Then you reframe it as

“How might we…?”

and check whether the question still allows for a range of answers. If it only permits one, you have written a solution and called it a question.

Develop

Now you ideate, generating as many possible solutions as you can with an open mind.

The methods:

  • Persona profiles. Character sketches of your users, grounded in research rather than vibes, covering demographics and habits.
  • Role-playing. Physically acting out what happens when someone uses the thing.
  • Scenarios. Writing a story about future use from the user’s point of view.
  • Storyboarding. Asking people to draw the journey through an alternative service as a series of panels.
  • Prototyping. Rapid prototyping is designing-through-making, quick and physical, and good for getting reactions out of very different stakeholders. Hardware prototyping is higher fidelity, closer to the real feel of a device. Interface prototyping covers the screens, buttons and navigation, on paper or on a machine.
  • SCAMPER It is seven prompts for manipulating existing ideas into new ones: substitute, combine, adapt, modify, put to another use, eliminate, reverse. I like it because it takes the pressure off originality. There is nothing new under the sun, mostly there is only a thing that worked over there being carried over here, and SCAMPER is a structured way of asking where else the thing might work. It’s undoubtedly my favorite and one I hope to use often.

Then you have to choose. The course lists open multivoting, secret ballots, pros and cons, group consensus, the leader just deciding, community rating, screening matrices, and the Delphi survey.

The Delphi survey is structured thus: You assemble a panel of experts, send them a questionnaire, then anonymise and summarise everyone’s answers and send that summary back so people can adjust their position against the group. You repeat for three or four rounds until opinions stop moving.

Fun fact: Delphi was an ancient Greek sanctuary, which the Greeks considered the centre of the world!

Deliver

You arrive here with several ideas and have to narrow to one. The line the course used:

Don’t fall in love with your prototypes.

Quality comes from the number of iterations you can stand to run. Every round tells you something about the weaknesses of the idea, the problems you did not anticipate, and the people who will actually use it.

  • Think-aloud protocol. Someone narrates what they are doing and thinking while using your prototype.
  • Feasibility testing. A small pilot with real users, mostly to find out whether your design for the full evaluation will hold up.
  • Randomised control trials (RCT). Comparing your product against a control, whether that is current practice, a stripped-back version, or nothing. This is the only one that can show your thing caused an outcome, and you can also use it to compare versions during development. It costs time and money accordingly.
  • Simulation-based evaluation. Putting users in realistic clinical scenarios to do tasks close to real life. Faster and cheaper than an RCT, and viable in situations where a trial would be impossible or unethical.

The Nuffield Trust (2021) also published ten lessons on implementing digital innovations:

  1. Give real time and resource to engaging end users.
  2. Co-design with them; it is not optional.
  3. Identify the need and its effect on the whole system, rather than identifying a need for a technology.
  4. Work out what will motivate or block uptake.
  5. Ignore information governance at your peril.
  6. Be willing to change the product along the way.
  7. Build in adequate training for the services using it.
  8. Embedding the thing is half the journey. Data collection and analysis carry on afterwards.
  9. Resource the roll-out properly, including project management.
  10. Local areas vary, so adapt.

Now, onwards, soldier!

Things I have open in tabs and intend to actually read: