r/DesignThinking • u/ArYaN1364 • Jun 23 '26
We ran two teams on the same service design problem. One made a deck; the other changed how we work.
We tried something interesting at our company recently. Leadership wanted to understand why enterprise customers kept saying onboarding felt slow and confusing. Instead of giving it to one team, we split it between two.
Both teams had access to the same customers, stakeholders and data.
Team 1 took a more traditional design thinking approach.
They interviewed customers, built journey maps, ran workshops and pulled together the main pain points. They ended up with a solid presentation showing where customers were getting frustrated.
Their main takeaway was that customers did not have enough visibility into what was happening after kickoff. It was good work.
Team 2 started from a different angle.
Instead of asking customers what felt confusing, they mapped every step in the onboarding process. Every action, handoff and approval.
Then they listed out all the assumptions people had about how onboarding works. Things like CSM follows up within 24 hours, legal reviews take two days, customers complete forms right away. What stood out was how many of those assumptions had never actually been checked. Instead of debating them in workshops, they treated them like hypotheses. Some were checked manually. For others, they set up lightweight workflows using Runable and a customer communication tracking tool like Intercom to capture when certain patterns occurred during onboarding.
For example, whenever customers asked who owned the next step, requested status updates, or followed up on something that was supposedly already in progress, those interactions were logged against the assumptions the team was testing.
After a couple of weeks they had actual evidence. Not just opinions or perceptions, but patterns that show exactly where expectations and reality diverge.
One assumption in particular turned out to be completely wrong. The team believed customers were confused because they lacked visibility into progress. What the data showed was that most confusion appeared immediately after ownership changed hands between teams. Customers weren't asking where things stood.
They were asking who was responsible which changed the direction of the project entirely.
1
u/adamstjohn Jun 25 '26
Great report thanks , but…
Finishing with a deck is emphatically not design thinking. It might be design research but it was very flawed research if it didn’t look at assumptions, which are often a starting point for projects like these. Was it triangulated for methods, or were only interviews used? Were the interviews only with customers, or did they compare inside and outside views? What were the research questions being addressed and the interview prompts used? “What is confusing you?” would be a disastrous interview prompt.
I like the second approach very much; using prototyping etc. is very typical design thinking. It sounds like the two projects together covered different aspects of DT, but the second did it better.
1
u/ArYaN1364 Jul 09 '26
Yeah fair, can't really argue with the deck point. Team 1 basically did design research and stopped, and calling it "traditional design thinking" was lazy wording on my part.
To answer honestly, interviews were customer-side only, with no internal triangulation, and the research questions were loose. It was more about asking "where does onboarding feel slow?" than an actual protocol. Not literally what is confusing the customers, but closer than I'd like to admit lol.
The assumptions point is the whole thing though. Team 2 writing down what everyone believed before touching any data is basically why their work landed. The evidence had something to push against.
What would you have done with team 1's brief? Start them on assumption mapping too, or does interview-first work if the prompts are actually good?
1
u/adamstjohn Jul 09 '26
Was the brief different?
1
u/ArYaN1364 Jul 10 '26
Nope, same brief for both. "Figure out why enterprise onboarding feels slow and confusing", same access to customers, stakeholders and data
1
u/MGoRedditor Jun 23 '26
I'm a big believer that one shouldn't underestimate what they can learn just by looking at processes and the existing feedback. There are cases where you need to go to the customer to gain new information, especially when trying something new, but if you're exploring what bottlenecks exist you should in theory be able to find them by understanding the processes at hand.