As service design has become a more prominent role and way of working for organisations I’ve seen some confusion between ‘service design’ and ‘business analyst’ (BA) roles.
Service design and business analyst roles have some similar skill sets, but they require a different type of focus and mindset.
As I’ve spoken about service design over last few years a number of people have told me that they are business analysts and that they do the things that a service designer does. I’ve especially heard this a lot working with government organisations in the UK. I’ve also seen service designers working more like business analysts which doesn’t always help the teams or organisations they’re working with.
To look at this in more detail I’ve written a breakdown and comparison. These skill sets are why I think that both roles are invaluable to teams working together to deliver and transform services. Both roles do complement each other. But equally, I think it’s difficult for the same person to cover both of these roles at the same time because of the different focus and mindsets required.
A breakdown of roles, skills and mindsets
This breakdown is based on my own experience of working with business analysts and as a service designer. I have experience of both these roles across different sectors, including public and private sector work. I’ve also compared notes with the detail for both roles in the UK government’s Digital, Data, and Technology profession, as well as referring to work that FutureGov has done to define digital and service design roles for government.
Learning to recognise what you’re missing
As an example, when working with teams over the past 5 years I’ve seen the following scenarios:
- Service designers working too closely with business requirements and getting drawn into working predominantly on detailed documentation or product-level specifications. This can lead to teams losing sight of the bigger picture of how all the parts of a service need to work together in order to work for an end-user and for the service to operate effectively.
- Business analysts designing solutions but not working from an end-user perspective. This can lead to teams not thinking beyond how a service or business model currently works and limiting themselves to service improvements constrained by maintaining what is seen as business as usual, and an inward focus on the internal impact and cost of any future service changes.
In the first situation, a service designer is acting more as a business analyst. In the second scenario a business analyst is acting as a service designer. In both scenarios the overall service design focus has been lost.
Both scenarios are the result of not having the right balance of skills or experience in a team, and I believe that it’s important to recognise if teams are missing skills and experience from all of the aspects I’ve listed across both service design and business analysis.
To be clear, this isn’t just about hiring the right roles. It’s having people in your team capable of applying different skill sets, recognising the mindset switch required when working predominantly from a users perspective versus working from a business, technical or operational perspective. This is why when approaching a service or project discovery and framing the problem I’ve always found it important to have people in the room that can help us find a balance and understanding from both view points.
If you’re a large organisation it’s likely you have analyst roles or skill sets already, but much less likely you have people that can apply a design mindset, or who have the skills to embed user centred design into how you transform or deliver future services.
If this is your organisation, I hope that you can see the importance of service design as a set of skills and a mindset that is distinct from any other analysis type roles that you may already have in your service or operational teams.
This blog post is also published on Medium.
Ben Holliday is an experienced designer, leader, writer and speaker. This is his blog (started in 2005). You can follow all of Ben's blog posts by subscribing to the RSS feed, or follow him on Twitter for more regular updates.