When I first started out at Stockport Council I had very little knowledge of what Service Design really was. I had a degree in Industrial Design and initially applied for a role as a User Experience (UX) designer, but a fellow Brunel graduate suggested that I would be better suited to join them as a Service Designer. Looking back on it now, I am glad that this happened. The UX team in Stockport is extremely talented and it would have been a privilege to work with them, however, I have found that my talents lie more in the field that I have found myself in.
I initially felt that being a service designer would be very similar to being a product designer but with less tangible outcomes. And for the most part, this is true, as we all follow a similar process (usually something similar to the Double Diamond process that we all know and love).
Learning Point: As usual, the devil is in the detail. Designing services is a much longer process that focuses more on gathering lots of insights whilst speaking to as many different stakeholders as possible. Product design tends to be more focused around developing and testing several ideas to find what is the best fit.
Learning from the team
My first project was not a small one by any means. It was one that had an internal focus and its main goal was to redesign the business support functions within the council to work more efficiently and to make savings. The team consisted of myself, members of the Business Support service and several Business Analysts (assisted where required by UX and Content designers).
At the start of the project, I have to say I felt out of my depth. It was a steep learning curve but with the help of our fantastic Design team I managed to figure out a direction that I was happy with.
We started by speaking to the different area managers within Business Support to establish what work they were doing across their different teams. After 6 separate workshops we created a mind map that displayed all this work:
This process also helped us to pull out specific areas that needed process redesign and we identified those that we considered to be ‘quick wins’.
Learning Point: I initially wasn’t keen on the idea of a ‘quick win’ as I felt the term itself implied that you were rushing the design process. With experience, I learned that it was not about rushing something out, but about finding something along the way with a high reward to time ratio.
Some of the ‘quick wins’ proved to be more complicated than we first thought, but the service took to the redesign with enthusiasm, giving us the opportunity to make smaller scale changes whilst building towards the bigger structural piece of work that ultimately led to them achieving large savings.
Learning Point: don’t feel like you have to do everything yourself. If someone has a particular skillset that you don’t possess, follow their lead and learn from them. It doesn’t make you a worse designer because you don’t yet know the ins and outs of a particular piece of software. Always be willing to learn.
The design tools we use often bring huge value to the service, helping them to better understand the way they are working, or how their users interact with them. However, as the service design process has become more widely accepted across the council, sometimes artefacts such as mind maps, process maps, journey maps, rich pictures or personas, are requested by a service before we even start the Discovery. I’ve had to learn to manage these expectations and my go-to response now is: “if we find that our Discovery points us in that direction, we’ll certainly look into it”.
Learning Point: Design artefacts may be seen as a quick solution by some services but as designers, we know that the work that goes into them can often be considerable, so you have to ask yourself, will this bring enough value?
Learning from external peers
On my second major project, the Financial Landscape project, we were supported by the FutureGov consultancy in our Discovery process. This was the first time I had worked with other Service Designers on a project over a long period of time and I learnt a significant amount.
We followed their lead on this huge project, and I have taken the basics of their approach forward into how I approach projects now.
Learning point:
- create a research plan
- establish who the different stakeholders are
- establish what teams make up the service
- find out what each of the teams does (pain points, processes etc.)
- ideate as to how we can help them improve these processes
My first opportunity to use what I had learnt was to run a small-scale Discovery on the ‘Bulky Waste’ service, with the aim of identifying areas for improvement. Working with an incredible Business Analyst, we started by speaking to the different service stakeholders (finance and service specific) in order to create an as-is process map that showed the different areas for improvement.
To get a better understanding of the users of this service we ran a Persona and User Journey Mapping Workshop with the service personnel. We produced a basic (crudely drawn) user journey and set out to do some guerrilla testing with residents, asking them to comment on what they thought of the experience and how they felt it could be improved.
In practice this was not as useful as we had hoped. I should have expected that most people were not particularly interested in the subject to give much useful feedback, though with persistence we did manage to find a few residents who were willing to have a chat with us.
Learning point: Don’t be disheartened if something doesn’t work out. If a workshop or activity doesn’t have the desired effect, don’t worry. Learn from it. And try not to make the same mistake twice. Over time you will develop your knowledge of what to expect from certain activities and you will discover what works and what doesn’t.
We presented our insights back to the service as a (very large) As-is process map. We showed the different teams the ‘How Might We’ statements we had created for different areas of improvement. We asked them to think of ways in which the service could be improved to address these ‘How Might We’ statements.
This led to the creation of a To-be process. Changes resulted including a new online form and internal process changes. Other recommendations, such as changes to user reporting and in-cab system improvements were deemed out of scope at that time.
Learning point: don’t limit yourself when generating ideas. These can always be modified to fit the scope or moved to the backlog for potential future improvements. At the same time, don’t focus too much attention on an idea that is never going to work for the service. Listen to what your stakeholders are saying as they know their service inside and out.
The rich picture
The Financial Landscape Project had spotlighted the complexity of the council’s financial teams and payments processes. My next project, was to look at the financial and payments teams structures and communication channels and try to identify barriers to a more joined up approach.
To find out more we conducted one-to-one interviews with all the different roles within the finance department. We asked questions relating to how they work and what internal struggles they are facing. We discovered lots of pain points across different teams and lots of positive points. After a fair amount of synthesis, we decided to create a ‘rich picture’ that showed which teams often communicated with each other, and what positive and negative comments had been made (this was all anonymous). It took up most of one wall of the office and attracted a great deal of attention and visitors!
We used this diagram to run a series of workshops with the different teams, with hopes of addressing the negatives to try to convert them into positives. The finance department took this whole process in their stride and adopted the process for themselves. They decided to run further workshops on their own and proceeded to make great progress in addressing their internal culture. For a short while they were running their stand-ups by the wall where we had initially drawn the rich picture. It was amazing to see something created with the hope of making a difference, fulfilling its purpose.
Learning point: It is often worth taking a chance on an idea if you believe it be worthwhile even if people have their doubts. The culture diagram had never been done before and I had never created one either. However, I had confidence that it was going to be useful.
Part 2 to follow – thanks for reading!
For regular updates from the #DigitalStockport blog sign up for email alerts.