Exploring “Design Thinking” using the notion of a Frame of Reference

Introduction

This is a short piece aimed at the curious. Someone who’s been exposed to Design Thinking workshops and would like to know a little bit more about just why it works. While it’s helpful to have experienced a design thinking workshop, the lack of exposure can be compensated for by a little imagination.

The Lens

The tool used in this post is the notion of a Frame of Reference. A frame of reference is a complex schema of unquestioned beliefs, values and so on that we use when inferring meaning. If any part of that frame is changed then the meaning that is inferred may change.

A person’s frame of reference is always subject to change. Any new insight, belief or value adopted by a person has the potential to change their frame of reference. While it is far more likely that changes to an individual’s frame of reference are minor, there is always the potential for a fundamental shift in perspective (for example, anyone who’s ever said “I found out about X and it turned my world upside down”).

Some useful links about the Frame Of Reference
https://en.wikipedia.org/wiki/Cognitive_reframing
http://changingminds.org/explanations/models/frame_of_reference.htm
Tversky, A. and Kahneman, D. (1981). The framing of decisions and psychology of choice. Science, 211, 453-458.

Problem Solving – Solo vs Teamwork

Using the extremely simplistic model that a person is T-shaped from a skills and expertise perspective (awareness of a broad range of topics and in depth expertise of a specialist area), when a person tries to solve a problem on their own, they’re typically thinking at the limits of their expertise. A bit like the red ellipse in this sketch…

Any new insights they come up with are also likely to also be in the red ellipse, meaning the associated changes to their frame of reference will also be minor at best.

Contrast this to how a collaborating team operates. With the same models, each person in the team is thinking at the limits of their knowledge, but the main difference is that they’re also sharing their insights across the team. This usually means that the changes to an individual’s frame of reference can be significantly greater, as it can be influenced by new insights that they simply would not be able to derive by themselves.

You think differently when you’re in a team

Your Focus Areas Change

A significant part of a good design thinking workshop is a focus on the customer. It’s imperative to build a strong empathic relationship with your customer. Capturing those insights as personas or empathy maps is common. Using the same visual language of T-shaped skills and expertise, the insights that the team derives can be represented as follows

You think about different things when you focus on your customer

If done well, the red T will contain the values, priorities, pain points, motivations etc of the customer. By integrating these insights into the frame of reference of the team members, the ideas that they produce would, almost automatically, have a much better alignment with real customer value and customer priorities.

You Have More Time

Design Thinking workshops have a natural double diamond pattern, with alternating phases of divergent and convergent thought processes.

However, as a participant going through this structure (especially someone who “already knows what needs to be done, they just want to get on with it”) this can feel extremely slow and frustrating.

This “slowness” does have benefits. The main one is that it gives the insights floating around the team much more time to work its way into an individual’s frame of reference and change how they think. In other words, it prevents participants from leaping to conclusions. While there’s nothing inherently wrong about “heading straight to the answer”, the solutions you develop using this type of strategy are not innovative, as by definition you’ve come up with them before. By maximising the opportunities to change your frame of reference, you increase the likelihood that your solutions are much more innovative.

The “Good Cop, Bad Cop” relationship with Tools and Automation

Context: This all started with a request to make the tool a team was using (JIRA) prevent a developer from moving a task that was “in progress” back to “not started”. The manager’s rationale was to forcibly highlight when the team started to work on too much stuff. The developer’s rationale was to fix an incorrectly started task.

It got me thinking about how we open up this discussion and make it inclusive. Some questions that seemed to work were:

  • Why do you need to be told how to “be good”?
  • When do you need the tool to “pick up after you”?
  • When do you need to be reminded about what your way of working is?
  • What mistakes do you need the tool to forgive or punish (or both)?
  • When do you need the tool to prevent all mistakes?

All of this stuff is enabled by automation. So just how much automation do you need, and what is it to be used for?

  • Automate or mechanise the “boring parts” of your job?
  • Validation for error prevention or error detection?
  • Automate all of the work variants? Or just the common ones?

 

As I like analogies, I thought I’d explore this using one, in this case, one of my favourite topics – “food”. For the purposes of this blog, assume time is magic and doesn’t cause any problems.

Making Soup

I want to eat something. Perhaps a bowl of soup.

soup
just in case you don’t know what it looks like

 

The full process starts in the ground. I could start there with a fully manual solution:

crops
The Good Life

Grow the raw ingredients from scratch. Prepare them as I want, cook them and voila, a delicious meal.

  • + complete control of ingredients
  • – slowest method
  • – I could grow the wrong thing

 

