We build a back office for medical clinics, and nobody on the team had ever run one. So for two weeks, the whole company did — on our own product, competing for patients. This is what that did to the product, and to the team.
The problem: we were not our own users
Most of the time, the people designing a product are not the people it is for. So we lean on personas and try to think from a chair we have never sat in.
Just when I thought I knew our users well, a few real interviews knocked that out of me. We had shipped plenty of features. The things clinics needed most were not among them.
It made me ask: do we understand our users, or do we only think we do?
A course by Lydia on realising UX value gave me the way in: immersion. Put the team inside the product as users and they will find its strengths and weaknesses themselves — and the whole team shifts from reading data and guessing to experiencing and observing.
The catch: our product is a B2B back office for clinics. How do you build a setting realistic enough for people to be genuinely immersed in a world that is not theirs?
The setup: a two-week virtual clinic contest
After a good deal of planning we settled on a contest. Teams would run clinics on our own system, and the friction they hit along the way would become the product’s to-do list.
It ran for ten working days. Every afternoon, for two or three hours, teams worked through a series of clinic-management challenges, and the final ranking came down to patient numbers and bookings. The patients were the rest of the company, booking through the LINE rich menu.
What we wanted out of it
- Have everyone run the full workflow of the clinic system and feel how it shapes a clinic’s day.
- Build a real understanding of how clinics use it and where it hurts — a shift from the builder’s view to the user’s.
- Collect concrete improvements: which flows are not intuitive, which features still need work.
Less a training session than an experiment in eating our own dog food: become the users, and find out what the product is actually worth.
What happened
Beyond exercising the system, the point was to simulate running a clinic. Each day’s challenge turned on that: setting up the clinic profile, tuning the booking flow, dealing with something unexpected. Every team was trying to attract more patients and run a tighter operation.
What surprised us was that the contest did more than teach people the product. It set off a wave of creativity and collaboration nobody had planned for.
We had expected people to follow the rules and complete the tasks. Instead they threw themselves in. Designers, engineers, and salespeople were finding bugs and fixing them without being asked — and normally getting a small fix done takes several reminders.
The moment someone hit a problem or an awkward flow, engineers were proposing changes and pointing at the parts of the architecture that needed adjusting. Front-end engineers were suggesting smoother interactions. Designers were refining the experience so every action made sense.
Those cross-team conversations — from bug fixes to flow improvements — were worth far more than the competition itself. People were not just completing tasks; they were pushing the product forward.
What we got out of it
The contest was designed to help the team understand users through immersion and to surface the product’s pain points. What came out of it went well past that.
1. Bugs fixed and flows improved on the spot
Details that hide behind the data surfaced one after another: small things in the booking flow, how screens looked on a phone. Using the product ourselves exposed the problems that actually affect users, and many were fixed during the two weeks.
2. Faster cross-team decisions, closer to users
Before, requests came back through business development or account managers, and the PM had to divine whether a request would pass and whether it really matched what other users wanted.
After everyone had played the user, design, engineering, and sales reached agreement much faster. Designers no longer had to imagine the situation; engineers understood design decisions more intuitively; every handoff got smoother.
3. The team started thinking from the user’s side by default
After the contest, people were noticeably more willing to take the user’s perspective. Working through a task, they no longer began with what was feasible to build; they asked first whether it would really help the user, and whether there was a more intuitive way.
That habit is spreading through the team and slowly changing how we make decisions.
Where this goes next
The contest taught us that understanding users does not come from data and assumptions. It comes from doing what they do.
We want to make this a regular practice: internal immersion sessions that put every team member in the user’s seat — so that we are not only designing products for users, but growing alongside them and building something closer to what they need.
