Behind the Scenes: Service Design for a B2B Digital Service
This post is part of a broader blog series, Service Design: A Comprehensive Guide for Beginners and Advanced Practitioners. Here, I’ll walk you through how a new digital service targeting a B2B customer segment was developed using service design principles. I'll also share some of my personal approaches to working. I favor an end-to-end mindset and approach, looking at things holistically by first understanding the entire puzzle before diving into individual pieces. End-to-end thinking also entails taking responsibility for the initial steps and continuing to improve the service post-launch.
Starting Points for Service Design Work
Our team had a defined design process and a systematic way to involve both customers and internal stakeholders across the organization, from the customer interface to business leadership.
Previous research had revealed that this particular customer segment was underserved, and there was a clear need for the planned service. In earlier customer interviews, we had touched on the topic and already had a basic understanding of how these customers currently operate, their challenges, and their needs. The business goals also supported the decision to create an entirely new service for these customers.
The design team included a service designer and two UX designers, while the product development team comprised a software architect, developers, testers, and a product manager.
Gathering Customer Insights
Since we had already explored the topic in previous customer research, we did not conduct a pure customer needs study. Instead, we engaged internal stakeholders to gather their perspectives on customer insights and business needs. We conducted one-on-one discussions, organized workshops, and collected diverse views from sales leaders, account managers, and customer advisors who interact with customers daily.
The new service also impacted other business areas, with clear interdependencies across various departments. Therefore, we broadly engaged business developers and leadership across organizational boundaries. The product development team was involved from the very beginning, ensuring they stayed updated at every stage.
Why involve such a wide range of stakeholders? Product development should never be an isolated activity of the development team alone. Multiple stakeholders—such as marketing, sales, customer service, and leadership—interact with the service and its impact on the business. A social process of co-development helps disseminate tacit knowledge across the organization, breaking silos and fostering a shared mission.
Ideation and Concepting
Based on prior customer research and internal understanding, we initiated ideation and concepting. Hypotheses about the service concept were formed, and we defined requirements as user stories, visualized concept alternatives, and created interactive prototypes. The goal of concepting was to translate customer insights into customer and business requirements and explore solutions before validating the concept with customers.
Concept alternatives and prototypes were reviewed with the same internal stakeholders for iteration. Early technical explorations and architectural descriptions began within the development team. Dependencies on other teams across the organization were identified early for future work.
Customer Interviews and Concept Validation
Since this was a completely new service, we involved more customers than usual in customer interviews and concept validation. The structure of the customer interview/concept study mainly consisted of first mapping the customer’s current way of working. The customer explained in their own words how they currently operate/behave, what their motivations are, what problems they face, and what needs and desires could be identified. Only after this did we show different concept options and go through prototypes.
The purpose of the prototype is to serve solely as a storytelling tool. When I moderate or lead a concept study, I never let the customer use the prototype themselves. I walk through the prototype example by example, section by section, and explain how the service could work. After that, we reflect with the customer on how the service would work in their case, whether it solves their current problems, and if it meets their needs. Is there something missing, or what thoughts and feelings did the customer experience? At this point, the conversation usually shifts to different use cases that might not have come up in the customer’s current way of working. The customer starts asking, "How would this work if we did it this way..." From there, it's easy to pick up on the customer's needs and ask more questions to dig deeper.
The goal of concept validation is to validate the hypotheses of the concept and identify the precise customer needs that will evolve into requirements for the development team. In a concept study, the focus is never on the details of the user interface, even if the prototype is shown to the customers. The prototype purely supports storytelling, helps to visualize things, and fosters a dialogue between the customer and the interviewer.
After the concept study, we iterated on the concept based on feedback, updated the requirements into user stories so that software architects could create the final technical descriptions. Based on the concept study, we could also define the development roadmap for a long time, as we understood the big picture of the service and what functionalities made sense to develop at each stage.
Our division of labor was such that the service designer was primarily responsible for gathering customer insights, involving both customers and internal stakeholders, and conceptualizing. However, UX designers also participated in validating the concept study, often in the role of observers, so that as the people responsible for the detailed design, they would always have firsthand knowledge of the customers' behavior, problems, and needs.
After the conceptual phase, a larger development team started working on the service's MVP solution, with the main design responsibility shifting from the service designer to the UX designer. After that, the service designer supported and, when needed, coached the UX designers in the detailed design process.
UX Design: Detailed Design Begins
UX design is the design of user experience, meaning its goal is to design a service that is as usable and easy to use as possible, delivering value to the customer. UX design involves designing details, where interactions, navigation, UI components, the final visual appearance, texts, and error and special cases are defined. UX design is done in close collaboration with software developers and testers, and it is an ongoing dialogue about how to implement the details from both a technical and usability perspective. In UX design, the data to be collected is also defined, and data events are specified in the code to ensure they are included in the data analytics. After the service is launched, we can track, for example, which features customers use or don’t use, how they navigate the service, and whether they abandon certain tasks.
The task of UX design is to ensure the high-quality design of the service's details and its usability. UX design is an iterative process, where designs are continuously reviewed with the development team, brainstormed together to find the optimal solution from both the technical feasibility and usability perspectives.
Usability Testing Before Launch
Although we had gathered customer insights earlier and validated customer needs through a concept study, they alone are not enough. Usability testing is also needed to ensure that the details work and the service is easy to use for customers.
Usability testing and concept study differ in that usability tests focus, as the name suggests, on ensuring usability and details, while the concept study validates customer needs. Usability testing also differs in that the customer is given predefined tasks to perform independently using a prototype. If customers are unable to complete a task independently without the moderator's help, it indicates that certain aspects are too complex or difficult to use/understand, and they should be redesigned. Usability tests also evaluate how well customers can find things, navigate, and understand the meaning of terms and icons. Usually, at this stage, the customer is using a coded prototype, while in the concept study, the prototype is created with a prototyping tool or may only be a visualization of the service.
If customer insights were previously gathered and customer needs were validated through the concept study, nothing catastrophic should arise in usability tests that would undermine the whole team's work. Some functionalities might need to be redesigned or refined, and terms may need to be reconsidered before the service is launched. Some work can also be scheduled for the next release of the service if it is determined that they won't significantly degrade usability. The primary responsibility for the UX design phase and leading usability tests was always with the UX designer.
Continuous Improvement After Launch
When is a digital service ready? The answer is, never. The development of a digital service only ends when the plug is completely pulled out of the wall and the service is discontinued. Otherwise, the development of a digital service is continuous. The roadmap guides the work on a larger scale, and in addition, the service is continuously developed based on feedback and analytics. Customer feedback is gathered, and the usage of the service as well as customer behavior within the digital service is regularly monitored through data analytics. Additionally, the next areas from the roadmap are taken into development, and depending on the level of work, customer needs are either researched and conceptualized, or the user interface and usability are designed. Depending on the level of abstraction in the design, either a service designer or a UX designer will lead the design process.
Service Design Documentation
I want to highlight the documentation of service design here. I've often encountered situations where requirements have not been properly documented or where nothing has been properly documented at all. This gap compounds in all subsequent phases and causes headaches, especially for software architects who should be creating architectural descriptions based on the requirements.
When I have worked as a service designer, my working method has always included, whenever possible, gathering customer insights, creating an overall concept, and being responsible for its validation. This is because it is important to first understand the whole puzzle before working on the individual pieces. My working style is very participatory, and I prefer one-on-one conversations, especially with internal stakeholders, due to the efficient use of time, but also because people tend to share their thoughts and experiences more easily, avoiding the herd mentality that sometimes happens in workshops.
I have documented my work, for example, in Confluence or another wiki site, where the site includes the following elements. I use different canvases depending on the situation, and nowadays I usually develop my own models to best describe things in each case. The key point is not to fill out a certain number of canvases/templates, etc. The goal is not to fall in love with the outputs but with the outcome. There are many ways to reach the outcome; there is no one single correct way to proceed.
However, some level of documentation is wise because it helps other development team members and compiles all materials in one place. In large organizations, the same customer understanding can also be used by other parts of the organization, so it is important to make it accessible to everyone. The structure of the Confluence page is usually something like this when I have worked as a service designer:
Customer research reports
Internal insights documented
Big picture of the entire concept at a business level, often depicted as a mind map
Customer journeys or service blueprint
Possibly the use of a canvas such as empathy map, value proposition canvas, personas, business model canvas/business model innovation framework, or custom-developed models depending on the situation, etc.
Preliminary roadmap proposal reflecting customer insights (Usually, the product manager is responsible for the final roadmap. In addition to customer insights, many other factors influence the order in which things are done)
Requirements broken down into user stories
High-level UX concept for main views
Link to prototype
Service Design – Building Castles in the Air or Agile, Value-Producing Activities?
If we take a step back and think about why businesses exist—businesses exist to create value. The final verdict on any business is given by the customer. The customer decides whether you are worth the effort and price. Without the customer, there is no business, as the customer is always the source of revenue for any company. Therefore, it is not indifferent how products/services are developed. The goal should be to create something that the customer perceives as valuable and is willing to pay for. A pile of fancy features does nothing on its own. Any business activity that doesn’t aim at delivering value to the customer is completely pointless.
Service design is a holistic way to develop business by engaging customers and internal stakeholders. There are still many companies that, in the worst case, start coding things without any research into customer needs, requirements definition, validation, or planning. Then there are companies that do plan but immediately start focusing on details. What you see on the user interface is just one part of the truth when developing a business.
There are many aspects that need to be defined and planned which do not appear directly on the customer’s interface. Things should be designed at different abstraction levels, starting from the top level and then drilling down into details. If things are only planned and visualized at the user interface level, the focus is on the wrong things at the wrong time. In other words, focusing on trivial details too early when larger issues, such as the overall business model or how internal processes function around the service, should be addressed first.
The design process includes several phases of research, conceptualization, detailed design, and continuous improvement. Some might consider this approach as building castles in the air, where you start building a monolith step by step that never gets completed. Based on my own experience, I can offer a strong counter-argument. The working method is very iterative, participatory, agile, and many things happen simultaneously among different parties. Agile practices and a long-term vision are not mutually exclusive; they can happen in parallel. When service design is done systematically, it also provides long-term direction for the entire development team. Service design ensures that requirements are defined and validated and reduces risk by making sure the right things are being done and done correctly.
Conclusion
To conclude, let’s make a comparison with the real world. If you were building a house, would you order kilometers of 2x4 lumber, 100 kg of screws, and other construction materials to fill the landing lot, hire workers to build, and then say, "Build me a house, you know what a house is"? Would you do that? Definitely not. First, the house would be drawn by an architect, the construction details would be designed by a structural engineer, the plumbing and electrical plans would be drawn separately, you might even have interior design plans for the finishes, color schemes, etc., and the yard would need to be designed as well. And all the groundwork would have to be done correctly in the right places.
So why, in the digital world, do we still go straight into coding without properly planning things at different levels of abstraction? The more incomplete the requirements and plans are, whether for business, customer experience, or technical work, the more it causes trouble, confusion, and back-and-forth. What does this mean in practice? It’s a perfect waste of money and resources.