I could “automate” that growing process, by buying the raw ingredients from a shop:

ingredients
Carrot, Celery, Very-Strange-Onion

  • + pretty good control
  • – may not have what I want in stock
  • – might not be able to manage the quality “precisely”

 

I could increase my levels of automation and also automate the preparation work by buying the pre-prepared stuff:

prepared
Definitely carrot sticks

  • – only partial control
  • – may not have what I want in stock
  • – may not be prepared as I need – e.g. carrot sticks when I need grated carrot

 

Or I could be extreme and also automate the cooking process:

tin

  • + fast
  • – limited control
  • – may not have what I want – e.g. I want “carrot and celery”, but all I can buy is “carrot and coriander”
  • – mass production, so probably very generic

 

Each of these levels of automation is accompanied by varying degrees of “policing”. If I’m a danger to myself when trying to chop vegetables with a knife, automating the preparation work is probably a good idea. But with that are constraints – I can only eat meals that can be made from pre-prepared ingredients.

 

Project Team Outcome

In the end, we left it such that you could move tickets back, and the policing aspect would be done by the humans in the team. Hopefully they chose that because it was the right thing to do, and not because they wanted my food analogy to stop…

The “Perfect” JIRA configuration

Well that got your attention. Aka sorry about the clickbait.

Context: A large-ish project is using JIRA(*) to manage their work, with varying degrees of success. And they’ve customised their instance heavily. No change was too small, or unreasonable. Over time, their configuration evolved as to be practically incoherent. There’s a parallel with teams maintaining software without paying any attention to technical debt. Things are built on top of other things. Workarounds are invented because it’s easier than refactoring, fixing deep seated faults and moving on. I’m sure most people have had an experience or two a bit like this.

Even your tools like Confluence and JIRA can have technical debt. Remember to pay that back regularly.

When I spent time with them, I came to realise that a significant underlying cause of their tool-based-pain seemed to be rather “simple”. They were not consciously aware of how they worked as a whole. They all knew what their roles were and how to do the day job. They even mostly understood how to work with their immediate neighbours (in a value stream sense). But they didn’t get the whole picture. No-one did. As a result, there was no way of telling whether a JIRA configuration change that would alleviate a local problem would have an adverse effect.

There’s a huge chasm between where they are now, and where they needed to be. Step one was to get back to basics – let them discover how they work (as opposed to how they use their tools) and then help them refine that.

Which brings us to another challenge. It was hard for this project to accept an OOTB configuration – “we do things differently here; we simply couldn’t work with a vanilla installation!”.

So I cheated.

They wanted to work sensibly, so they had great intentions. I tried to use that with a sequence of questions which allowed them to build up a tailored process for them:

  1. Are you sure you want to use Sprints? Yes! Handy, it allows us to have backlogs, sprints, sprint planning, demos and retrospectives.
  2. Do you want to visually track what you’re actively working on? Yes! That gave us an “In Progress” column and state
  3. How do you tell if what you’ve worked on is good enough? We have testers in the team, they work with developers. Before we merge our code, we need to explicitly run tests. That gave us a “Being Verified” column and state.
  4. When do you close off a story? When it’s accepted by the Product Owner. That gave us a “Done” column and state.
  5. What happens when things get stuck? We have a blocked column and we put things in there so our scrummaster has a backlog of blockers. That’s another state & column (**).
  6. When you run your “before-merge tests”, can you start that verification as soon as the developer is ready? No sometimes it takes us a bit of time or we batch up some related work and verify multiple changes at once. That gave us a “Ready to Verify” interim state that testers would pull from.
  7. Is your product owner available at all times to accept stories as soon as they’re ready? No, our product owner has a day job so sometimes they have to batch accept stories. That gave us a “Ready to Accept” interim state that the product owner would pull from.

 

The final workflow they were happy with looked like this:

disciplined

The corresponding board looked like this:

disciplined_board

If you squint, that looks like Not Started > In Progress > In Test > Done. Which is pretty standard. But because they, as a team, worked through their process, it was their board. They also thought about a few useful elements, such as pulling work when you’re ready to do it, and trying to limit how much they had on the go at any one time.

 

Footnotes

(*) I don’t mind the Atlassian stack. It works well enough. But if you go well beyond OOTB then like a lot of products you’re flying without an electronic safety net.

(**) I’m not keen on having a discrete Blocked state as I’m a bit nervous of it being seen as a “rug to sweep things under and start something new”. But this team liked it, and it’s their way of working, so I accepted it.