If the team hasn’t worked together before it can be useful to break down barriers and develop a shared understanding of what people want. Give everyone a pad of Post-Its and ask them to write down:

If you’re working in a short timeframe, it’s important to remain focused on a longer-term goal. This tactic is useful if you aren’t sure that you are going to setup a single project or don’t have a clear brief to work to.

Local government services can be complex. Often we only provide part of the service that a resident needs. For example, we provide a service to enable residents to apply for a school place. But before they can do that, they want to understand which schools are right for their child. Mapping the customer journey helps you understand the whole process, including elements that aren’t covered by our service today.

You can accelerate your understanding by interviewing just four different experts. Try to interview them as a group to develop a shared understanding. If that’s not possible, then make sure the interviewer presents the findings to the group.

One of the key challenges in any piece of work is understanding the real problem that you’re trying to solve. For example, are customers not using computers to access council services because they don’t want to, don’t know they can, don’t know how to or don’t have access to the technology?

Personas can help give an identity to the types of users we’re working for, and bring to life their needs and challenges. Talking about them collaboratively can help a team with different expertise develop a shared understanding of what they need to do.

There are lots of good ideas that just don’t work in practice. Sometimes that’s because the people providing the service don’t understand how people use the service. For example, Facebook only made its mobile app really good when Mark Zuckerberg, the founder, banned access to the desktop version in Facebook HQ. Forcing staff to use the mobile app meant they understood what wasn’t working.

It can be easy to jump towards specific solutions before you have enough evidence to be sure that any one solution is right. Once you have a solution in mind, it can be increasingly difficult to see its flaws.

It’s important to involve the team in decision-making, partly to reassure everyone that good ideas which you don’t have time to focus on won’t be lost. Getting people to vote through a show of hands can be difficult in a hierarchical context.

Vision statements traditionally take a long time to develop. However, it can be useful to have a shared vision across a team of what you’re trying to achieve - particularly if people haven’t worked together before, or if part of the team has already developed a view of what the solution should look like.

It can be particularly hard to solve a problem that you’ve experienced for some time. In public services there might be a shortage of innovation or inspiration from other organisations. So it’s useful to look at very different services to understand what they do well, and what you can learn from them.

People often have lots of existing ideas of how to solve a problem. When they’re described it can lead to confusion.

Create a storyboard to show the service or product from start to finish

User stories are a device for capturing what the user needs from the solution. By explaining what the user needs, it enables a designer and developer to work together to find the best way of meeting this need. This can be preferable to detailed documentation that can inadvertently add extra complexity or fail to explain what you really mean.

There are lots of ways of prototyping- from drawing pictures of what something might look like, wireframing or developing the web interface that a user would use, without the data or software integration that might be delivered in a full working service.

If you interview just five users, you will get important insights about how your product works. The following are essential to ensure that you get valuable insights from the interviews:

Our services are conditioned by the business and legislative rules that determine how we can design something. The ‘gherkin syntax’ provides a common way of capturing these in a simple format.

One of the difficulties of group-working is how rapidly people cluster around a solution. Often they’ll disagree vehemently about the details, but agree about the broad framework. This agreement helps you make rapid progress together, but makes it harder to view a potential solution from a more critical perspetive.

The closer a team works together, the greater the opportunity for friction. If this is left unaddressed it can slow down, or prevent progress on a project. Equally, if the project does not have the full commitment of every team member, it can lead to resentment. At the end of each phase of work it is valuable for the team to assess its performance and air any challenges.