What Feedback Should You Ask for on a Novelez Draft?

You send a playable visual novel draft to three people. One says, “I liked it.” Another rewrites the protagonist for you. The third reports a typo in the opening and says nothing about the ending you spent all week building.

None of those readers failed. They answered the job you gave them, which was probably just “tell me what you think.” That request sounds open and generous, but it makes the reader choose the purpose of the test. One person becomes a fan, one becomes a co-writer, and one becomes a proofreader. You receive three honest reactions that cannot be compared and no clear next edit.

Useful feedback starts before the link is sent. The creator decides what the current draft is ready to prove, gives the reader enough context to play naturally, and asks about the experience rather than requesting a solution. The aim is not to collect the most opinions. It is to reduce one uncertainty in the story.

What decision is this draft supposed to support?

A test needs a decision waiting at the end of it. Perhaps you need to know whether the reader understands why the protagonist enters the abandoned station. Perhaps the question is whether the first choice feels risky before its consequence appears. Perhaps two scenes explain the same relationship change and one can be cut.

Choose one of those before publishing or sharing the draft. If you cannot finish the sentence “After this test, I will decide whether to…,” the build is not yet a test. It is a general showing.

One focus does not mean ignoring everything else. Readers should still report broken paths, unreadable text, or missing images. Those are blocking defects. The focus tells you what to ask after the draft runs correctly.

For a story-heavy game, the most useful early questions usually belong to one of three groups. Comprehension asks what the reader believes happened and why. Attention asks where they leaned in, rushed, or lost the thread. Expectation asks what they think will happen next and what kind of choice they believe the story will let them make. These are different from asking whether the story is good. They expose the model the reader built while playing.

Ask one group at a time. A form with twenty polished questions may look rigorous, but it can turn a ten-minute draft into homework and encourage the reader to invent distinctions they did not feel. Three precise questions about one uncertainty are often worth more.

How do you ask without giving away the answer?

Suppose the scene is meant to reveal that Mina distrusts the station manager. “Did Mina seem suspicious of the manager?” is weak because it plants the intended reading. A reader can agree with your wording even if that idea never formed during play.

Ask for recall first: “What changed between Mina and the manager in this scene?” Then ask for evidence: “Which line, expression, or action made you think that?” Only after the reader answers should you ask about a specific moment you are unsure about.

That order matters. Free recall shows what survived without help. Evidence locates the moment that created the reading. A targeted follow-up lets you inspect an edit without rewriting the reader's memory first.

The same approach works for choices. Instead of “Was the second choice meaningful?”, ask “What did you think each option would change?” and “What were you trying to protect when you chose?” If the reader describes a different tradeoff from the one you designed, that is not automatically a bad result. It tells you what the scene currently communicates.

Avoid asking the reader to solve the design. “How should I fix this scene?” transfers authorship to someone who may not know the later route, the production limit, or the tone you want. Ask where they hesitated, what they expected, and what they understood. The creator can then choose a fix that still belongs to the whole story.

What should the reader know before playing?

Give practical context, not an interpretation. Tell them how long the section takes, where it ends, whether placeholder art or unfinished sound is expected, and what device works best. If a control is unusual, explain it before the session. A reader who spends five minutes guessing how to advance is no longer testing the opening rhythm you care about.

Do not explain who the characters are, what the theme is, or what emotion the ending should produce unless prior knowledge is part of the intended experience. If the published story must communicate that information itself, the test needs the same burden.

When you can observe the session, resist the urge to rescue the story. Note the first pause, the first backward glance, the choice that takes unusually long, and the place where attention leaves the screen. If the reader asks a story question, answer only when the real player would have outside information. Otherwise, write down the question and let the scene answer or fail to answer it.

For an unmoderated test, ask the reader to mark moments in plain language. A scene name, the nearby line, or “just after the café choice” is enough. Do not require them to learn your internal node IDs. The goal is to find the moment again, not to turn the reader into a bug tracker.

How does the current Novelez sharing flow affect the test?

Novelez keeps editing, browser preview, and web publishing close together. You can make a scene change, play it in the browser, and then share the playable version without packaging a separate desktop build. That short distance between an observation and the next revision is useful for small feedback rounds.

There is an important boundary. In the current editor, Share publishes the work to the gallery and issues a public link. It is not a private invitation link. Tutorial projects cannot be shared, and switching a published work back to private removes both the gallery listing and access through the share link.

Treat the share button as publication, even when your audience is only a few testers. Remove material you are not ready to expose, check rights for every asset in the test, and make sure the opening does not contain personal notes or placeholders meant only for you. If the draft needs to stay private, use local preview with someone beside you or wait for a private distribution path instead of assuming the link is hidden.

Before sharing, run the structural pass first. Every intended route should open, every ending should be reachable, and the public link should load on a signed-out device. Feedback about a character turn is hard to trust when one reader unknowingly skipped a scene because the path was broken.

How do you turn several reactions into one edit?

Do not count suggestions. Group observations by moment and by effect.

Imagine three readers react to the same café scene. One says it is slow. One says the protagonist suddenly seems cruel. One suggests cutting the friend character. Those are different proposed diagnoses, but their evidence may point to the same beat: a long exchange repeats information while withholding the protagonist's reason for leaving.

Keep three columns in your notes. First, what the reader did or remembered. Second, where it happened. Third, which design goal it affected. Suggestions can sit in a separate column, because they are ideas, not evidence.

Repeated evidence raises priority, but one report can still matter. A blocked route, inaccessible text, or a scene that accidentally reveals sensitive content does not need three votes. For subjective reactions, look for a pattern across the target readers. If only the mystery fan wants less romance, that may be taste. If every reader cannot explain why the protagonist accepts the invitation, the cause is probably on the page.

Change the smallest element that can test the diagnosis. Move the motivation one beat earlier before rewriting the chapter. Shorten the repeated exchange before deleting the character. Clarify the consequence shown after a choice before adding another branch. Then run the same focused questions again with a fresh reader. A new question every round makes progress impossible to compare.

A compact feedback brief

Before sending the next playable version, write down five lines for yourself and the reader:

• Test goal: the single decision this round will support.
• Play boundary: where to start, where to stop, and expected time.
• Known rough edges: placeholders that should not consume feedback.
• Three questions: recall, evidence, and expectation.
• Response anchor: how the reader can identify the scene or nearby moment.

For example, the goal may be to decide whether the first choice arrives after enough context. Ask what the reader thought the protagonist wanted before the choice, what they expected each option to change, and which earlier moment shaped that expectation. Those answers tell you whether to adjust setup, labels, or consequence. “Did you like the choice?” does not.

Novelez can shorten the path from edit to playable link, but it cannot decide what you are trying to learn or separate taste from evidence for you. That remains an editorial choice. The next time you show a draft, what is the one decision you want the reader's experience to help you make?