When the QR code stopped working

PRACTISE 5

I started this internship the way most service design projects start, with a research plan that looked clean on paper. I ended it the way most of them actually end, with a different plan, and a lesson about respecting the environment you're researching.

Tropical Nomad is a coworking space in Bali.


The brief was open: map the end-to-end member journey, find the friction points, and prepare the team to act on them. The promise the space sells is smooth focused work. The reality, like most services, is a stack of small moments that either hold the promise together or quietly break it.

Speculative

Futurism

Design challenge

IKEA

Starting in the field, not in slides

Before talking to anyone, I ran a Service Safari, walking through the experience as a member would. Arrival. First-minute onboarding. Wi-Fi setup. Picking a zone. Trying to take a call. Asking for help when something broke.


This wasn't research yet, it was orientation. But it gave me a baseline of the actual service moments before any staff or member could tell me what they thought happened. Designing solutions from secondhand descriptions of a service is one of the fastest ways to design the wrong thing.

Mapping who actually runs the service

Coworking looks like a reception desk to a member. Behind that desk is a service system. Stakeholder mapping turned up Community Desk, Operations, Marketing, Security, Public Area staff, Maintenance, F&B, plus third parties like the ISP and Google Reviews. Each of them shapes some part of the experience. None of them owned the experience as a whole.


That's the actual problem in most service design work. Not "the Wi-Fi is bad." It's "no one owns the moment when the Wi-Fi is bad."

The QR code that nobody finished

My initial plan for member research was a Typeform survey behind a QR code on the wall. Clean, scalable, low-friction.


It didn't work. People opened it. Almost nobody finished it.

That moment was the most useful failure of the project. Coworking is a deep-work environment. A passive feedback prompt has to compete with calls, deadlines, and flow. The method assumed members had spare attention. They didn't.

So I pivoted. Instead of waiting for responses, I approached members directly, ran short conversations, and in many cases filled out the survey with them. Participation went up immediately, and so did the depth of what they told me. Not just what they chose, but why.


One member said something I keep thinking about. He described staff who didn't listen properly to him, even when he had to use Google Translate. That single observation reframed the whole onboarding question. The friction wasn't in any system. It was in the listening.

Service Blueprint as shared truth

I synthesised everything into a Service Blueprint covering the journey from first Google search to daily deep work. Frontstage, backstage, and third-party dependencies in one view. The blueprint became the team's single reference for where the service actually breaks.


Then I facilitated a How Might We workshop with Community Desk, Operations, and management in one room, using the blueprint as the shared map. I didn't bring solutions, I brought reframed questions. The team generated ideas, dot-voted, and prioritised what to test first.


The most valuable output of the workshop wasn't on the board. It was the disagreements that finally got said out loud. Things like who actually handles a member complaint, and what "fast onboarding" means in practice, had been silently assumed for months. Once they were on the table, they could be fixed.

What I'm taking with me

Two things, written down because I want to remember them.

The method has to match the environment. A QR survey in a deep-work space isn't research, it's an interruption. When the data isn't coming in, the method is wrong, not the participants.


The most valuable workshop output isn't the ideas. It's the alignment. Or the disagreements that surface when alignment was assumed. A workshop where everyone agrees too quickly is a workshop where nothing was actually said.

© MUNI
(WDX® — 02)
Design
© Help Center
(WDX® — 08)
Clarifications
© Help Center
(WDX® — 08)
Clarifications
© Help Center
(WDX® — 08)
Clarifications

FAQ.

FAQ.

Defining outcomes through a transparent process and honest dialogue.

01

What services do you offer?

02

What is your typical process?

03

How do you identify what users truly need?

04

Why invest in research instead of jumping straight into design?

05

What is your primary goal when designing an interface?

06

What exactly is the "output" of your work?

What services do you offer?

What is your typical process?

How do you identify what users truly need?

Why invest in research instead of jumping straight into design?

What is your primary goal when designing an interface?

What exactly is the "output" of your work?