A simple framework for Service Design teams
Four methods to solve four problems

Service Design is not a mysterious world. It’s user-centred design at scale; bringing together user, colleague, business and tech needs in one giant design iceberg.
And just like any user-centred design methodology, you start with the same question — What’s the problem we’re trying to solve?
Why have a methods framework?
Oftentimes, Service Design methods get over-complicated, with teams applying every toy, template and canvas in the box to projects that frankly don’t need them, or worse.. treating every project as a convergent JFDI mapping exercise to show what (something the business has already decided it wants) would look like.
Scenario 1 — Method bloat
Service Design agencies, or consultancies in general are more likely to get involved in blue-sky projects where time, money and technical limitations are not front-of-mind. This means you can play with all sorts of things, and often do so to make design ‘exciting’ to clients.
This is not the best approach for every project on every occasion.
Scenario 2 — JFDI
JFDIs are particularly likely in in-house roles where you deal with business reality and delivery pressures every day. When working in-house you are less likely to be designing a service from scratch every day, and more likely to be developing, improving or iterating parts of an existing service. Sometimes you have to fight for anything to be done in a remotely user-centric way.
Note: not every company has the UK GDS Service Design Standard (or regional equivalent) and associated operations in place. Many of us have to muddle through. This article is for the muddling-throughers.
The solution
Most teams need methodologies that flex for both scenarios, whilst keeping users, customers and colleagues involved in the process.
To offset either scenario described above, I have developed having a simple methods framework which allows a Service Design team to easily triage every project into the right UCD methodology, depending on project and stakeholder needs. This makes working practices more consistent, limits method creep, and ensures user-centricity.
This makes your working practices more consistent, limits method creep, and ensures user-centricity.
What are the four methods?
Working with my current team, we have established that every project, more or less, falls into one of the following methodologies.

1. Fix
Fix is for things that are on fire, where the resolution is fairly straightforward. Here you might even (gasp) not necessarily need to do user/customer research. It might be as simple as a missing communication, content type, or back end process and you just need to understand enough of the wider implications to build it into an existing journey.
Yes, this aligns to the JFDI approach described above, but bear with me.
You might find other issues along the way, but you are a crack team with a focus. Get ‘er done.
- Complete your understand phase as quickly as possible — check the major assumptions
- Engage stakeholders in short, collaborative iterative cycles (or lock them in a room if needed)
- Create a single-point of truth such as a journey map or blueprint
2. Mitigate
Mitigate is for when something is decided (usually from on high) and there’s a concern that there will be implications and a ripple effect of negative impact for technical debt, customer experience, or business outcomes.. or all three.
Here you are looking to conduct a damage limitation exercise. You have permission to raise risks and red flags, so not a JFDI.
- Engage multiple stakeholder groups and departments
- Map risks, pain points and assumptions
- Size any significant risks
- Prioritise accordingly in hand off
3. Optimise
Optimise is about improving a service root-and-branch. Here you are going to understand the service insight-out, from colleague challenges to back end issues to customer pain points — across every channel. And then you’re going to work to systematically improve it by identifying and prioritising vitamins and painkillers.
You are not going to do either a JFDI or a massive ideation piece. It’s a sensible and systematic approach to making something better.
- Broad-reaching understand phase across multiple touch points
- Get buy in for research that identifies unmet needs
- Be ready to communicate quick wins and opportunities (eg to move into “Innovate”)
- Run prioritisation via impact/effort matrix or similar — and size the prize
4. Innovate
Finally innovate which is reserved for scenarios where you are taking something new to market, or radically overhauling an existing service.
Here you are asking — What does good look like? Where are the gaps in the market? Why do we have the right to go there?
This might involve more creative workshops and co-creation with customers and colleagues but does not at all mean that the methodology takes longer or has less accountability for actually going live than the other methods.
- Discovery phase to include competitors and opportunity/white space
- Focus on clarifying and getting alignment around business ambition and desired outcome
- Use a business model canvas (new service) or an opportunity canvas (existing service)
- Balance business ambition and technical limitations
- Stay grounded in solving real customer problems and value proposition
- Engage the right stakeholders in ideation and testing sessions
- Ensure solid business casing to prevent project stagnation
- Get an MVP out there to test and learn (focus on “viable” being something actually of value to customers)
Want more detail on the precise method approaches? Subscribe to my Gumroad page, as I’ll be uploading there in due course.
As you can see above, the first supports a JFDI scenario, the fourth is your blue sky innovation. The middle two allow for the reality of many projects which are neither end of the spectrum.
Why not design each method from scratch?
Yes, obviously mature teams can build their own methods from scratch. That’s not who this is for.
Mid-maturity teams, or seniors within a low-mid maturity team should be able to use the methods as a framework and build them out as needed, adding techniques and tools and adapting based on stakeholder and project needs. When a team is regularly doing this, you probably don’t need the framework anymore.
The aim of the above is to give a strong framework and structure to a less mature Service Design team, or those working in a less mature product ownership environment.
What if you don’t know enough to work out which one?
Although each of these methods includes an understand or discovery phase, it is entirely possible that you don’t know enough about the problem space to choose a correct method.
One option is to guess, start the project and then pivot methodologies as you go.
The other is to conduct a higher level discovery phase up front. This will allow you to identify whether it’s one project or problem space (and which method is suitable), or whether it is or could be multiple work streams, each fitting into a different category and needing a different approach.
What are the benefits of this approach?
As stated above, these are for low-to-mid maturity Service Design teams, and especially those working in low-mid product or service maturity environments.
They could be used either by in-house teams or agencies depending on the problems you are tackling.
Again, if you are a team of absolute experts working in a top digital, user-centric org then these are probably not for you.
However, if you are the type of team I’ve described in this article, here are some benefits you may experience when triaging projects and requests into these methods:
- Product Managers/Owners know what SD service or approach they are buying
- Service Designers know what they are delivering
- It’s easy to tell when a project is changing
- You can still adapt/amend as the project progresses so long as you are communicating regularly and clearly
- It builds such consistency that anyone can pick up anyone elses’ work within the SD team
- All in-scope activities are planned and understood from the outset
- You still can iterate a service from one level to the next for continuous improvement
- Works well at a whole-service or journey level
Will this work? It depends..
Now this assumes that your organisation is anything like mine (never assume). One thing I re-learn with every organisation is that you have to adapt and iterate on methods that suit these stakeholders delivering these products to these customers in this organisation.
You can’t just take a book off a shelf or a method of the internet and expect it to work perfectly first time.
But test & learn should come naturally to any designers reading this.. :)
You made it to the end — Well done! If you want to see new articles when they’re published you can 👉 Subscribe for free.