Jude’s weeknotes — 25 Nov 2022

Jude Webb
6 min readNov 26, 2022


A cracking week of service designing.

What did you experiment with?

I’ve been asked to:

  • Visualisation of the public beta service and all of its parts from a user perspective
  • Also wants to see the back office as well (EG how do operations work with case management and what are the hand offs like in practice)

I tried to attempts because I couldn’t get my head around doing both at once.

Showing how the products fill together and high level info about each

The first was using a visualisation I’d done before which showed the ‘elements’ of the service. You could also call these the products. It had them overlaid on the step in the process and categorised by type of product (online guidance, online tools, human support and 3rd party support).

Example diagram with step 1, step 2, step 3 and step 4 across the top. Down the side there is online guidance, online tools, human support and 3rd part support. Over the top there 4 boxes with product 1, 2, 3 and 4. Showing which areas they apply to.
Showing how products fit together to meet user needs at various step through different channels.

I then supplemented these with a page on each product explaining:

  • Purpose
  • What’s working
  • What’s not working
  • Example content (links where relevant)
  • A screen shot if relevant
An example of how to lay out the content: Purpose, What’s working, What’s not working, Example content, A screen shot. There are squiggly lines representing where the content would go
Template for a product page

While putting together the overall picture of how the service fits together with the product pages give a picture of what the service is made up of it doesn’t quite meet the brief. You don’t understand the service from a user point of view and can’t see the back office processes.

So I tried something else.

Story board

At the moment we’ve got some user research going on to understand the how users experience the journey. I’ve observed a session and listened to what the user researchers are finding. With this fresh in my mind I wondered if a story board could tell the story.

I started by thinking about more specfic examples of what I could include in the story board. For example thinking of all possible entry points and journeys though the service, to try and find one that told the fullest story.

Then I reached out to the #design slack channel coz I know others have done great stuff with story boarding.

Someone shared open peers for the images of the people on the story board, it was easier than I thought.

Someone else shared a had drawn 6 frame story board of the whole journey.

With these as inspiration I went for it. Started drawing a few frames, shared what I was thinking with the product manager and then talked though what might come next. Talking it though helped.

A zoomed out view of a black and white story board with characters talking to each other and looking at a laptop. You can’t read the words because they are intentionally fuzzy.
The story board using open peers images done in lucid spark

Once I got going on it it was really fun to follow the story and think about where it could go.

Someone suggested I could have a row underneath to say which tools are used when and highlight points.

What was hard?

Design histories

Last week we were shown that DfE was going to use strapi for design histories. But I think we need a bit more guidance about how we structure out posts. I also think it would be better if there was tagging so we could start to see patterns in how we’re solving the problems. I chatted this through and will raise it with the team bringing the new CMS in.

It’s a huge step forward that they are editable by anyone not just interaction designers who know how to use the design system.

Knowledge management

It’s a bit daunting how scrappy we’ve been about where we save things. Pulling them all together into a good order is going to be a yucky job.

What did you enjoy?

Sharing patterns

Another team are solving quite similar problems so I shared my thinking on patterns. The work is starting to make sense because they could make use of what I’ve drafted for our service.

I’ve learned that while the high level ones that I drafted at first have some use the more specific ones on how we’ve implemented login are probably more useful.

At some point I’ll do a post about how I’ve approached patterns, but for now, here are the titles I use to document each on:

  • Title
  • Intro
  • As a external user I need to
  • As a internal user I need to
  • How xx works
  • Example of xx in use
  • When to use xx
  • When not to use xx
  • Research on xx
  • Tech stack under xx

And the list of patterns that I’ve tried to define is:

  • Ask for something
  • Ask about something
  • Send something
  • Identify yourself
  • No Log in
  • Log in to prove eligibility or save
  • Identifying staff users
  • Non digital channels
  • Check or build requirements
  • Create a spec and Tech audit
  • Receive something
  • Check something
  • Decide something
  • Choose — Similar to decide?
  • Define
  • Plan
  • Book
  • Audit

Defining biggest areas of improvement

Thinking about assessment and finding the 5 or 6 biggest problems that we’ve solved — well worked on — during private beta was cool. We decided on:

  • trialling new core products because there was not always a solution for users
  • making documents more accessible
  • making a bespoke entry point for the most frequent type of case to improve efficiency
  • improving the case management system for internal users
  • trailing ways to get more cases through digital channels
  • defining the service better so we can set expectations well

One thing we probably need to think about a bit more is what other teams have done because it’s the whole service that’s going into assessment not just the digital tools.

On a call with operations team a member of the team (HM) was really grateful for how many improvements there were to CMS and how new features they didn’t even know they wanted were super useful. It was great to hear.

Feedback from operations

After a phase of working out how we work best with the operations team this feedback was lovely to hear ❤.

Following our Thursday meeting yesterday — this is a big note of thank you to everyone who has been working on making the changes we’ve asked for in CMS, from all of us in Ops.

The usability of the system has improved a lot in the last couple of months... The case statistics page and the ability to interrogate this data and it taking you straight to the list of the cases in question is game changing from a team management point of view, this and having the quick links to check the level and stage have saved me hours this week compared to previously. And obviously we love all the PowerBi Dashboards.

I think another change I’ve seen in the last couple of months is the communication between us all to prioritise and get some of the things communicated effectively and delivered which makes meetings seem less fraught and much more effective.

What did you learn?

The process of defining work to put it into sprints is getting easier and easier and I can see the value in it so that I know what I need to and don’t take on too much.

Who did you talk to outside of your organisation?

Spoke to an interaction designer and it was sad to hear that talking about problems was discouraged in their area.

Also spoke to some devs who are growing their team about the types of roles they need.

What are you looking forward to next week?

Getting feedback on my visualisations.

What are you reading?

All our yesterdays, book club book. I’m half way though, I’m finding it hard going because the style jars with me a bit.