How many people does it take to design and build a service?

Reading Time: 5 minutes

Scottish Enterprise is changing. We are delivering services to customers and stakeholders in new ways, this gives us a fabulous opportunity but also presents some challenges.

As the team leader for the user centered design team at Scottish Enterprise I hear comments such as ‘What do you mean when you say service’, ‘We don’t really know what you do or who you are’ and also ‘But don’t you just build websites? Why do you care about all this other stuff that’s not digital?’

It prompted me to think what was causing this perception and how I felt four years ago when I joined the digital team at Scottish Enterprise. I was struck by how many people are involved and therefore how confusing it can be.

What do our stakeholders care about?

Stakeholders care primarily about what’s above the ‘visible delivery’ line. Let’s look at our recent Green Jobs call for funding. The iceberg analogy is a good one. On the face of it the needs are straightforward:

• As a customer I can check my eligibility
• As a customer I can complete my application
• As a staff member I can process the application
• As a stakeholder I can see the management information I need to monitor performance

Simple……right?

We know that customers do not care who is delivering the service or what part of the organisation you happen to sit in. They just want to achieve their goal. This is a universal truth that you can read more about in the Good Services scale.

We also know that designing any service in the right way requires thinking and experimenting before we even get to build something. Much of that work is unseen (rightly so) by end users. However, as it is unseen, it can mean that everyone underestimates the scale of work needed.

So, getting this right is important, for both our staff and our customers. It takes a lot of people and different skill sets to design the right thing, and then build the right thing.

How do we design the right thing?

At the beginning we need an early look at what we think the service is, what it could be and even if it is needed.

In these early stages it feels familiar to talk about ‘gathering requirements’ or ‘mapping a process’. It’s maybe less familiar to consider a blueprint for the service (akin to a blueprint for your house), and to start to ‘sketch’ what it could look and feel like. The power is bringing all the capabilities that are needed together into a working team. Each person brings their own perspective. What everyone’s job title is really shouldn’t matter. This is where things can get confusing.

As an example business analysis and service design are two sides of the same coin, bringing complimentary skills to the same problem. You can read more about this example in a blog by Ben Holliday. You might sit in a meeting with a business analyst, solutions architect, service designer, UI/UX designer or user researcher. We could all make a change, by introducing ourselves not by our job titles, but instead the skills we bring and why we are there?

The team should be able to:

• Help the organisation understand its operations and how they relate to its strategy
• Break down services into all the people, products and interactions that make them possible
• Understand the needs of people and the organisation to make something that is usable by everyone
• Focus on people’s visual experience of an application or website
• Create the correct words that describe what a user must do to achieve their goal
• Get feedback that is unbiased directly from users of the service, both external and internal
• Work with customers and subject matter experts to design the service together
• Make sure users of the service can find it and use it

The team do the hard work to make things simple, and as a team they will know when other skills are needed.

How do we build the service?

There is little point working away designing something that no one can build. Manufacturing businesses have known this for a very long time. Manufacturing experts get involved early with product design teams to ensure that any changes they need to make to a production line are considered early.

When I first joined the digital team, people threw names at me and I had no idea what they meant. Developer I thought I knew until I realised we had a few different types. Testers kind of made sense as the clue was in the name. Scrum master, delivery manager and various other terms just confused me. Looking at the skills that they bring is simpler:

• Build and maintain the technology that powers the websites, applications and databases that are needed. Make the connections between these things work securely.
• Develop the digital parts of a service that people see and interact with. Use code to create the right buttons, font, and colours.
• Make sure everything we do is usable by all, secure and of a high quality. This means testing on a variety of devices (desktop computers, mobile devices and tablets), with different browsers, and making sure things like screen readers also work.
• Make sure data can flow through the whole service, and can be used for accurate reporting.
• Check that everything we do is secure, that data is protected, and that we can withstand cyber-attacks.
• Plan how we will run the service in live – how will we make changes to it and how will we fix things if they break.

All these capabilities come from a variety of job titles.

Who else is involved?

So many people from different parts of the organisation are needed to design, build and then run a service. As well as the skill sets mentioned already, we also need people who can:

• Help staff learn and understand new processes
• Handle queries from staff and customers, and fix problems quickly
• See how users are moving through the service, and any problems they are finding.
• Tell customers about our service
• Ensure everything is delivered

And there is one person in here that I haven’t mentioned yet, and that’s the product owner/product manager. It doesn’t really matter what they are called but what they do is critical. They keep everyone aligned to a common vision and motivate them towards achieving it. With a team that’s as big as this one, you can now see that role is critical.

What’s my takeaway from this?

The original question was how many people are needed to design and build a service. The answer is lots!

So as we start to deliver services in new ways there are four things that we should all consider:

1. Get in and do good stuff– don’t explain every nuance of your skill or your colleague’s skills right at the start.
2. Use plain English – everyone should do their best to translate what they do into terms everyone can understand. Great posts on design-isms already exist.
3. Communicate – build trust across the team through using an open approach and all channels available to you.
4. Have fun – we should be able to have some laughs along the way. If you aren’t, then look at why. Fun and creativity go together.