Journey to Improving Planning Alerts: A Service Designer’s Perspective – Part 3 Toolkit for Service Improvement

Guest post by Service Designer and Researcher, Sabina Popin

This blog post is the grand finale in our three-part series on the recent Planning Alerts Service Improvement project. I kicked off the series with a bird’s eye view of the project, and the sequel dove deeper into the approach, research, insights, opportunities, and concepts. Now, let’s shift the spotlight onto the nitty-gritty – the outputs of our work and the fate of these insights.

Oh snap we created Service Principles!

In the process of identifying key opportunities for service improvement we generated How Might We statements. A method of creative questioning that can then be used as a prompts for generating ideas. 

While we did indeed use them to help us generate our short term concepts for improving the service, to our surprise these statements also echoed some profound truths about how the service should operate. At first I wasn’t entirely convinced on what to do with these statements, conscious of not creating more artefacts that might add noise and confusion for the team. By being open about this with the team it became clear that some much needed Service Principles were taking shape. A set of aspirational instructions that would support design, development, onboarding of new staff and collaborators, and decision making that aligns with the core intent of the Planning Alerts Service. 

We dived headfirst into the details of these principles, which shone light on what the Planning Alerts team implicitly believed about the service. Through this process we found that some earlier principles crafted to support Development Design now had a new home – right next to Service Design principles. Three sets of principles emerged:

  • Experience principles: How we want the service to feel. 
  • Purpose principles:  Core values and intentions of the service.
  • Delivery principles: The “how” of our service delivery.

The emergence of the Service improvement toolkit

During the research synthesis process I plotted the user needs onto the different stages of the user journey to understand people’s needs in the context of where they occur when using the Planning Alerts service. This was the moment a new kind of map formed – a map of service improvement opportunities. We found gold in this all-in-one map that encompasses insights about individual, organisational, and planning authority needs, opportunities for improvement, and ideas for those opportunities. Usually, these elements would need different maps.

All-in-one Service Experience (Improvements) Map

A couple of factors led us to believe that such an all-in-one map was the right thing. 

At Planning Alerts the key decision makers are also the same people who are implementing the decisions. They need a tool that’s a Swiss Army Knife – determining strategic focus, stirring up solution discussions, and being a nest for future feedback.

Designing this jack-of-all-trades artefact posed quite a riddle for me. With so many functions, it risked becoming an overwhelming info dump, leaving it gathering dust. I shuddered at the thought of our hard work and precious insights being lost in the labyrinth of a poorly designed artefact.

This called for some good old fashioned back to basics information design hierarchy, but most importantly it called for ongoing collaboration with the team to ensure they knew the artefacts back to front, and developed a sense of ownership that would allow them to continue using it. 

Triaging new feedback

During the map creation process, we realised that the team needed a way to differentiate between issues that could be addressed right away and those that needed further analysis. As valuable as Github is for tracking immediate tasks, it’s not as well-suited for issues requiring extended discussion and evaluation.

And there’s no lack of feedback — with the new user account features, we have more comments, more blog posts, more emails, and likely even more feedback as we implement new changes. So, we were faced with the question: What should we do with these new issues?

We needed a way for the team to to organise these incoming pieces of feedback, opportunities and ideas, and to know how to use them to build on the needs that have already been uncovered and are housed in the Service Experience Map. This led us to experimenting with a triaging process for any new issues or feedback that cannot be actioned immediately, so they don’t get lost. 

Ok these sound great, but how do we make this work?

“We need a guide, some ‘how-to’ instructions!” was the consensus. And so, the toolkit concept was born. It will be an experiment, of course; we can’t guarantee it will be as beneficial as we hope. This led to an agreement on continued engagement: I’d work with the team once a week for at least the next three months, helping them iterate and integrate the toolkit into their strategic and daily decision-making processes.

Where to from here?

Short term improvements and Github

First up, we prioritised some concepts that could be implemented right away to address recurring issues. These small changes have the potential for a big impact. The Planning Alerts team already uses Github, so I logged these ready-to-go issues there. Integrating this process was extremely valuable; it helped me understand the level of detail required for a concept to be actionable and more importantly, how to weave user insights into the final design and features of a concept. I was watching the insights come alive.

Next, the idea is for the team to act on prioritised concepts, determining what they want to track and measure before implementing. This will allow them to evaluate new features against these metrics and make improvements based on feedback.

Ongoing strategic decision making

Having the support of myself or another service designer on an ongoing basis will help ensure the artefacts in the Planning Alerts improvement toolkit become a regular part of strategic conversations and decisions about the service.

Over time, they’ll need to continue working through the User Experience (Improvements) Map, making improvements at both the incremental and the bigger picture level. Part of my ongoing engagement will involve helping them cultivate a habit of using the Miro board and artefacts for strategic conversations. Additionally, they’ll need to start incorporating medium- and long-term improvements into the toolkit to make it an integral part of these strategic discussions.

A service designer on the team ongoing will help them refine their service principles, integrate artefacts into the onboarding process for new staff and collaborators, conduct ongoing research with users to understand evolving needs, and work with council and planning authority staff to better understand their needs and potential improvement opportunities.

Unique Challenges Require Unique Solutions

The chance to continue working alongside the team beyond the project and become true partners in the work is the greatest highlight for me. While it’s a service designer’s nightmare to see valuable insights go unused at the end of a project, the dream is to be there from the start — from research, strategy, and ideation through to implementation and beyond.

So, faced with unique challenges, the Planning Alerts team had the ability to be flexible and a willingness to try new approaches. This spirit of improvisation and adaptability were key assets in the success of this project, serving as a powerful reminder that no team is too small to make a substantial impact. Size and resources are only part of the equation – collaboration, creative thinking, and resilience play a crucial role in the success of any service design project.

This entry was posted in Planning, PlanningAlerts.org.au and tagged , , , , , , , . Bookmark the permalink. Trackbacks are closed, but you can post a comment.

Post a Comment

Your email is never published nor shared. Required fields are marked *

You may use these HTML tags and attributes <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*
*

Subscribe without commenting