Design thinking

It’s just over a month since I completed a three day leadership bootcamp run by the lovely SatoriLab.  I documented the tools from days 1 and 2 here, and am finishing the job by adding the day 3 tools / concepts here.  Day 3 focused on service design and prototyping.  Here are the highlights:

  • Brasília case study – example of city design that looked great from above but didn’t work for the users (citizens) at  ground level.  Architects/planners design new places with fancy aerial models, but fail to visualise what it’s actually like to work, live, and play in a space.
  • We need to frame the problem – why are we doing this work?  Who are our users?  What are their needs?  What services currently meet their needs?  What outcome(s) will users get from this service?  What are our key metrics?  What are the next steps to develop the service?  What should the user journey look like?
  • Most of government is mostly service design most of the time ~ Matt Edgar
  • The policy lab is a big user of design thinking
  • We should be a user centred organisation – putting our users at the heart of what we do
  • Use the agile life-cycle to hone problems and solutions:  Discovery > Alpha > Beta > Live (DABL).  Get users involved early, and involve them continuously.  Going through DABL controls exposure to risk by reducing the cone of uncertainty.  Funding is released in phases subject to passing of gate reviews.
  • Design council double diamond model:  Discover, Define, Develop, Deliver.  Spend more time on problem definition – up to half of the project should be devoted to this.  There’s no point delivering a solution for a poorly defined problem.
  • To understand the user experience ask yourself (and actual users!), what do our users:  Think and feel?  Hear?  See? Say and do?  What causes them pain?  How do they gain?  The goal is to empathise with the user.   Ask them open-ended questions… “Tell me about the last time you used XXXXX service”.
  • Constantly Replace Assumptions With Evidence.
  • Defining user needs – understand what users really need.  Don’t prescribe solutions in user stories.  e.g. “As a diabetic I need to see my GP once a month so I can avoid health complications” = bad user story.
  • Useful matrix for analysing the user journey:  for each stage (pre-service, during 1, during 2, during 3, …. during N, post service) – consider what the user was doing and thinking, how they were feeling, and any insights and opportunities for design improvements.
  • Take opportunities to collect user feedback – e.g. on a web page, ‘was this page useful?’
  • Rapid prototyping:   helps you pick the right goals and designs early;  helps check you’re designing something people actually need;  Lets you try something out without the pressure of perfecting it;  helps you to empathise with the user through role-play;  provides quick feedback loops.
  • It’s the bravest person that puts pen to paper first #jfdi
  • Make prototypes lo-fi (messy and amateurish) as users are more likely to give feedback if they see they didn’t take a long time to produce.
  • Prototyping plan – Key elements of the idea; what do we want to learn?; how will we test it?; Who needs to be involved?; When.
  • Hacker mentality – the meeting is ‘building the thing’, not ‘talking about building the thing’
  • The only people who can change the culture of an organisation are the people inside the organisation.
  • <[]>  The importance of opening, exploring, and closing a discussion.

Leave a Reply