The Planning Inspectorate

In a nutshell permalink

Three week secondment in Bristol as the UX/UI designer for four Google Ventures style ‘Design Sprints’. Set within two teams to plan, design and deliver working prototypes for the digital transformation of the government organisation.

• 4 separate Design Sprints
• Collaborated with Civil Servants, Inspectors, Directors, Senior Managers and Delivery Managers,
• Presented initial concepts to Stakeholders, Directors and members of staff were then taken forward to inform the technology stack and costing.

The MVP prototype

Nice things they said

We undertook a series of “Lightning Sprints” with the aim of developing prototypes that guide us towards solutions for known problems within the organisation. Darren was key to this work for two main reasons:

1) His remarkable ability to listen to what was being discussed and turn it into a prototype that matched the requirements of the user. Ideas moved from a rough sketch on a white board to a clickable prototype very quickly and with great accuracy. When changes were required (often because user realised that their requirements were different having used the prototype), Darren was able to make the changes instantly. Feedback from (a usually very cynical) staff has been universally positive on the quality of the prototypes.

2) His wider input into the sessions He wasn’t just a passive member of team but he helped to challenge and question during the ‘Sprints’; this allowed us to really pin down the user requirements and to prevent unrealistic expectations from developing. He was able to fulfil this in a very positive, constructive manner and it was a pleasure to work with him.

Tom Warth
Operational Delivery Transformation – Product Owner

I wrote about the process in detail to share with my team back at Door4.

The process (Long read)

I was part of a team of upto 12 Rainmakers +1 other subcontractor split into two teams, Bolt and Strike. I was primarily a member of Team Bolt, helping Team Strike when required.
There were to be 4 Sprints. We actually did 4.5 as we had some time to look at something that came out as a result of Sprint 4. They were broken down as follows;

Sprint 1 - (Strike) Submission and Validation - The frontend form that an appellant uses to submit their appeal to the Inspectorate.
Sprint 2 - (Bolt) National Infrastructure Template - Currently a Word based reporting tool that Inspectors responsible for large Infrastructure projects (ie Heathrow/HS2) use to justify their findings and create a 100s of page report.
Sprint 3 - (Strike) Inspector view - An area in the portal where an Inspector can find out their workload, map events and see a 10 weekly schedule. Also a place for all documents and communications with the case officer.
Sprint 4 - (Bolt) Case Management and Allocation - Used primarily to support the Inspectors before they go to events and to ensure the case managers can process the case through the various stages required for the appeal which also included...
Sprint 4 - (Bolt) Programming - Scheduling the Inspectors workload and time
Sprint 4.5 - (Bolt) Time Calculator - This wasn’t planned but we had some time towards the end of week 3 and decided it was an important part of the jigsaw of what we’d done in weeks 1 and 2. This was an automated calculator based on a matrix that they currently have as a number of spreadsheets depending on the appeal and case type.

Who was involved?

Overseen by the Rainmaker Client and Project Directors and answering to the Director of Transformation and the Board, each team consisted of the following roles.

The Decider / Product Chief (PINS Staff) -

Senior member of the PINS Digital Management Team tasked with approving key decisions and ensuring the output was inline with expectations and requirements for PINS.

Customer Rep (PINS Staff) -

Number varied depending on the Sprint but usually 3-5 members of the PINS staff from different areas and positions from within the organisation. Their role was to educate us with their current practice and how they thought it should change for the better.

Lead Facilitator -

Rainmaker who was chair of the meetings, ensured everyone had what they needed in order to carry out the sprint. Challenged ideas around cost, practicality and delivery. Kept everyone to the spirit and agenda of the sprint process, jumping in should the team deviate too much from the task in hand (this happened quite a lot some days).

Delivery Manager -

Ensured what was being proposed could be reasonably delivered as ‘MVP’ or what needed adding to the ‘Future’ list. Challenged practicality and cost of ideas and kept Sparkle Engineering* suggestions to a minimum.

Facilitators - 1-3 in each team

Responsible for capturing all the notes, stickies, whiteboard sketches, photos and creating video for presentations to show what had been done. Encouraged to contribute with ideas and sketches during the sessions.

Designer - (Me)

Contribute with experience, ideas, sketches and storyboards during the sessions. Tasked with bringing all the captured sketches, post-it notes, storyboards and ideas into a tangible clickable, designed prototype in InVision. Present the prototype to the organisation.

Engineer -

Technical expertise from a GDS (Government Digital Service) guidelines point of view culminating with a prototyping a live interface built out from the GDS framework.

*Sparkle Engineering was a term that was introduced early in the process by the Client Director and became synonymous with our thinking throughout. KISS (Keep it Simple Stupid) was another favourite.

