template – Dave Briggs

Quick and easy service discovery (with template)

This is a nice and easy framework to use when you find yourself needing to do a quick service discovery to find out some basic details about a service and how it can be transformed.

The point at which you might want to use this is right at the start of your digital work, when you either:

need to identify a service to work with
or have decided which service to work with already, but need to gather some up front information on what you’re dealing with

Whichever way you use it, you’ll find it a really helpful way to have a meaningful conversation with the service owner, that will help you get on the same page really quickly.

Here’s the template:

A preview of the service discovery template

How to use the template

Some quick notes on how to use this – although remember, you are free to do what you like with it!

Replace <Name of service> with… oh, you know surely
You can delete the link to this post to protect your reputation if you like
Add a quick summary of what the purpose of service is – both in terms of the user need and what the organisation needs to achieve
Consider the components of the service (whether tech or process based). Leave ticks for those that are needed and crosses for those which aren’t
How is the service currently delivered? Again, leave ticks and crosses in the right places
Think about the users of the service. Are they
- Everyday residents?
- People running their own businesses?
- Professionals working alongside the organisation, perhaps solicitors, architects, or folk from other public services?
- Politicians, whether at a local or national level
- As well as doing the tick and cross thing, add the number of people who use the service every month, to get an idea of the size of this thing
Finally do some quick analysis on three criteria:
- What would the level of benefit be to the end user if we transformed this service? Green for lots, red for little, amber for somewhere in the middle
- What would the level of benefit be to the organisation (savings, happier staff etc) if we transformed this service? Green for lots, red for little, amber for somewhere in the middle
- How hard would it be to transform this service? Green for easy, red for nightmare, amber for somewhere in the middle

If you are running this exercise before choosing which service to transform, this analysis will help you decide whether a particular service is a good candidate. If you’ve already fixed on a service to transform, the outcome of this might a) change your mind; or b) decide how to approach it.

Hopefully this comes in handy! Let me know if so 🙂

Matching user needs with tech capabilities

Something that I have found helps an awful lot is having a simple way to match identified user needs with the technology capabilities needed to meet them.

It helps in two main ways:

by encouraging people to consider the user needs they are trying to meet before thinking about technology solutions (always tempting, but dangerous!)
by reinforcing the message about capability-based technology delivery, as opposed to always thinking in terms of single monolithic systems

By considering user needs first, then identifying individual capabilities to meet them, it’s possible to come up with solutions that are more likely to succeed and can often be cheaper and quicker to implement.

A good example of when I used this was when I was advising on a new intranet project. The initial requirements list had all sorts of stuff in it – HR policies, telephone directory, social networking, better collaboration (whatever that means!), and loads of others.

I was able to break it down into the needs we were trying to meet, and then come up with the technology capavilities to meet those needs. I found that adding an extra translation layer betwene the teo – tasks – helped with doing this. Here’s an example below:

User need: I need to know if my pay will increase this April
Task: quickly and easily access details of pay grades and scales, via search or navigation
Technology capability: publish pages of content

Pretty obvious perhaps. But let’s look at another need:

User need: I would like to understand the organisation’s policy on remote working
Task: find and read a policy document
Technology capability: share and manage versions of documents

Now, traditionally both of these things are requirements for an intranet. But broken down in this way, we can understand that we need an intranet to publish pages of content, but perhaps for the sharing of formal documents, a more specific capability is needed?

I then add a fourth column, which outlines the potential technology to deliver the capability. In the latter case, this could be a system such as Sharepoint or Google Drive, which may already exist in the organisation.

By following this process through with all the identified user needs, you’ll end up with a list of what technology you’ll need, along with a map of what you already have that can do those things, and where you have gaps.

To make it super easy, here’s a Google Doc template, with a worked example for the intranet, that you can copy and make use of.

Hope that’s useful!

Creating good, simple user stories

User stories are the strongest way you can capture requirements for your digital service and are another key component in taking a user centric approach to design.

Rather than the old way of doing things, of producing a specification document outlining every single feature that a product needs to have, user stories focus on the needs of the users of that product, and specifically on their outcomes.

This focus goes a long way towards producing services that are usable and deliver end to end, rather than breaking down halfway through because a feature ‘works’ technically, but doesn’t do what is expected or needed.

Additionally, user stories can be a great way to bring a product to life when describing it to stakeholders. It really demonstrates a new way of talking about digital services and technology, and can be very meaningful to non-technical folk, giving confidence that you’re doing the right thing.

In a multi-disciplinary team, the user stories are usually the domain of the product manager, written with the input from the rest of the team. If you don’t have all the roles in your team, then do try to have a single person responsible for the compilation of user stories – and try to have someone non-technical doing it, to avoid the temptation to leap into solutionising too soon.

Writing a good user story follows a certain format:

As a…
I need to…
So that…

For example:

As a new, and busy resident who drives to work in the town centre
I need to apply for a parking permit online
So that I don’t run up loads of parking fines

That’s quite a high level example (often referred to an ‘epic’ story), so we can probably come up with a more granular user story:

As a resident who has applied for a parking permit online
I need to be proactively kept informed of the progress of my application
So that I don’t need to keep contacting the council

Note that the user story doesn’t explicitly state here what the solution is. The focus is on the outcome that the user needs, not the technology that will enable it.

The technology is likely to be mentioned in the second main element of a user story, which is the acceptance criteria. These are descriptions of what done looks like for this story. The GOV.UK Technology blog shares a nice method for writing good acceptance criteria, based on the pattern ‘Given… When… Then…’.

Additional information for a user story might include the prioritisation of that story, so the team know how important it is to get that story completed, and also the size – how much effort is likely to be needed for the story.

Here’s some tips for writing good user stories:

Keep them small. If they start getting to wide in scope, treat them as an epic and break them down into smaller stories
Avoid the temptation of repeating your ‘I need to’ in your ‘So that I can’ – which is a really common error. For instance – ‘As a manager, I need to access my team’s performance dashboard, so that I can view the perform dashboard’
Don’t treat individual technical pieces of work as user stories. They might be important to the project, but that doesn’t mean they directly contribute to meeting a user need, and doing so can clog things up and spread confusion about what the outcome of the project is intended to be
Try following the INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable) formula for producing good user stories. It’s a handy framework to ensure your stories are what you and your users need. Read more about that here.

To make life easier, here is a simple template for writing user stories. Feel free to amend it any way you like!

Hope it’s useful!