Creating simple user personas

Photo by Daria Nepriakhina on Unsplash

Personas are a great place to start with user centred design, particularly if the whole practice is new to your organisation. This is because they can provide a quick and cheap way of ensuring your project puts the different types of user at the heart of your service design process.

Personas are fictional representations of the different types of potential users of your service. Well written ones can bring the important user types to life, which is why it helps to make them as realistic as possible. They also help to give the project team focus, by constantly reminding them of what really matters to their users. Finally, they are a great way of engaging stakeholders with your work, introducing personality and something relatable.

They can have their downsides though:

  • often personas aren’t based on user research, but assumptions
  • they can sometimes focus on what user’s want rather than what they need
  • they can get stale quickly – don’t fall into the trap of not updating them or using the same personas over and over again
  • They should not be the only form of user centred design that is used in a project – personas are not a shortcut or a tick in a box

So make sure you use them properly, and most importantly of all – do your research first!

To make your life easier, here is a simple template to use for your user personas. Feel free to amend it in any way you like to make it work for you.

Hope it’s useful!

Matching user needs with tech capabilities

Photo by Patrik Michalicka on Unsplash

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

Photo by Felipe Furtado on Unsplash

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!

Communicating customer access

I’m at Channel Shift Camp in Birmingham today, organised by my good friend Nick Hill.

It’s an opportunity for people involved in customer services in the public sector to talk about ways of delivering services using new channels, such as online.

The point for organisations is that online channels tend to be a lot cheaper than phone or face to face; for the customer, hopefully the experience is quicker and more convenient.

The first session I attended was a very interesting one about how to communicate the benefits of using new channels for contacting councils and so on to users of services.

The problem was soon identified of the quality of the new service being sold. Often the user experience of online public services is pretty bad – to the point where most people would rather phone up or turn up to an office than try and figure out how to use them.

After all, think about the big, successful online services, like Google’s search engine, or Facebook, or Amazon. When have you seen an advert, or a poster, trying to convince you to use them? Probably never, and yet we do in our millions, because it’s better.

It was mentioned that it might be possible to ‘nudge’ people into using online channels by doing things like hiding the organisation’s phone number and address on the website, so people have to use the web service.

That is not nudging! It’s bullying.

Users ought to be able to access a service in whatever way they prefer to. The job of the organisation delivering that service is to design it so that their preferred channel is also the one their customers would choose.

So to start with there is a need, I think, for communications folk to challenge those asking them to promote a service to ensure that it is actually an improvement on the traditional alternatives. If it isn’t, then trying to persuade people to downgrade their user experience is not really a goer.

In other words, the service ought to sell itself. To do that, it needs to be designed with the user at the centre, meeting their needs and solving their problems first, and not those of the organisation.