How do you test and iterate your Service Design solutions in real-world scenarios?

An example I’ve seen is from the McDonald’s Speedee Service System that Dick and Mac McDonald invented to serve fast food fast. In the movie “The Founder”, you can watch how the McDonald’s brothers prototyped and tested their kitchen design over 6 hours with 10+ staffs on a tennis court. So how did they prototype and test their solution? By drawing the exact dimensions of the kitchen and the individual stations using coloured chalks on the tennis court floor. They also got the staffs to role-play their respective stations responsibilities like grilling burgers to applying the sauce, exactly on their designated station locations as indicated on the chalk drawings. Nothing fancy. Just some hard work and chalk drawings on the floor.

Ah, prototyping, what a game-changer in stakeholder management! You see, diving into the nitty-gritty of a project with a prototype really helps align the team. It's like handing out a map in the middle of a forest—everyone suddenly sees the same path. Orchestrating stakeholders is like conducting a symphony; prototyping harmonizes everyone's thoughts, inviting them to shape it with insights. Do you want to dodge those misunderstandings and misinterpretations? Prototyping is your shield. And when they engage with it, it's magical—they feel a part of the creation, not just spectators. And the best part? It's the ultimate insurance policy against future hiccups.

A very interesting and quick way to create storyboards within Service Design is by using AI generated images. Just give the right command and a story board will be created for you. This can also be evolved in case continuous concept development is buying done.

When planning the test, start by defining the KPIs and metrics you need to monitor. Assign specific responsibilities to team members to ensure these are tracked accurately. Often, KPIs are missed due to execution issues, leading to underwhelming results. To avoid this, have backup plans in place to cover any gaps. Clearly explain why each metric is important, ensuring everyone understands their relevance. This thorough planning ensures comprehensive data collection and more reliable outcomes.

Test the right things for your project! This might seem obvious, but I’ve been in situations where our prototype didn’t provide the answers we needed. One reason was that, in the pursuit of making the prototype a “success,” we focused too much on artificial performance indicators rather than on what we truly wanted to learn from it. The prototype ended up being perfect for another project but subpar for ours. I hope you can avoid making this mistake.

Although research is typically considered the preferred approach, an increasing number of companies are turning to real-world pilot tests within smaller ecosystems to accelerate the process. While I don't advocate for this route, if teams choose to pursue it, it's crucial to conduct a comprehensive cost comparison between the two methods. Real-life pilot tests have occasionally proven to deliver quicker and more efficient results compared to research alone.

During testing, it can be very challenging for facilitators not to get too involved and risk muddying the results. Even though you may have worked hard to create a prototype, and it’s frustrating to see users struggle with it, avoid jumping in to “solve” the prototype for them or leading them through answers with guiding questions. Understand that while there’s a strong urge to assist, the purpose of testing is to observe genuine interactions and challenges. Foster a supportive and productive environment where users feel at ease, rather than treating it like a high-stakes exam.

To begin with, in order to analyze anything effectively, it's crucial to plan the test/experiment properly. Depending on what we are testing, we should carefully consider the tools for measurement. In the case of webpage, tools like Google Analytics may be sufficient, but it’s also worth using tools like Hotjar. However, during internal tests of services for employees, it might be beneficial to define the metrics ourselves and sometimes manually measure the process or user actions. Standard usability metrics like SUS (System Usability Scale) may not always be sufficient; it might be worth considering TPI (Task Performance Indicator) or developing your own measure or metric.

Iteration requires refining your prototype and solution by incorporating feedback and testing it with real users and stakeholders. While this process is essential for improving the desirability, feasibility, and viability of your solution, it can be particularly challenging. Why? One reason is that iteration is rarely a straightforward process- changing digital prototypes and offline customer journeys and processes could be time-consuming and budget-consuming even on prorotypes. Additionally, balancing conflicting feedback from diverse stakeholders or users can complicate the decision process. Remember, first test the value proposition; based on it, build the CJ solution, and then create digital prototypes and processes for testing.

Yo...you designed dope service solution But testin' and iteratin' is the real revolution Can't just ship it and dip, gotta put it through its paces See how it hits in real-world use cases Gather real people get them to interact Coz that honest feedback's a must to extract Don't just stick to sterile usability tests Take it to the field face those real-world quests Dive deep in the data both quant and qual No insight' too small to make the service call Wash, rinse, repeat until that design is blazin' Continuously iterate, solutions keep raisin' Real-world testing is the service design grail Without it even hot ideas will fail! Rap's done, mic drop, I've said my rhyme Now go out there and leave no one behind! ? in collab with Claude ??