Ok, thats the background. So, what happened then?

Week one was the Submission (Strike) and National Infrastructure (Bolt) Sprints.

I was part of the Bolt team along with 5 members of the PINS staff; a Senior Inspector, 2x Case Managers, IT Manager and a Validator.

Day 1
An introduction day and a day to capture the HMW notes (How Might We’s). These reframe the problems as opportunities. They are stuck to a whiteboard via post-it notes and voted on with the small dot stickers by the team to give a focus for the week.

Day 2
The day starts with inspiration: a review of existing ideas to remix and improve. In the morning we discussed the homework set on Day 1. Everyone was encouraged to spend some time finding similar solutions to the HMW’s from unrelated industries.

For example;
How well Netflix allows a user to navigate through shows, movies and favourites. Could this thinking be applied to documents/files and folders in our prototype?

Round the room we went and sites were suggested and pulled up and we spent the morning deliberating the pro’s and con’s of each with the person who suggested pointing out how they felt we could emulate the pattern demonstrated to meet our needs.

Then, in the afternoon, each person will sketch, following a four-step process that emphasizes critical thinking over artistry.

‘Each person will Sketch’. - This was the first pain point.

Despite our best efforts to assure them it didn’t matter how good they were, 3 out of the 5 members of the PINS team weren’t comfortable at all with showing their artistic abilities and were quite resistant to the idea of having to draw out their ideas.

The sketches were pinned to the whiteboards and individuals were given 1 minute to explain their thinking against the HMW’s from the day before. We then voted on the best ideas using small dot stickers. The ideas with the most stickers was considered critical to the success of the prototype and were to be the direction of travel when drawing out our storyboard which would ultimately be replicated in our clickable prototype.

Day 3
We all sketched, storyboarded challenged, changed and configured what would be on the screens for the prototype we’d be testing with the users on Friday.

Day 4
Taking the finalised storyboard from the whiteboards we made a start on creating the prototype which would be tested on Friday. Artworked in Sketch and linked together using InVision, by the end of the day we had a clickable ‘good enough’ prototype.

A number of users had been scheduled with varying degrees of IT knowledge, age, experience and rank from the PINs organisation. None of whom had been involved in the Sprint process.

Myself and the Delivery Manager had some concerns about the tool we’d need to procure in order to meet their MVP user needs. The key ones being;

• Word processing
• Notes and comment tracking
• Multiple users at once on a single document
• Publishing to PDF
• Related file management and structure

After a late meeting on Thursday night with the Client Director and Project Director we all agreed there were products on the market that could deliver these features so, we continued with the testing as scheduled on Friday.

Day 5 - Testing the NI template

We allowed the testers to explore for themselves; explaining what the limitations of the prototype were. The test was captured using an online tool and the testers webcam with the facilitator sat next to them in a separate room or via an online conference if the tester was based remotely. The testers were selected by the onboarded PINS team to give the widest range of age and expertise.

We sat in our war room and contributed via slack and text message should the tester or facilitator have questions or need context as to why and where things were in the prototype. We wrote comments on post-it notes during the sessions, including recommendations, concerns and improvements.

In all, 6 user tests were carried out and all the post-it notes were added to a whiteboard for review after lunch.

After lunch all the notes were grouped as necessary;

• Similar notes
• Reasonable and actionable within scope notes
• Out of scope notes
• Future notes

All this was then captured by the facilitators and entered into a spreadsheet for reporting to the final output.

At the end of day 5 some of the key stakeholders came into the war room for a demo and to ask the PINS team how they thought the Design Sprint had gone (via an out of 10 points system). They were all very positive however their scores came in two parts reflecting our own concerns about the selected tool being fit for purpose. Also, they expressed the fact they were initially quite cynical about the whole process having been through various consultations over the years and nothing ever coming of it. They felt engaged and involved and mentioned on a few occasions how they didn’t feel their ideas were excluded due to their position or rank in the organisation.

Based on Futures they all said they’d give it 8/9 out of 10 as they knew it was dependant on the tool used could do what we suggested it would.

We repeated this process with different members of the organisation for the remaining sprints.

What I learnt

This was a very positive experience all round. After initial reservations the onboarded PINS team really got into it from day 3 onwards.

A key member and contributor of the onboarded team was the Senior Inspector. He was brilliant. He had sufficient IT knowledge and experience of the job to know what questions to ask and also understood that we could be limited by budget and that would determine the selected tool. A very expert witness (user).

All in all it was possibly one of the best working experiences of my career and I brought it back to our team to implement the ideas and shape our future process.