What is Service Design?
If I had to describe service design in my own words to friends and family who have no prior knowledge of it, I would explain it as planning and organizing the working parts — people, infrastructure, products — in a way that best improves the interactions between the service provider and the user. It’s a process through which you must first search for and recognize connections and interactions a user will have while doing something, and by analyzing them create productive, optimal solutions and experiences. To best cover what I’ve learned in the past 7 weeks about service design, I’d have to take a more in-depth look at the most significant activities we did in class and their respective key takeaways.
Double Diamond Design Process
One of the first things we learned in class was how service design, like a lot of forms of user-centered design, follows a cyclical nature. This is represented best in the double diamond design process. The idea behind the double diamond is that design is constantly being modified and designers are always researching to perfect the product, as peoples’ needs evolve and change over time and services must do the same to stay relevant.
The four steps are the following: discover, define, develop, and deliver. Discover is the step where you figure out the needs of the organization and users involved. Define involves interpreting and aligning these needs, then moving on with research or converging on a concept. Develop involves developing, iterating, and prototyping possible solutions. Deliver occurs after you agree and finalize a final prototype, and then proceed with launching it for use. One article we read in class mentioned that the company that was being discussed had a version of the double diamond with a fifth stage — sustain, which makes sure the service can continue to thrive onward.
Service Safari
We started out our journey with service design with the Service Safari. It was an activity from early in the semester where we demonstrated the process of acquiring our favorite food. We had to document the experience and interactions we had. This allowed us to take a closer look at the tools we used, as well as all of the pieces that came into play — these are the touchpoints. I demonstrated how to order food on a self-service kiosk and pick it up at the location. This picture of ordering food became much bigger than I had ever really noticed before, as I had to consider the fact that I google locations on the map first, read the ratings on yelp, check their menus online to see the prices and real-life pictures of the food, and other such actions that require unique and separate touchpoints.
For the service safari assignment, one particular requirement was that we had to retell our experience through a presentation based around storytelling. The biggest takeaway I had from the Service Safari was the importance of telling a story, as it is the best way to communicate your steps to the audience. It puts them in your shoes. This activity was our gateway into analyzing and recognizing services and what things need to be considered for good and inclusive customer service. One example of this that came up from another classmates’ service safari at Five Guys was the need for emergency exits that are actually accessible for people with disabilities, and floor layout that takes into account the size of wheelchairs and need for ramps.
Service Blueprints, Stakeholder Maps, and Journey Maps
This led us into understanding what stakeholders may look like in a specific example. Stakeholders are any people or organizations (internal or external) who are invested in that service’s success. There are different tiers of stakeholders, internal, external, direct, indirect, core, and more. One article we covered in class, Human Machine Collaboration — Designing for a New Kind of Relationship expanded upon how, when thinking about the role of AI in the service design process, AI itself becomes a stakeholder. This is because it is involved as a tool during the design process — so even tools are necessary to consider in a map like this. On a separate note, communication yet again arose as something needed for service design. Proper translation of why AI may choose to calculate things a certain way and the nuances humans might see in things would enable a smoother relationship between human workers and AI tools, and is necessary to unlock the full potential of both.
You can see an example of the different types of stakeholders in this diagram we did for the in-class group assignment where we picked something and then created a map for it. Our group chose OMNY. What shocked me the most from this assignment was the sheer number of stakeholders involved. Rather than a singular product which has a user and a manufacturer, a service involves people you might not have considered since they might not directly interact with the service. For example, taxpayers or donors, public workers, people who decide where the turnstiles are placed, people who implement updates to OMNY — the picture becomes that much bigger, just like with the touchpoints and the service safari.
Next, we went into journey map creation, which is a layout of the user’s experience. It includes the phases the user is going through, the thoughts they have, the emotions they feel as they go through, and possible areas of improvement with their usual process of doing something. This was an activity I had done in prior classes, but I noted a few differences when applying it to a service — for example, there were many more things involved and more things to consider. The group I was in chose to analyze the process of using one of those dormitory laundry self-services. You can see how complex it got in how many unique post-it notes are up in the journey map.
We also created Service Blueprints, which are described as a “map of user journey, touchpoints, and backstage processes” in another assignment where we analyzed the process of signing up for classes on Albert. I had done a similar activity in a previous product design class, but I noted some differences. The main one was was how this blueprint includes not only the front-end experience but the back-end. This involved doing something very similar to the above activity, but not just with the user. You also have to consider the role of the staff and any things that are working behind the line of visibility, such as support systems, as they are as involved in the service as the users.
Mini Design Jam
Above all, what best secured my understanding of service design along my learning journey was the mini design jam activity we did in one class in the MakerSpace. A design jam is a collaborative brainstorming and prototyping event where teams are given a prompt that they must design a solution for. The prompt we were given was a drawing of an open box.
During this session we underwent a significantly more condensed version of the service design process, and the rapid pace of the design jam helped us focus on the most important steps. We started the session with mind mapping, a process of brainstorming where we visualized the connections between the object in the prompt and other things. I wrote down mainly connections that had to do with the delivery of packages and idea of disposability. The three of us had some overlap, but also several different ideas. One team member focused on transportation, imagining cars and buses as forms of boxes carrying or transporting riders. The common underline we all shared was the role of boxes in transporting goods, sustainability, and ease of use.
We then went into the research phase of the project and looked into existing issues and solutions related to the topics mentioned above. From there, we created a “how might we” statement, which is a problem statement we aim to design a service solution for. The “how might we” statement we came up with is shown below: “HMW reduce the environmental impact of box distribution while maintaining their functionality?”
Originally, we were thinking of perhaps creating a service where people could design their own custom boxes for things they want to pack with very specific shapes, or a service that would allow for easier disposal of packaging. Another idea we had was a service that would provide the customer with the option of requesting languages for their packing labels, rather than only being provided with the default option of English. The biggest obstacle we had was that we kept getting stuck in thinking of ways we could improve the design of the box rather than creating a service that would involve the concepts we had come up with. This product-centered approach would have helped us had we not been in a service design jam.
Because we were stuck on this, we decided to take a step back and think about the bigger picture, what we wanted the user to achieve by using the service we made. This was by far the most challenging part of the design process for us, as we kept coming back to the design of the physical item. Ironically, we had to think outside of the box in order to begin designing a service rather than a product. We decided to take our break at this time to let ourselves get a breather from thinking about the same issues and contexts, which was most likely limiting the solutions we could come up with.
Thanks to us stepping back and re-evaluating, I had the idea of a Too Good to Go service but for used boxes. Too Good to Go is a service where restaurants sell discounted bundles of leftover food from the day to people using the app in order to minimize the amount of food waste. The idea of applying this for boxes stemmed largely from the idea of small spaces in NYC. Lack of storage room in your living space is a common issue here in the city, especially in dorms where students most likely need access to boxes they can use when frequently moving in and out of places. After we reconvened during the break, we went into the crazy 8s activity where we generated 8 versions of possible service design solutions to fulfil our HMW. I’ve attached my version of this document below, which illustrates the directions I took our service — I thought of it mostly as an opportunity for people recycling, reusing, or donating these boxes in different situations, like the post office or as part of a dormitory.
Finally, we decided on our prototype, which would be a service through which people could go to the post office and either drop off or obtain used cardboard boxes for no charge. The boxes would be sorted by their dimensions, with the range of sizes displayed on the outside of the different bins they were dropped off in. There would also be an infographic on how to best disassemble a cardboard box so others could use it, as well as a QR code that would link to that same infographic on the UPS website that you could share with your friends to spread the word (pictured below). We created a user map and storyboard as well as a simple physical prototype and demonstrated it to the class in the form of a story. I had taken product design classes in prior semesters where I had been exposed to these activities, but this challenged me to get outside of the mindset that I had to be designing a product, and to look closer at what exactly defines a service.
The Role of Communication in Service Design
Another big takeaway was from one of the guest speakers from class, Carol Massá. She gave us a glimpse into how service design works in a specific field which had to deal with medical services and aiding patients. She continued the trend and placed more stress on the importance of communication, a common thread seen ever since beginning of the course in the Service Safari activity. This was demonstrated in the fact that as someone participating in the design of a service, you can be working with people remotely across the map and need to make sure everyone is up to date on what needs to be done. Maintaining these connections is important for the service to be designed productively and successfully, and the key to this communication is listening. She also mentioned language difficulties explicitly arising in the project she worked on. This arose from being unable to communicate with patrons who only spoke Spanish, and how that was overlooked in the earlier steps of the design process.
We had also read about this role of communication in service design and design for users in general in an excerpt from the book The Culture Map by Erin Meyer. It touched on how different cultures may have different methods of communication and how these differences must be taken into account during the design process, as you want to make sure you can get the most accurate information out of people without unintentionally leading them to hide anything. This miscommunication could lead to important parts of the user experience being emitted, and the service not succeeding because of that. The article covered different communication styles, including applications-first thinking, which I most resonate with. It’s a method of communication where you take a closer look at how other people use things and from that observation come to conclusions, rather than observation based thinking that has to deal more with theory. We discussed this in groups, and found that there is a lot of difference in the kinds of communication people prefer.
The second guest speaker who visited, Dongin Shin, spoke about communication again but from a different viewpoint. She mentioned that it’s important to understand things from a financial or business viewpoint because of the common struggle designers have of being seen as not really understanding the issue they’re designing for, just because they see it in terms different to, say, someone working on it from a financial point of view. I came away from both speakers’ visits understanding that it’s important as a service designer that you “speak the same language” even when you don’t, and to make those adjustments so that you can.
My Future with Service Design
Moving forward outside of this course, I can see myself applying the practices I’ve learned about service design in designing applications and queries at work. Since I plan to work in a field where it’s important that the outward facing interface functions as efficiently as the backend, it’s necessary that the interface also meet the needs of all stakeholders and not just work in a way that makes sense to the developers. Taking the time to identify all possible stakeholders related to the service I’m designing lets me know who we have to consider inside and outside of the user base. For example, for a database that gets displayed to a user I need to know who we are getting the information from, who we are displaying it to, who is getting that information from those stakeholders who have it, how they are showing it or recording, what it means to those who are reading it, and other such things to properly design the interface in a way where access is intuitive and can reveal onlythe information they most need. By applying this sort of service analysis, I can more assuredly ensure that the design overall is effective for all users.
