At Renben, we’ve learned that great software doesn’t start with code. It starts with people, with listening to their daily struggles, the clever workarounds they’ve invented, and their own definition of success.
That’s why we run our Exploration Workshops.
They’re not just requirements meetings. They’re one week of deep, hands-on user research where we roll up our sleeves, step into the users’ world, and see the work through their eyes. We map workflows, spot the “happy paths” where things click, and shine a light on the pain points that slow everything down.
And we’ve seen it again and again, if you only talk to business owners or project leads, you never get the full picture. The real breakthroughs happen when the people who actually do the work have a voice in shaping the solution.
Earlier this year, we were invited to help a financial institution create a new software system for a team spread across different regions. The challenge? Each region had been working in its own silo, with no central system to tie their work together.
Before we even stepped into the workshop room, we spent a week meeting with the project team members, analysing the business processes. These early sessions gave us a sneak peek into how the work flowed and where it broke down, so we didn’t walk in on Day One completely in the dark.
We kicked off in a big room with walls ready to be filled with sticky notes. From the outside, it might have looked like arts and crafts, but for us, these tools are how you make complex systems visible.
We skipped stiff introductions and instead shared small, personal stories, the kind that spark connection and break down barriers. That set the tone for the rest of the week: open, collaborative, and curious.
Once everyone was settled, we talked about long-term goals. Not just project goals, but what success would look like for the people using the system every day. And then we asked the question that always changes the room:
“How could we fail?”
Suddenly, the room was open, candid, and honest.
It’s not a pessimistic question. It’s an invitation for honesty. Risks and worries surfaced early, the kind of things that, if left unspoken, tend to become last-minute surprises.
Then we got to the heart of it, talking to the users from each region. These weren’t managers or consultants; these were the people who lived and breathed the process every day.
It didn’t take long to see the pattern: while their goals were aligned, their approaches were vastly different. That inconsistency was a big part of why this new software needed to exist.
As they shared their experiences, we captured notes in our “How Might We” format — short, open-ended questions that frame problems as opportunities. Later, we grouped them into themes, which gave shape to our Project Problem Statement and a shared Vision everyone could agree on.
To keep things moving while making sure no valuable thoughts got lost, we also introduced our Bike Rack, a section on the wall where we “parked” questions or tricky points that needed a deeper discussion later. This way, we stayed focused in the moment, but still made sure nothing slipped through the cracks.
Now that we knew what needed solving, we dug deeper into who we were solving it for. We explored the roles, responsibilities, and everyday roadblocks of both customers and internal people.
This led us to one of the most powerful tools, the As-Is Service Blueprint. Imagine a giant map of how users and customers currently interact with the system, with happy paths marked in one color and pain points in another.
What made this moment so engaging wasn’t just the mapping itself; it was watching the users come alive in the process. They weren’t just passively answering our questions anymore; they were talking to each other, debating steps, and building the blueprint together. Conversations sparked, and we could see consensus forming right there in the room about what the real pain points were and what needed fixing.
By now, the ice had long melted. The walls were filling with sticky notes, and the energy in the room was electric. Users were physically walking up, placing stickies on the blueprint, and making the map their own.
Then came the To-Be Service Blueprint. The rule was simple: keep the happy paths happy, and turn pain points into positive experiences. By the time we finished, we weren’t just looking at a blueprint. We were looking at a shared vision of what the future could be, created by the very people who would live it.
By the end of the week, the room looked like a living mural, covered in notes, diagrams, and ideas. But more importantly, the people in that room were no longer just from “different teams” or “different regions.” We had broken down the silos. Everyone understood the system, the challenges, and the goals ahead together.
We pulled everything together into our Exploration Workshop Outbrief Deck and presented it to users, product owners, and stakeholders. Those insights became a prioritized backlog of features that the software needed.
But we didn’t stop there. As we moved forward, we kept testing, learning, and refining because designing with users, not just for them, is how you build the software they need.
Looking back, this workshop was the turning point. It turned uncertainty into clarity, scattered voices into a shared vision, and ideas into a roadmap. When the software was finally delivered, it wasn’t just a tool; it was something built with the people who would rely on it every day.
That’s the real secret. If you want to build the right thing, don’t just design for users. Design with them.