Skip to content
Better ways to work.
More room to grow.
Join the newsletter

The prototype is ready. The research plan isn’t.

You have people booked for research next week. The prototype works, but the team is still arguing about what to test. Asking an AI to pretend to be a customer produces plenty of opinions and very little you can use.

Time with real participants is valuable. Your researchers should be able to use it to listen and follow an unexpected answer, not discover that the task never worked in the prototype.

Korium in this storyMemory + Code + Skills + Workflows

An illustrative story, not a customer result. No customer is depicted.

Follow the work

01What keeps happening

Every simulated user starts fresh and conveniently likes the new design.

Your team is changing the first-use experience for a collaboration tool. Earlier research found people hesitating when asked to invite colleagues before they had tried it themselves.

The new prototype lets someone try a sample project before sending an invitation. You ask an AI to play a potential customer, but its answers assume features the prototype does not have and forget the concerns raised in the previous rehearsal.

The team ends up debating which generated opinion sounds convincing. Meanwhile, the actual research plan still does not say what you need to learn from the people who are about to join the session.

Where the explanation gets lost
  1. Earlier research raises a concern
  2. Each AI rehearsal starts without the history
  3. Generated opinions are treated as findings
  4. The real session has no clear question

02Where we would start

We’d rehearse to prepare for real people, not to replace them.

We’d start with the permitted, de-identified research and the product decision it informs. What did people actually do, what are we assuming, and what does the new prototype let someone try?

Then we’d define a synthetic user by a motivation: they want to see whether the tool helps before asking colleagues to spend time on it. We’d keep that motivation and the history of each rehearsal, rather than inventing a demographic profile and treating it as representative.

03What Korium would keep

Keep observed behavior, simulated experience and open questions distinct.

The assistant could save a clearly labeled rehearsal note in Korium, with a reference to the research it draws on:

An illustrative Korium note
“Synthetic rehearsal, not an observation of a real person. This simulated user wants to try the product before inviting colleagues and declined the invitation in the earlier rehearsal. In the sample-project prototype, test whether they can complete that trial; any concern generated here is a hypothesis for research, not a validated finding.”

Source: The approved, de-identified research summary for the original hesitation, plus the synthetic persona instructions, rehearsal history and prototype version for the generated material.

04The next person, the next task

The rehearsal ends with a better research task, not a claim that users approve.

In the next rehearsal, the assistant retrieves the same motivation and earlier simulated experience. It does not turn yesterday’s reluctance into unexplained enthusiasm simply because the conversation is new.

For this coded prototype, Korium:code helps locate the sample-project and invitation paths so the team can verify what the current build actually allows. A research skill guides the rehearsal and separates generated assumptions from source evidence; the workflow ends with a researcher choosing what to test with people.

Suppose the rehearsal raises a question about who can see the sample project. The researcher can add a neutral task to the real session: try the product, then decide whether to bring a colleague into it and explain that decision.

A plan based on the saved explanation

  1. Verify the trial and invitation paths in the current prototype before rehearsing them.
  2. Carry the simulated user’s motivation and earlier experience into the new scenario, and label the output as synthetic.
  3. Turn the unresolved questions into tasks a researcher can test with real participants.

05Memory + Code + Skills + Workflows

Which parts of Korium help here?

Memory keeps the research sources and the simulated history. Code helps check the working prototype, skills give the rehearsal a consistent method, and a workflow takes its questions into real research and brings the findings back.

MemoryKorium:mem

Remember what is known and what the simulated user has experienced.

Korium:mem keeps the approved research references, the persona’s motivation and the history of each rehearsal. Synthetic material is labeled separately from actual observations so an assistant cannot legitimately cite a simulated reaction as something a participant said.

CodeKorium:code

Ground the scenario in a prototype that actually exists.

Korium:code locates the named functions behind the trial, sample project and invitation paths in the indexed commit. The team reads the current code and tests the build before setting the scenario; code lookup can establish where a behavior is implemented, not whether a person will like it.

SkillsKorium:skills

Give every rehearsal the same research discipline.

We’d adapt a skill for defining motivations, writing neutral tasks and challenging unsupported assumptions. It would require the assistant to distinguish source evidence from generated responses and report contradictions instead of manufacturing agreement with the design.

WorkflowsKorium:workflows

Take the rehearsal into real research, then revise what is remembered.

The workflow would retrieve the research and prior rehearsal, check the prototype, run the scenario with the research skill and prepare questions for researcher review. After real sessions, it would save the observations with their sources and connect corrections to the earlier hypotheses.

06What the team can do next

Make the time with real participants count.

Suppose the real sessions show that people can use the sample project but cannot tell who will see it after an invitation. Save those observations separately from the earlier simulation and revise the team’s explanation of the problem.

The next rehearsal can start from that better understanding, with the source and the limits of what was observed. Memory makes the simulated experience continuous; real research remains the way to check whether its questions matter to people.

A rehearsal can help the researcher resolve prototype problems and sharpen the starting questions before anyone arrives. During the real session, they have more room to notice hesitation, ask a follow-up and hear something the team did not expect. Those observations, not the simulation, should shape the next product decision.

How we would check whether it helped

  • Review which rehearsal questions improved the real session and left room for unexpected answers.
  • Check that the tested scenarios match the prototype people were actually given.
  • Keep a visible distinction between generated hypotheses and findings supported by real participant evidence.

One problem. A useful place to start.

Bring the product decision you are about to test.

We’d take your existing research, one working prototype and the question the team needs to answer. Then we’d build a rehearsal that carries its history forward and helps you make better use of the time you have with real people.

Talk through a research rehearsal Sign up for Korium Start with one research finding