15 Good Service Principles - School of Good Services / Lou Downe
Principles for Service Orgs - The Service Org / Kate Tarling
Public Systemic Design - Marlieke Kieboom (BCPS)
Dark Matter and Trojan Horses: A Strategic Design Vocabulary - Dan Hill
What is Service Design, anyway?
First: the tricky part. It can look a bit different, and be scoped differently, depending on the context. The size of your organization, complexity of your service, intended business and UX outcomes, constraints, and other factors will influence the details.
Fundamentally, you’ll see in the diagram below that service design considers the customer (learner) experience, but primarily focuses on the operations needed to deliver a good service experience.
At the Digital Academy, one of the critical service touchpoints or interactions is with our learning products (Learning Design & Curation team own the experience of those products).
Other touchpoints sit outside of the Digital Academy entirely, e.g. the LearningHUB (PSA), but it’s still part of our service (how employees find our courses). Service design can work across teams to facilitate a connected, impactful experience, e.g. by aligning everyone involved on a shared vision and purpose, and helping every team see their role in the larger connected service (from the customer/learner’s perspective).
To support this, service design can facilitate the creation of shared ‘standards’ for the big picture service across teams, e.g. an experience vision or UX strategy.
whatever you’re doing, think of all the people involved and impacted
in a healthcare context you need to think about not only patients but their family, the physicians, the nurses, other medical personnel, technicians, janitors, administrators… you have to think of it as a system and look at all of the components
Principle: solve the right problem
Don Norman: “almost always when someone gives me a problem to solve, I refuse to solve it. Because it’s not the right problem, it’s a symptom of the problem… if I can solve the fundamental problem, the symptoms disappear.”
Principle: everything is interconnected, think of everything as a system
sometimes optimizing a bunch of small pieces gives an inferior result
think about the big picture: what is the final result we care about?
Tess says: then we can apply agility and techniques such as story mapping to start chipping away at the vision and desired outcomes
Note: human-centred design is an umbrella term, it’s a way of thinking and doing our work - under the umbrella we have formal professional roles: UX Research, UX Design (products, apps, websites, other tech - user focus), Service Design (business operations, service ecosystems - employee and process focus), Content Design (content is the experience - and is more than words: videos, graphics, forms, etc), and Learning Design. Informally, anyone can bring this mindset to their work, and design thinking is a helpful tool (more on that in section 3 below).
Designing a service is not the same thing as Service Design
Designing a service = creating end-to-end customer journey of the user experience
Service Design = understanding what we as employees need to do to produce that customer journey
looking across an organizations resources and designing how it works to improve the employee’s experience, and indirectly the learner’s experience.
key ingredients: people, props, process
people: employees, partners, learners
props: things that have to exist for employees to create the experience, incl. tools, physical and digital spaces, e.g. a Learning Management System (LMS), virtual and IRL classrooms, marketing & comms tools…
process: workflows or procedures that occur between employees or between employees and learners/partners
“The process we design is just as important as the product we make”
A service design perspective is needed to avoid fragmenting the long-term learner experience by individual (but uncoordinated) touchpoints, provided by siloed internal teams.
Divisions in the digital learning space include: BC Data Service, CIRMO, Digital Office, Enterprise Services, GDX… - with many teams within.
Service design is the act of designing, aligning, and optimizing an organization’s operations to better support customer journeys, which results in an better experience for employees and learners/partners
Service design analyzes the workflows and procedures performed throughout a service
It also looks at the people involved in the creation or use of the service, and props like tools, physical spaces and digital environments
In many organizations, teams work in silos. Teams or departments may not be communicating about the holistic learner/partner experience, and may not be paying attention to the experience someone is having across many touchpoints
e.g. what is the experience of a new Product Owner who wants knowledge, skills, or abilities in agility, hosting, and data? They would need to interact with several teams and several digital spaces.
In our 2023 Design Research we learned that this is difficult to navigate, and sometimes offerings compete with each other. A Product Owner in our research study needed OpenShift and Agile Fundamentals training, had to wait for both offerings for a while, ultimately the two courses were scheduled at the same time and they had to pick one, and go back to waiting for the other, when they really needed immediate support. They deserve better.
Service design can work across silos to:
surface conflicts like misalignment between business models
foster hard conversations, like overhauling archaic policies and procedures
reduce redundancies by defining where duplicate efforts occur and redesigning
form relationships, by facilitating discussions across departments and creating a shared understanding
Context: when working across silos, service design can add more capacity and support to the work our incredible Communications & Engagement Specialist does!
What's the difference between user experience (UX) and service design? Or, more to the point, how does good service design support a good user experience?
UX (the “what”) = anything the end user comes across: an app, a website, a kiosk, an end-to-end experience they encounter
Service Design (the “how”) = how does that end experience get created: the people, processes, technology that have to align in order to make all the different pieces of the user’s experience possible
Why we need both: you can’t have one without the other - different sides of the same coin:
you can’t have the end experience if you don’t have anyone to create it
you can’t create something if you don’t have an end user to experience it
they should be practiced in parallel with equal efforts in both places: as you come up with innovative products, think about how they are going to be delivered to meet learner expectations
Orgs tend to silo themselves by functions or products, but users have many touchpoints across the silos when trying to get something done
Service design aligns these silos to create the experience we want as an organization
what is the experience we want folks to have with the Digital Academy?
From the movie the Founder, a fun example of prototyping a service (operations)
How does service design support the Digital Plan & Code of Practice?
This section is about how I’m personally finding a sense of purpose in supporting our core policy. A personal mission.
Historically, ministries work within their mandates to design and deliver services. These services are arranged to match government’s own organizational structure. The result is products and services that are hard to find. In some cases, people need to understand how government is organized just to interact with us.
Digital Code of Practice: Design with people and embed inclusion x build internal capacity
Employees are people too! And service design aims to improve the employee experience, toward a better learner experience.
“Staff who are involved in the creation and improvement of service not only feel more engaged but through learning about the complex ecology of the service they provide and how to make use of innovation tools and methods, they are also able to continually improve the service themselves.”
— Andy Polaine, author of Service Design: From Insight to Implementation
Service Design can look quite different depending on the context - “it depends”. Let’s put Service Design in context of the hopefully-familiar design thinking method:
Conduct research to develop an understanding of our learners, employees, partners, and business context incl. ecosystem and connected service perspective
Combine all your research and observe where problems aka opportunities exist — I look at problems as good, interesting things!
Generate a range of ideas, can include creative & competitive research: how do others solve similar problems? The more a team is connected to a problem, they better they can innovate!
Build real, tactile representation for your ideas (see Speedy Service System above)
Service Design should be co-creative, including employees and partners in prototyping, also testing early and often
Put the tested work into play, monitor and iterate as appropriate. To be agile, we can pilot operational changes before rolling them out officially
it is excellent, and frames how to move from waterfall thinking to breaking the work into pieces, and identifying high value places to start (prioritization) - this supports:
working in large, complex, legacy environments (aka gov): everything is broken, the ecosystem/connected service context is complex, there is urgency to improve, omg overwhelm, where to start!?, and
supports responding to a rapidly changing world
the course does not touch on working in specific frameworks such as scrum
The Digital Plan and Code of Practice lead with Design (being human-centred), whereas much of our operations and training leads with Scrum, with a lot of ambiguity, friction, and outright conflict developing in pockets of gov when trying to combine the 2 ways of working. None of the agile/scrum training references Design or how it fits into the process, sometimes even assigning accountability for human-centred work to Product Owners instead - some folks are confused
It seems that the onus is being put on Designers to solve this for themselves on the ground, without guidance OR Design practice leadership. It means they’re being asked to lead Design work (often as a team of one, technically working across several Design job profiles), teach folks around them how to work with them, defend their practice (potentially as they are up-skilling said practice and may not feel confident doing this yet), and problem-solve how to fit their work into these frameworks such as scrum (with some Scrum Masters pushing back: “you’re not agile”, “you don’t fit into this work”)
I believe the Digital Office needs to play a bigger role in advising how Design fits into frameworks such as Scrum, in a way that supports good practice and outcomes (see cautions below)
Tess Good was 1 of 3 auditors, materials (3 x 8 hour days of slide decks + resources) are restricted to honour the effort and intellectual property of the course. Happy to share elements as appropriate.
Breaking work down into smaller pieces
Breaking work down into smaller pieces
Service design can be chunked into agile pieces - it’s a delicate dance of looking at the big picture (systems, holistic thinking re: silos, connected services, ecosystems, and operations), then ‘zooming in’ to work on small components at a time - maintaining clarity on how it all fits together, being open to change as we try, test, and learn
Early on, e.g. when conducting design research in the “understand” stage, let’s say you need to run a fairly large study because there is significant uncertainty, complexity, and a diverse customer/user group (necessitating a larger sample to be representative of the humans you’re trying to understand):
you can still chunk the work into sprints and defined tickets, breaking down phases of research and tasks (discovery, planning, recruitment, writing scripts and developing your research materials, running the research, analysis and synthesis, sharing and integrating the findings…)
A significant benefit: this can help surface collaboration points, e.g. Product Owner and sometimes other key employees who are part of delivering the service should be involved in developing and refining a research plan, getting it into the backlog and calling out the collaboration ensures folks are aware and available
It can also help us anticipate when we’ll need to involve folks outside our team, e.g. when working on connected services, engaging folks in your service ecosystem, or running participatory design sessions. Being proactive and looking ahead in your backlog can help identify when to start scheduling collaborative sessions. Sometimes working around availability can slow the work down, but I believe it’s important to “go at the speed of trust” and “go far together” vs “going fast alone”. Service Design is most impactful and successful, long-term, when solid relationships are slowly built with everyone involved in the service ecosystem.
Service Design, especially when new, can be quite threatening to folks - if it isn’t introduced/framed carefully, there can be negative reactions and assumptions given it can involve change, optimization, ‘efficiency’ etc. - important to consider this in context of the broad psychological safety and trust at BCPS (I’d assess that baseline as pretty low, today)
You can prioritize a smaller number of people or groups at a given time to be agile, vs. boiling the ocean and trying to address an entire ecosystem of relationships all at once
Mitigating the risk of ‘doing the wrong thing, faster’
Mitigating the risk of ‘doing the wrong thing, faster’
avoid the temptation to scope down necessary research or design work to “be more agile” - sometimes speed genuinely is critical, but often a focus on speed or “MVP” thinking can limit Designers and their impact (and could signal a misunderstanding of agility). It’s a balance, it depends on context, but it’s absolutely ok to be flexible in your agile/scrum practice, especially when conducting early-stage research in a service evolution or transformation to frame up the problems (“start with the problem”) — agile is primarily about responding to change as you go, toward building the right thing (solving whole problems)
I’ve seen teams that focus on speed spin their wheels for years because they don’t understand the root problems, user-needs, or business-outcomes the work needs to address - they produce lots of code, often working at the surface level (e.g. automating broken processes), and might see poor user adoption, or might not solve complete user or business problems, and get stuck - it feels fast and therefore productive, but isn’t having the desired impact
Leveraging scrum ceremonies and methods
Leveraging scrum ceremonies and methods
The backlog prioritization and sprint planning elements of scrum can be helpful, once we have ‘just enough context’ about the big picture and root problems/opportunities from discovery and research, we can conduct activities to identify the highest value/impact opportunities - where is the most pain and risk? Or most pragmatic opportunity for change?
Methods such as story mapping can help us maintain perspective on the big picture while ‘chunking’ the work into user stories and taking an MVP approach*
*but watch out for the MVP-and-move-on trap! It can often result in undesired outcomes, e.g. half-solved problems, accessibility gaps, broken trust with users and stakeholders
We can run small ‘pilots’ to test operational changes rather than making big, complicated wholesale changes all at once - having a clear idea of how the small component fits into the bigger picture we’re working toward gives us confidence we’re making the right decisions
Because the work needs to be collaborative (Service Designer working with service/product staff), time for staff to participate in service design activities (research, mapping, piloting new ways of working) needs to be built into sprints and planned across both teams
On how to sequence the work, Jeff Patton has some fantastic advice for product teams in this article: https://jpattonassociates.com/dual-track-development/ - the context and reality of Service Design (the act of designing, aligning, and optimizing an organization’s operations to better support customer journeys) is slightly different, but we can borrow the same thinking and principles
one idea to explore: is there value in dual-tracking 1. service improvements (where the focus is on understanding, exploring and materializing service changes WITH service staff) and 2. maintaining service operations (even during improvement phases, the service is likely still running, meaning a certain amount of staff time needs to go into keeping the lights on)
Leading with the problem and desired outcome
Leading with the problem and desired outcome
A caution on design sprints: In my ~15 years doing this kind of work, I’ve seen more work thrown out after design sprints than I’ve seen ‘stick’ and lead to good outcomes. I’ll tell you stories if you’re interested!
Sometimes people jump to Design Sprints as the way to practice Design in a scrum org, “sprint” is right in the name after all — let’s break it down!
What is a design sprint? A method for rapid ideation, prototyping, and testing — most often leveraged in product (app) design contexts
On culture, values, and outcomes: this method comes from the ‘move fast and break things' private sector world - which often doesn’t put inclusive design or harm reduction at the forefront and deprioritizes “edge cases” (aka excludes people) - out of the box, it’s also not a way of collaborating that works for everyone (know your audience)
This is one option in our method toolbox (maps to steps 3-5 in the design thinking table above). Please honour the role of Design professionals in assessing the work to be done, and identifying the optimal method to get the information/results needed - method selection is a key point in Design work where things can go sideways, and as a general rule leading with a method vs. leading with the problem and desired outcome can get us into trouble down the road
for a different example, check out this resource on selecting research methods - it does a great job of visualizing how different methods are good at different things https://www.nngroup.com/articles/guide-ux-research-methods/ - this principle can be applied to all facets of Design
A poorly scoped/planned/facilitated Design Sprint could result in Design Theatre (Tanya Snook) - it looks and feels productive at the time, but doesn’t get us where we need to go, and sometimes you don’t realize right away, which can be costly in time, budget, and trust with stakeholders and users
When this method is identified to be the right fit, and planned/facilitated well, they can be impactful!
an example scenario: you could use a design sprint in a discovery phase (early in a new initiative) when you want to surface what everyone involved in the initiative knows, quickly socialize that knowledge, and start to model what a way forward could look like (sketches, prototypes). We could call this “collaborative hypothesis building” (credit to Teresa Lee) and it could help orient collaborators to the design process. Similar in concept to a scrum team inception.
the outcomes (sketches, rough protos) could inform a research plan, where some of those materials are even used as props in the research - but the above design sprint wouldn’t replace fulsome Research and Design practice
What are we trying to avoid? (applicable beyond product - services, programs, etc.)
How are we practicing service design here?
Introducing: Full Stack Service Design · Sarah Drummond (she/her), School of Good Services
A model to help people break services down into the parts that make them and understand how all of these parts impact the user experience.
Services are made up of thousands of tiny, often accidental design decisions. These design decisions are often unconsciously made, in isolation from one another, and without an understanding of the impact they will have on our services or the experience our users will have of that service.
From policy development to metrics & measurements, organisational structures to technical architecture, all of these components – and the decisions we make about them on a daily basis – have an impact on the services we deliver and our ability to meet user needs.
Yet the vast majority of the tools we use to design services – from user journey maps to blueprints – focus on just the parts of a service that a person can see and where we believe we can firmly influence the output of how a service should work with a level of certainty.
This is an attempt at summarizing the article — I see so much opportunity, but I’m only one person, so where might be the highest value places for me to support? (Now, Next, Later). I’ve re-ordered the 5 layers per the ‘order of operations’ I see for the Academy today.
What (5 layers to the stack):
Why (each layer matters to service design):
Academy opportunities (where we can go from here):
What (5 layers to the stack):
Why (each layer matters to service design):
Academy opportunities (where we can go from here):
INTENT The reason why we provide services, the thing we want to achieve. scope: business models, mission, policy, values & ethics
The intent is often documented in a ‘mission’ or ‘purpose’, and, if that intent is fully supported within that organization, will be encoded in every layer that this organisation uses to think – from its policies and business models right down to it’s values and ethics.
Mission: clarity on the Digital Academy mission in line with the IM/IT ADM committee, Digital Office OKRs and Scrum@Scale value stream prioritization, DTC Branch OKRs (dependencies)
“we can use a mission as a driving force in aligning groups and delivering on a shared purpose in a complex ecosystem”
Policy: integration of the Digital Plan, Code of Practice, and other relevant policies into our work
what are we hoping to achieve with this policy (what does “having digital skills” mean and look like)? why is it important? what happens if we don’t adequately support digital skill acquisition?
how will we know if we’ve supported this policy through learning experiences? signals & evidence?
Audience: define, align, prioritize streams of the IM/IT audience with key partners (PSA and Digital Talent?), create a discovery/research plan to better understand the landscape of IM/IT learning needs, practice pain points and opportunities (2023 research recommendation #7)
who are we doing this work for, why, and what do we know about them today?
the full IM/IT audience and scope of work is too large for our current org capacity - need to chunk and prioritize
ORGANIZATION How we organize ourselves to make decisions. scope: governance, procurement, finance, org structure, skills & roles, metrics…
Services are shaped by the organisations that create them. The way we construct our organisations or collaborative arrangements to design, deliver and maintain services affects the user experience.
Governance drives organisations and brings people together to make decisions. How it is run, what data we use to make decisions and who is involved all impact on our services.
When services are run by multiple different departments without clear ownership for service decisions or approval processes are complex, this can affect a services ability to respond quickly to feedback or emergent needs
In order to deliver a service we need to be clear about who is responsible for what tasks and at what point in a service they are being delivered. The skills we have within our organisations, and the way we define those skills into specific ‘roles’ plays a huge part in our ability to organise ourselves to deliver our services.
Measuring performance is a key part of ensuring an organisation is meeting its overall goals. Measuring the outcomes of our services help us understand if we are delivering the impact we set out to deliver, but it also motivates us to do certain things in our organisations too. What we outline as a good outcome for services has an impact on how we design, deliver and monitor our services, and then incentivise this performance.
Governance, org structure, skills & roles: somewhat of a dependency on Scrum@Scale and value streams for governance/decision making clarity, and cross-Digital Office collaboration?
DA role clarity: we’re making progress with Service Design and Learning Design job profiles, this page is meant to help
identifying our skills and strengths (incl. growth goals), assessing the work to be done, and being clear about who’s involved in what will all support our service evolution
Data: To make informed decisions you need data and knowledge. Good governance considers what type is needed to make informed decisions about the services being delivered and the sustainable operation of these (2023 research recommendation #8)
Measurement: See proposed product-market fit matrix with outcomes and measurement resources (2023 research recommendation #7 and #8)
Keen to apply the Kate Tarling (Service Organization) outcomes workshop once we have some direction. See email from Tess on Jan 5 re: measurement from Jared Spool
Finance: Funding is rarely stable and can also increase and decrease dramatically in quick cycles depending on external factors.
Service Designer can support Product (Service) Owner with cost-recovery strategies and models that support our service evolution as we head into an election year and see significant investment going toward emergency readiness & response in 2024
Procurement: Procurement and supplier management involves buying goods and services that enable an organisation to have the resources, equipment and people to deliver their services.
If procurement focuses on outputs, not outcomes it is likely the service will not meet user needs over time. Service design can support.
CULTURE The conditions that affect how we make decisions. scope: culture can be organic and fostered
Culture envelopes all the components of a service because it shapes how we make decisions and act.
From the autonomy staff have to how authority works, our culture shapes how we design.
Our ‘culture’ as an organisation is expressed through our attitudes and beliefs, how we make decisions, how we express our thoughts, and what we show up to expressly care for.
We can design and iterate this as we go, together (intentional co-creation)
INFRASTRUCTURE The things that enable our services to be delivered. scope: systems & tech, data
Infrastructure affects the way we build our services because services rely on the technology that is used to deliver and maintain them over time.
When it comes to using data to design services, there are four things we need to think about:
How we document and standardise our data
How we use and exchange data
How we use performance data to inform our decision making
Safety and privacy
Tess argues for a 5th @ DA - how we collect the data
Systems & tech: e.g. Learning Management System (LMS)
Data: appropriate data collection (intentional discovery, responsible survey design, research rigour), establish data practices, e.g. Atomic UXR and repositories (2023 research recommendation #8)
SERVICES The things a user sees and interacts with. scope: business process, user experience
A service is something that helps someone do something they need to do.
The things a user sees and experiences are made of lots of small interactions with your service. This user experience is designed to orchestrate someone to do the thing they set out to achieve.
Business processes are a series of actions we take as an organisation that enable services to take place. When business processes are not designed well, they can be expensive to provide, stop users from getting the support they need, or force them to become experts in negotiating your complex processes.
Business: Service Designer can map (blueprint) our service to visualize service components (people, props, processes) and identify business optimization opportunities that supports our shared mission, per point #1.
for blueprints or other activities/artifacts to have impact, we need to have a goal or desired outcome in mind. This is why, in this moment in time, I’ve listed this step last. A shared intent/ mission will take us far!
UX: Leverage our journey map and 2023 research to identify highest-value touchpoints in the service experience to optimize first for our learners (we can’t do it all, today). Service design can advocate for the customer, but doing the UX work (creating or iterating products, tech that supports our service) is owned by many other folks. This work is collaborative, a team sport!
Systemic design thinking and practices are gaining momentum by entering the field of government policies, services and program design. In the 10–part “Unbounded Affairs: Systemic Design (with)in Government’’ blog series a diverse collective of thinkers and practitioners explores the concept of “public systemic design” for a relational future.
"Unbounded Affairs" was written by Marlieke Kieboom, based on conversations with a like-minded and like-hearted collective — the “Ministry of Unbounded & Entangled Affairs” — whose people work and think at the intersections of design, public policy, complexity, social justice and deep ecology. The series was written over the course of 2022.
Dark Matter and Trojan Horses: A Strategic Design Vocabulary (Dan Hill)
This is a book that compliments the Full Stack Service Design model, and explores the role of design in shaping and influencing the world, particularly in the digital age. It delves into the idea that design is not limited to aesthetics but plays a significant role in shaping our social, political, and technological landscapes:
Design Beyond Aesthetics: Hill argues that design extends far beyond the realm of aesthetics. It is a strategic tool that can be harnessed to influence and change various aspects of our lives.
Dark Matter: The concept of "dark matter" in design refers to the often invisible and hidden elements that shape the user experience and behavior. These elements can be as crucial as the visible design aspects.
Trojan Horses: Hill discusses the idea of design as a "Trojan Horse" – a strategic tool that can be used to introduce new ideas, concepts, or technologies into society in a subtle and persuasive manner.
Strategic Design Vocabulary: The book introduces and explores a vocabulary for understanding and discussing design as a strategic discipline. It offers terms and concepts to help readers think critically about design's role in various contexts.
Design in the Digital Age: Hill reflects on the unique challenges and opportunities presented by the digital age. Design, in this context, is not just about products but also about services, systems, and interactions.
Social and Political Implications: The book highlights how design decisions can have significant social and political implications. It encourages readers to consider the ethical and moral dimensions of design choices.
Interdisciplinary Approach: Hill emphasizes the importance of an interdisciplinary approach to design, drawing on insights from various fields such as sociology, psychology, and technology.
Examples and Case Studies: The book includes case studies and examples from various domains to illustrate how design has been used strategically in different contexts.
Design for Change: Hill advocates for a more proactive and intentional approach to design, using it as a tool for positive change in society.
