I simplistically take the view that Service Design is the concepts and methods of Design Thinking applied to making services work better for their customers. It’s a definition that works in the circles I most commonly move in, i.e. directors, programme directors, etc. It allows me to set the stage in which service design and design thinking both play.
However on the same stage, we commonly find KPIs, OKRs, Business Architecture, etc. And the stage starts to look crowded very quickly. We also start to see people pulling in different directions, like someone has let a mouse loose in the chorus of an Italian opera.
Operas and plays have directors, often many directors each responsible for their own domain, but with one artistic director responsible for the overall vision.
Now imagine what would the stage look like if the director asked the question “How might we…..?”.
It’s the opening line of many a design thinking ideation round. And it serves many purposes, explained better by others elsewhere.
Taking the stage analogy further, I hear questions such as “How might we produce more colourful costumes?”, “How might we light the back of the stage better?”, “How might we fill this part of the stage?”.
All of them are good questions and relate to the specific problem that has been uncovered during the discovery phase.
What they’re not doing is thinking of the entirety of the show. They just resolve the problem that was uncovered for their part of the show.
How might we approach this differently?
What they’re not doing is asking “How might we aim to deliver a better show?”
Let’s look at that question more thoroughly.
It’s got the typical format of “How might we…?” introducing the concepts of inclusion, a shared problem, and an indication of possibilities and potential.
I didn’t stop at the simpler question of “How might we deliver a better show?”. That’s where service design typically fits.
If we step back from the stage and consider an organisation, even applying service design in this way would be a stretch. At this scale, we’d be trying to apply service design to the whole organisation, e.g. how might we deliver better services? Where typically each service would have its own change activity, often in the form of design sprints, etc. Instead, the simpler question of “how might we deliver a better show?” could be translated into a top-down design question for an organisation of “how might we deliver better products and services?”, “how might we become a better organisation?” or similar organisation-wide design questions.
However, the question I introduced earlier focusses on the aim, not necessarily the end result. It asks about how might we aim to deliver. In focussing on the aim, it allows us to explore the goals and how goals are set. It leads us to question what goals would be required in order to deliver a better show. In understanding the goals, we have to understand what good looks like, what counts as successful and not just in the eyes of the board, but in the eyes of customers. If we set the concept of goals smart enough, this could easily set the scene for continual improvement.
Alignment with Business Architecture
Back to the organisation, now that we’re asking about the aims, and we’ve looked at the goals, we can start to see how the goals for the enterprise could be set. This brings Service Design up to the area where it aligns with Business Architecture. While this may seem at odds with a top-down approach of setting KPIs, we have to ask the question of why wouldn’t we want to develop an organisation that is driven by achieving its goals that deliver value to customers?
Alternative Business Motivation
By combining Business Architecture with Service Design, there is the possibility of redefining the concept of Business Model Modelling. Typically that’s a top-down approach, modelling external influencers, assessments, goals, objectives/outcomes, etc. Taking the combined service design/business architecture approach would result in metrics that matter to customers as the metrics percolate up through the organisation, not cascade down as is more common.
Whereas the concept of One Metric That Matters may suit startups as they redefine/focus on a different metric per stage of development and growth, it would not be expected to change as often in a more mature organisation. Instead, we may see a single metric that is of most interest for a cycle of improvement. But here’s the clincher – that metric would be an aggregate of the metrics defined by exploring the problem space with customers, not one that’s defined by an executive board.
However we may see a situation where an executive board decides to steer the organisation away from its current model towards a different business model. In that case, we would consider a more top-down approach.
I’m convinced that there’s no thought to place of people in the design of most supermarket car parks.
I’ve just been to a great example of poor design.
When driving in, you turn off the main road to a roundabout. At this roundabout, you turn right, away from the store, to the main car park. You can turn left, towards the store, to the disabled and parent+child spaces. There is no path between the main car park and the store. So at the roundabout, we also have people walking from their car to the store and back from the store, laden with shopping, to their cars. All those people also have to walk through the disabled and parent+child car park. Even in that car, the only two differences are that the spaces are wider and closer to the store. Once you’re out of your car, there is no pathway or walkway, even as disabled or with a child; you’re straight into route of cars (with their drivers looking for spaces).
More Common Example
I’ve always wondered why every supermarket car park has the access road running right past the front of the supermarket pedestrian entrance. From a day-to-day safety perspective, it doesn’t make sense. It forces drivers to drive their cars past pedestrians trying to cross the road from the car park to the store. It feels like lazy or shoddy design. I hope that it’s a law or bye-law regarding providing access for emergency vehicles. However, even if that were the case, is the road right in front of the superstore the correct approach?
What’s missing here is the realisation that we’re all pedestrians. Whether we drive or not, at some point, we’re walking or moving with the aid of a wheelchair. That element has been forgotten and instead, the focus has been placed on the car, not the people.
Cars can’t speak for themselves, they can answer questions in a design sprint. Only people can. And there will always be more people than cars going to supermarkets. At least, until automation becomes more prevalent.
Can you imagine what a car park would look like if it were designed with people in mind first? Better walkways, better trolley parks (self-driving trollies?), more visible paths splitting pedestrians and cars, straight walkways that go from the store to where people want to get to (as opposed to the current approach of pathways where it’s least awkward for cars).
Look back long enough and you’ll see lean, systems thinking, TQM, CRM, structured systems and many, many more methodologies and/or approaches.
The problem is in the delivery of the projects when the terms become more widespread.
What we’re seeing is the climb of two methodologies: Service Design and Design Thinking. You can probably add in Human-Centered Design and Inclusive Design into that mix. Many organisations are adopting these methodologies to solve their existing problems, switching from a lack of methodology or from more formal, structure methods to ones centred around design.
I’m increasingly seeing Design Thinking heralded as the way forwards, but there are some issues with that approach.
To be clear, I’m a supporter of Design Thinking and many related methodologies. I’m not necessarily a supporter of how those methodologies are implemented in many organisations. I don’t believe design thinking is a fad or at least a significant number of its concepts will remain even if a newer or revised method takes pole position.
What we’re not seeing though are the reports of the design thinking projects that have failed. I find it hard to believe that design thinking and similar, related methodologies are the magic bullets that we’ve all been waiting for.
So do failed projects exist?
For every other methodology, there are numerous reports about how it has failed the client. The application of Six Sigma to Nortel comes to mind as a famous example. But there are plenty of other reports detailing failed projects.
So where are those reports for Design Thinking? It could be that it’s too early to tell since we’re on the early adopters curve.
Gartner produce the hype curve for technology adoption. It describes how people react to new technology, by relating their emotions to the stage of the technology and their use of it. We can apply a similar description to most methodologies.
They usually start with practitioners noticing something wrong in their current way of implementing projects. So they add, modify or remove elements. This may be a 2.0 version of the original method. Or if sufficient changes have been made, then it becomes a new method. Occasionally changes are blended from another method or a practice outside of the change domain. This new 2.5 version may take on a life of its own and become yet another rebranded method; this time at 1.0. So this fresh 1.0 version has only been used on a few projects and has had great success from the perspective of the facilitators. Therefore it’s a brilliant solution to fixing any problem and becomes heralded as the latest and greatest. Unfortunately those implementations are only just becoming lived-with, i.e. the changes occurred but they haven’t had time to become embedded in the organisation. That’s when murmurings of disgruntlement appear, sometimes with a “told you so” attitude depending on whether or not the change team had listened to the advice of their subject matter expects. Often the change team has moved on to the next project, this time with a couple of tweaks to their methodology, so version 1.1 which addresses some of the issues they were confronted with at the time of making their changes, but importantly, not those that appeared following the change.
The combined status of design thinking is relatively immature, compared to SSADM as an example and I’d measure that maturity through the age of the methodology, the number of project years it has been exposed to and the rigour involved in the definition of methodology. Design Thinking could potentially have more project years (due to the vast number of projects running now), but many of those projects would be, themselves, immature (due to people trying it out for the first time). Moreover there’s no single agreed definition of the method to follow, but instead many different flavours as different authors, consultancies and training organisations create the latest version of design thinking.
So whereas other methodologies are further along the hype curve, with many of them on the “slope of enlightenment”, there are times with design thinking when I think we’re at the “peak of mount stupid”. I could probably say that about a number of projects, regardless of methodology employed, it’s just that more projects now are aligned with design thinking than before.
Confirmation bias and success bias
We only want to hear what we want to hear and what we’ve planned to hear. So we will either not hear or discount information that contradicts our beliefs or expectations. This selective perspective allows us to promote one methodology above another without viewing all the evidence. It takes time and experience to continue to assess beyond those initial boundaries and look for evidence that contradicts our expectations.
I suggested that the reason we’re not hearing about the failed design thinking projects is that they haven’t been in place for long enough for us to realise they were failed projects. But perhaps, it’s that there’s something more insidious about the design thinking movement, in that only the positives are celebrated. Even to the point that failed projects receive political spin so that the positive elements of them are celebrated.
I’ve seen examples where the design team ran their sessions and sprints, came to implement new organisation designs, process designs, etc and were heralded as successful, even as leading lights as other similar organisations came in to learn how to achieve the same magic. However that same team hadn’t engaged with many of the other departments required to make the changes work, most notably IT. That meant that they had a great design that would take 2 years to implement if and only if the IT department had the same vision and decided to implement. Remember that IT was just one of the forgotten departments. Would the design have looked different had the other departments been involved? I’d bet money on it.
I’ve also wondered if it’s the age and associated behaviour of the people performing these sprints. Remember that most of these will be millennial, coming from a segment of society that did not get overtly negative feedback at school. There’s no right or wrong there, just a different perspective and a different approach to giving and receiving feedback.
Many change professionals have been combining elements from numerous methodologies or creating some methods almost from scratch for years. You can only do that successfully and repeat successfully with the experience of having first worked with a number of different methodologies. Once you have the background of what works and what doesn’t, then you can better understand what is likely to work in any one situation.
That leads to a few issues that we can learn from:
Issue 1: Vanilla Method
My view is that no methodology should be applied to an organisation without some tailoring. Applying the out-of-the-box tasks and activities makes a mess of an organisation, where the objectives become secondary to the method. Part of the skill of any methodologist or senior business analyst is in knowing which parts of a methodology can be removed while still providing acceptable risk to the organisation and its objectives. Otherwise, we would all be producing documents for every part of the methodolgy rather than getting any work done.
Issue 2: Inexperience in change
Reading the book doesn’t make you an expert. Methodologies take tact, understanding and planning to implement. They also take the extrapolation of what’s worked and what hasn’t worked so well. Without that analysis, whether seen first hand or learned from others, the method is untested.
Issue 3: Inexperience in business
A significant number of people I see involved in design methodologies are new to their careers; any career in fact. Would I expect them at the start of their career to know how HR, OD, IT and legal interact. I’ve been doing this for years and I still have to question each of my clients what their HR function actually does. I learnt to ask since in some it’s purely advisory, in others in full-stack recruitment, sickness management and training. It’s different in every client (with a few common patterns appearing if you work across enough clients). That’s part of what we need to unpick before we can figure out who needs to be in the room. I wouldn’t expect that from a relatively new starter.
Issue 4: Underestimating
Not only underestimating the number of people that need to be involved in the change, including taking those off the front-line so that they can contribute, but also underestimating the skill set required to facilitate changes through implementation and beyond, or better still, underestimating the skills set required to have the changes graciously accepted.
Issue 5: Learn from mistakes
We all make mistakes. Even the best project has had a few errors. Learn from them and take action to not repeat them. By moving design teams onto new challenges too quickly, they won’t be in a position to receive that valuable feedback that is required.
Issue 6: Implement
Design with a view to implementation. Design for design’s sake will get you so far, probably for your outputs to sit on a shelf. If you’re designing to implement, then you’ll think differently about who to include and also how to include them. Thinking about the fact that it needs implementation forces you to think through timescales (e.g. what’s feasible?), think through the politics and governance, think through the people you’re going to affect internally.
Think of this current article as being a first draft. It’s likely that my thoughts will clarify as I hear of other projects and have further discussions about this concept. If you’d like to discuss it more, get in touch at @alanward
I’m often designing change programmes for large organisations. I’m an external consultant, an outsider coming into the organisation that already exists.
There are already governance boards in place, whether for operational, financial or change governance. These boards happen on a regular basis, often on a set day of the month. As an outsider, I’m not going to be able to change those days. At most, I can influence the shifting of one or two on ad-hoc and in very rare occasions, the executive sponsor is senior enough to be able to change the day because it suits her as well. But remember that a lot of other activity is set around these events and most organisations will resist changing the day.
So why do we need to change the day?
If you think of a typical design sprint, then it’s a week long, starting on a Monday and finishing on a Friday. But we want approval to proceed from relevant sponsors before moving onto the next stage. Or we want guidance or steer or budget to be able to continue.
Depending on the rate of change, the organisation may not wish to see the delivery delayed as one team finishes on a Friday, then has to wait until Wednesday or Thursday for approval (or rejection).
So the really simple trick I’ve employed is to build the executive boards into the design sprints by changing the starting day of the sprints.
Figure out your approval mechanism before you plan the sprint, find out what date it meets, gain agreement to present on a regular basis (even if it means extending that board by 30-60 minutes until they become used to the type of content), then plan the start day based on when you’ll be ready to present.
It is that simple.
Typically, for a Wednesday morning board, this will mean starting on Thursday the week before. This cascades back into the planning sessions for the sprint, these will typically have the same starting day once you’ve found your pattern.
This ensures a smoother design-approval-implement pipeline than we’d otherwise achieve.
The additional advantage is that the weekend provides a break. Sprints can be intensive, should be intensive, and for attendees not used to that level of continued, deep thinking, there are often casualties in terms of attendees not wishing to continue, still trying to carry on with their day job, etc.
The weekend break gives you all chance to refresh, gives the facilitator change to revive spirits on the Monday as it’s only a few days left, not a whole week, and gives you all time to reflect on the positive work you conducted the previous week.
There are three issues that I’m aware of from having done this with numerous clients.
As mentioned above, you need to engage with the board and modify the agenda before you attend for the first time requesting approval. Request additional time for the first round, or create a separate session immediately after the board but with the same membership.
Talking about weeks can get a little confusing, but easy to clarify once you get more rigorous about your choice of words.
You’re more likely to cross into someone’s unavailability due to annual leave.
Whatever system, process, technology we’re implementing, shouldn’t we be designing for everyone? Or at least everyone in the target customer segment?
In the last couple of weeks, I’ve read a number of articles that have consolidated and made me reflect on my thinking about designing for disabilities and what counts as normal.
Having spent a number of years working in the health and social care sector, I’m well-versed in the practicalities of working with people with disabilities. But I still hate the phrase “people with disabilities” and every other similar phrase I’ve ever seen. I don’t like the word inclusion, not that I don’t like the concept itself, but that I don’t like that the concept has to exist. Hence the title of this article as “Designing for Everyone”.
What’s an average person?
I read The Atlantic’s article on how we’ve ended up with a definition of a normal person. That’s at the crux of a lot of the disparity that we can see in the thinking of a lot of designers; they design for the average person or people similar to themselves. By using the term designer here, I’m not necessarily thinking of an artist or a creative, but rather the person responsible for delivering a changed process, a changed organisation or a changed way of working. They may have a creative background, but often are from their own professional background, e.g. in the front-line work or a change management professional. Fortunately, a more creative influence is coming into the change profession, for example we’re seeing newer methodologies such as Design Thinking, Service Design and Inclusive Design.
The problem with most of these approaches is that they develop solutions for the average person. There may be several average people in the target. These personas should have been based on the likely customers that the service wants to attract/serve. But considering how many conditions and disabilities there are in the world, there’s no way to account for all of them. Instead, we’re back to averaging again and possibly some Pareto analysis to account for 80:20 of the target population. That still leaves 20% who are not included in the thinking behind the design.
And that’s part of the theme of the article; that by defining a normal, we start to react towards the average as the ideal and the non-average as divergent.
How can we be completely inclusive?
Microsoft have released their Inclusive Design toolkit. The start of the toolkit is a touch simplistic, especially if you’re worked in health and social care, but it gets interesting part-way through. I’m also aware that the beginning portion could still be a incredibly valuable education source for those not used to having think from this perspective. So for that reason alone, I’m grateful to Microsoft for having released it to the world.
But more than that, there are a few nuggets of quality information in that method that I haven’t seen written down anywhere else. I’ve had to reign in proposals by pointing out difficulties of interacting in the proposed manner, so the 2 points below resonate with me.
The first is the potential to abstract away from individual conditions and dis(abilities) to perform tasks and instead focus on the interact between the person, the technology and the environment. That way, you can focus on resolving issues or improving the interaction between the person and other people in the context of the environment and the technology used.
The second is that disabilities do not need to be permanent. There’s a description of a spectrum from permanent through temporary through to situational. And there are more people in situational or temporary with difficulties than with permanent disabilities.
I’ve cropped the slide here and clicking on the image will take you to Microsoft Design Practice.
How do we include views of everyone?
This is an old source for me, but one that I still point people to when they’re thinking of how to approach their change programme. Beware though, it only becomes inclusive if you included a wide range of people in the interviews and in the service design. It’s a concept of Experienced-Based Design that I’ve seen from the health sector. It’s the best example of a co-production/co-design methodology that I’ve seen.
Implementing changes for people with disabilities is difficult to achieve since you’re already on the back foot with that perspective. We can see this by the difficulties involved in making websites accessible when that’s been added as an afterthought. Instead, by bringing the focus on a more inclusive design up-front in the process, we have the opportunity to design changes that suit many more people.
Above, I’ve listed a few articles and methods that could help influence others around you. The main item to take away concerns perspective; anyone involved in change has to be able to shift perspective to include that of all customers in the target segment.