Fix It Between Sessions: How RITE Beats the One-Shot Study

You run a study, gather findings, then hand a stack of problems to the team weeks later. By then the build has moved on, the fixes feel like homework, and nobody is sure the changes worked. The waiting is the waste. There is a better rhythm: test a few people, fix what broke, test again with fresh people. You learn whether your fix actually worked before you ship it. Here is how to run that loop without kidding yourself about the data.

The deep cut

• Research and design are one loop, not two handoffs. RITE, born in Microsoft's gaming division, updates the prototype the moment an issue surfaces.
• Speed used to dodge research becomes a lie. GitLab warns that fixing after the study, untested, turns RITE back into a plain study with unproven fixes.
• Classify every issue before you touch the prototype. GitLab's A, B, C buckets decide what you fix now, plan later, or watch.

Why one big study leaves you guessing

The old way batches everything. You test the same prototype with a dozen people, then meet after to sort the wreckage. You find common problems, sure, but you never learn if your fixes land. You just ship them and hope. Peep Laja makes the plain case for the opposite in iterative A/B testing: when you cannot predict how people will behave, small repeated tests beat one big redesign bet.

RITE closes that gap. As Sara Mansell puts it, the method updates the prototype the moment an issue shows up instead of waiting for the study to end. After one to three people hit a wall, you change the design before the next person sits down. You are testing your fix, not just your first guess.

The loop: three people, fix, three more

The GitLab handbook spells out the rhythm cleanly. Start with three participants. If you find issues, fix them, and run three fresh people. If you find nothing, add two more to reach five. Hit five with no new problems and you are done. That is it. The small batch is the point, not a shortcut.

Why three? Because the count adds up across rounds. Each iteration stacks more real users onto the pile, so problems surface over time while you fix as you go. You stop when a clean run of five turns up nothing new. At that point you are not hoping the design works. You watched it work.

Sort issues before you rush to fix

Speed tempts teams to patch the first thing they see. Do not. GitLab sorts every problem into three buckets. Category A has an obvious cause and a quick fix, like relabeling a button, so you change it before the next session. Category B has a clear fix that takes longer, so you start it and test in a later round. Category C has no obvious cause, so you collect more data until it earns a promotion to A or B.

Paula Barraza pushes the same discipline from a different angle in her tips for iterative testing. Keep a master list of every issue on a Kanban board, from "identified" to "tested well" to "implemented." She also warns against chasing only quick fixes. Dig for the root cause, or you will keep bandaging the same wound.

Where teams cut the wrong corner

RITE is fast, and that speed gets abused. Mansell is blunt: do not use it just to spend less on research or to wave a "we tested it" card at your boss. Two real risks come with the small sample. You can spend a design day fixing something that hurts less than one percent of users, because with three people you cannot always judge how big a problem is. This is where a researcher with heuristics knowledge earns their seat.

The deeper trap is faking the loop. GitLab is clear: if you skip the clean five-person run and push fixes out untested after the study, you no longer have RITE. You have a normal study with unproven changes bolted on. Brian Sullivan's ways to test faster trim the cycle honestly, on recruiting and scripts, not by dropping the retest.

Set the team up to move at this pace

RITE only works if the whole team is in the room, not waiting on a report. Mansell alternates test days and design days on a shared whiteboard schedule, with the product team watching each session live from a separate room and dropping issues on sticky notes. GitLab makes the same call: decision makers watch the sessions so they can react fast, because domain knowledge is what tells you whether a problem will hurt other users too.

Use low or mid-fidelity prototypes so you can change them overnight. A coded prototype drags in developers and kills the speed. Barraza adds a warning worth taping to your monitor: define exit criteria up front, or the pace burns your researchers out. Kelly Dern's rapid testing guide shows a designer can run this without a full research team. The BTS team fixes and re-tests known problems inside a single week.

Three questions for your team

• Which known experience issues could we test, fix, and retest inside one week, and who can make the fix between sessions?
• What are our exit criteria for this round, meaning what does "done" look like before we start, so we stop when five clean sessions turn up nothing new?
• Where is our current test cycle slowest, recruiting, scripts, or fixes, and which one tactic could we change this month without dropping the retest?