In Norse, we work with new and existing clients to discover and define meaningful and interesting digital initiatives. We also receive several start-up pitches from Norselab, our parent-company which we work closely with. We have an idea, a concept, and it’s time to develop. In this article, you will get an insight into how we execute service design and how we work from a concept to a validated product.
Why a service design process
In Norse, we employ a service design mindset to lower the risk of developing something that doesn't give a purpose to the user. With this process, we get to understand who we are creating for, and their needs. We get to test our thoughts and ideas through a prototype to validate that we are on the right path to creating a user-centric solution that gives value to the user.
Gather your insight
We always start with clearing out minds and gather the insight we have received from the client. We always start by analyzing what we have and try to understand what the core problem is. After analyzing the material, we end up with a problem statement, and from that statement, we start to define hypotheses. These hypotheses set the ground for our next activity, user research.
But what if we are creating a new service and start with no data to analyze? Well, then we start to look for similar services to see how the service, we are creating can be better and more valuable for the user. One tip is to use the Blue Ocean Strategy to map out areas where similar services don't perform, where you can take a leading position.
After understanding the potential for the new service, we then set hypotheses and start our user research.
Understand the user
As service developers, it’s crucial to understand the users of the service. We are creating something for them, not us. In Norse, we have a toolbox with many tools and methods to understand the user, and the one we use the most is user interviews. By interviewing potential users you get to know them on a whole new level, and you get the possibility to be curious and ask all the burning questions that you have.
When we plan an interview, we bring the hypotheses that we defined earlier and use them as a base for the questions. By doing this, we get to validate our hypotheses during the interview and end up with a deeper understanding of what the user needs and what we need to create.
Author conducting an interview on a bus
There are many ways to conduct an interview, and what we like to do is to visit the users in their environment. Yes, it’s tempting to invite them to the office, book a cold meeting room, and interview them in your environment. But when you go out to the users, they tend to relax and open up more than in the meeting room. You also get the opportunity to see how they act in the environment that the service is going to be used.
As I mentioned, we have several tools to understand the user, but we can’t cover it all in this post. Our best tip is to be curious. Go out to where the user of the service is, observe, be curious and ask questions. It doesn't matter if it’s on a bus for a new travel app or at a school cafeteria for a new learning platform, the same principles apply.
Find the thread
Okay! Now we have a lot of material and insights from the user, and it’s time to find the thread. We go back to the screen and analyze the material that we have gathered. The goal is to validate the hypotheses that we defined earlier, and we do that by looking at the answers and compare them to each other.
Let's say our hypothesis is “It’s complicated to find the right bus.” To validate this we find all the answers and feedback regarding finding the right bus. If we see the people we talked to repeatedly express that it’s hard to find the right bus, we can say we validate the hypothesis. Now we know that our users find it hard to find the correct bus and that this is a need for them in the service we are creating.
Define the user journey and the content
With our validated, or not validated, hypothesis and user insight, we can start to define what we need to create. In Norse, we usually do this by drawing out the user journey and core content. We invite the client to a workshop where we share our learnings and together, we start to draw out what we think may be the optimal solution for the user.
When we have the user journey, which often results in site types, we can get into the content. As a part of good user flow, it’s crucial to have the right content in the right place. We often use an activity called the Core Model to help us define this.
We also have tools to test the core content and user journey. Optimal Workshop has several services they offer and we use their services to test side structure and content.
Our team working on core content for a client
Wireframing, prototyping & test, test, test!
Now we have plenty of material to start the next phase, wireframing. Our service designer starts to wireframe the pages we need in Sketch and creates a prototype in InVision. We use the user journey we defined earlier as a map of what we need to sketch out, and to help us define the paths the user should go through during our test.
We always test our prototypes on the users of the service. We do this to make sure we create a service that gives meaning and is user-friendly. When we do a user test, we invite users to go through 3–5 tasks. The tasks are based on the core content and user journey, so we can see if the information is intuitively located and easy to understand.
After the user test, we go back to look at the results. We analyze the findings and iterate the sketches to improve the user experience and update the prototype. Then, we book new users in to test the updated prototype to see if our improvements give a better experience for the user. After the second test, we go back and analyze the results, change the design after the feedback from the user and update the prototype.
If we don’t find any further areas of improvement, we have a validated prototype. If we still find critical areas of improvement, we do the necessary iterations and run another user test, until we are confident that we have something that the users really need.