Raise Idea Quality with Submitter Microcopy, Conditional Prompts and Progressive Disclosure

Most idea programs treat form copy as an afterthought. Somebody writes "Describe your idea" in a text box, adds a placeholder that says "Enter your idea here," and moves on. Then three months later the innovation team is drowning in submissions that read like "we should improve communication" and "make the app faster," and everyone blames employee laziness.

It's almost never laziness. The submitter looked at a blank box, got no signal about what "good" looks like, and typed the smallest thing that would let them hit submit. The words you put next to that box — the microcopy — are doing more work than your entire recognition program. This post is a copy-paste library for that microcopy, plus the conditional-prompt logic and progressive-disclosure rules that actually raise articulation quality, with before/after examples and the metrics worth watching.

This isn't about form fields — that's a different problem covered well in Stop Low-Quality Submissions: Intake Form Fields, Conditional Logic and Triage Signals. This is specifically about the language inside those fields, and when to reveal more of it.

Why generic microcopy produces generic ideas

There's a pattern across almost every underperforming intake form: the copy asks for the thing (the idea) but never asks for the shape of the thing — the problem behind it, who it affects, what evidence exists. A submitter reads "Describe your idea" and interprets it as "give me your solution in one line." So they do. You get solutions with no problem attached, which are nearly impossible to evaluate or reuse.

The other quiet failure is tone. Copy that reads like a compliance form ("All fields required. Submissions reviewed within 30 business days.") signals bureaucracy, and people write to bureaucracy — vague, defensive, minimal. Copy that reads like a curious colleague pulls fuller answers out of the same person.

A useful way to think about it: every field label is a question, and people answer the question you actually asked. "Describe your idea" gets you a description of an idea. "What's frustrating enough about your current workflow that you'd change it?" gets you a problem statement you can act on.

The field-level microcopy library

Below is phrasing teams can lift directly. The left column is the tired default; the right is a version that pulls more signal without adding cognitive load. Most fixes reframe the question rather than bolt on extra instructions.

Two things matter about the "rough guess is fine" language in the impact field. First, it removes the paralysis that makes people skip it entirely. Second, it signals you're not going to hold them to a fabricated ROI number — which is what causes people to either lie or leave it blank.

The evidence field is the sleeper. Adding "a number, a screenshot, a story" as concrete examples roughly doubles the rate at which people attach something. Left to "supporting info," most people assume they need a formal business case and attach nothing.

Conditional-prompt recipes: ask the right follow-up, not every follow-up

The mistake teams make when they realize microcopy works is bolting on ten fields for everyone. Now your quick-win submitter has to answer a market-sizing question, and they bounce. Conditional prompts fix this — you only surface the deeper question when the earlier answer justifies it.

1. 1
   If effort = "big lift" → reveal

   "Big changes need a champion. Who besides you would need to be on board?" This surfaces the political reality early and filters fantasy ideas from real ones.

2. 2
   If impact mentions revenue or cost savings → reveal

   "Roughly how are you getting to that number? Even a back-of-napkin guess helps." This turns unqualified "this'll save us thousands" into something an evaluator can pressure-test.

3. 3
   If the same problem keyword matches an existing submission → reveal inline: "Someone raised something similar — want to add to theirs instead?" Deduplication at the source, before a moderator has to deal with it downstream.
4. 4
   If problem field is under ~15 words → gentle nudge

   "Can you add one detail about when this happens? It helps the reviewer picture it." Not a hard block — just a nudge.

5. 5
   If category = "process/workflow" → reveal

   "Roughly how many people run into this, and how often?" Frequency is the single most useful triage signal for workflow ideas and almost nobody volunteers it unprompted.

The rule of thumb: a conditional prompt should only appear when the answer changes what happens to the idea. If the follow-up is nice-to-have curiosity, cut it. Every extra field shown unconditionally is a tax on your completion rate.

When conditional logic backfires

Conditional prompts get annoying fast when they fire on trivial triggers or stack more than two deep. If someone answers one question and three new boxes cascade open, it feels like an interrogation. Cap it. One trigger, one follow-up, maybe a second. Beyond that, route it to a conversation instead of a form.

Progressive disclosure: show the minimum, earn the rest

Progressive disclosure is the discipline of not showing the whole form at once. The submitter sees a small, unthreatening entry point, and the form expands only as they commit.

A workflow that consistently works:

1. 1
   Stage one (visible immediately)

   Title + problem. Two fields. Anyone can do this in under a minute.

2. 2
   Stage two (appears after they type the problem)

   Proposed change + rough impact. Now they're invested, so a couple more fields feel reasonable.

3. 3
   Stage three (appears on "review before submit")

   Evidence, effort, and the "want to help test this?" question — framed as optional polish, not requirements.

This works for a behavioral reason, not a technical one. People who've written two sentences about a real problem have crossed a commitment threshold. Asking for more after that point gets far higher completion than asking for everything upfront. The same person who'd abandon a ten-field form will happily fill nine of those fields if you reveal them three at a time.

One thing worth internalizing: progressive disclosure isn't about hiding work from people. It's about making sure the people who bounce are only ever seeing the cheap fields, so a bounce costs you nothing — while the people who stay give you the full picture.

Flow illustrated above.

Before / after: what this actually looks like

Here's a concrete transformation from a single field.

Before

1. 1
   Label

   Describe your idea

2. 2
   Placeholder

   Enter your idea

3. 3
   Typical response

   "We should have better onboarding."

After

1. 1
   Label

   What's the problem or annoyance behind this? Who feels it?

2. 2
   Placeholder

   e.g., New hires spend their first week hunting for docs across five tools — support tickets from week-one staff are our #1 category.

3. 3
   Conditional nudge if under 15 words

   Add one detail about when this happens.

4. 4
   Typical response

   "New hires can't find setup docs — they're scattered across Slack, Notion, and email. Every new engineer files 3–4 'where is X' questions in week one."

Same person, same idea, radically different usefulness. The second version is triageable, dedup-able, and reusable. The first is noise.

A quick real scenario

A mid-market software company with around 400 employees ran an internal idea portal averaging roughly 60 submissions a month. The problem wasn't volume — moderators were rejecting or sending back close to 45% of submissions as "too vague to evaluate," which created a slow, grinding back-and-forth and pushed response times way out.

They didn't add fields. They rewrote the four core labels using the reframed-question approach above, added the "rough guess is fine" language to impact, dropped in two conditional prompts (the big-lift champion question and the sub-15-word nudge), and split the form into three progressive stages.

Over the following two months, the send-back rate fell to somewhere around 18–20%. Submission volume dipped slightly at first — maybe 5–8% — because a handful of low-effort submitters bounced at stage one, which was fine. The ideas that came through arrived with a problem statement attached most of the time, and moderator time spent chasing clarification dropped noticeably. The optional evidence field, previously near-zero, climbed to roughly a third once it was framed as polish rather than a requirement.

Nothing exotic. They just stopped asking bad questions.

The QA metrics worth tracking

Microcopy changes are easy to A/B test because you can swap labels without touching your backend. Run two versions to alternating submitters for a few weeks and watch these:

1. 1
   Send-back / clarification-request rate — the clearest quality signal. If moderators ask for clarification less, your copy is working.
2. 2
   Problem-statement presence — sample submissions and mark yes/no on whether there's an actual problem stated. This should climb.
3. 3
   Field completion rate per field — watch where people abandon. A field that tanks completion is usually a copy problem, not a user problem.
4. 4
   Median problem-field length — crude but useful. Longer usually correlates with more evaluable, though don't chase length for its own sake.
5. 5
   Downstream progression rate — what share of submissions make it past first triage. Better articulation should lift this.
6. 6
   Time-to-first-decision — clearer submissions get decided faster.

“

Segment results by submitter type — power users and first-timers behave differently.

A note on A/B testing: run it long enough to clear novelty effects, and segment by submitter type if you can. Power users react differently to copy changes than first-time submitters, and averaging them together hides the real story.

When this is worth doing — and when it isn't

Worth it when: you have a steady stream of submissions but your moderators spend real time chasing clarification, or when a big share of ideas die at triage for "not enough info." Copy fixes are the cheapest lever you have here. No engineering, no new tooling — just better questions.

Not worth obsessing over when: your volume is tiny — a handful of ideas a month. At that scale, a moderator can just have a conversation. Fix your microcopy once using the library above and move on.

Skip the heavy conditional logic if your submitters are all in one function and already share vocabulary. Conditional prompts earn their keep when submitters are diverse and you can't predict what kind of idea is coming. A homogeneous team often does fine with a clean, static three-field form.

Where the downstream work still lives

Better microcopy raises the floor on submission quality, but it doesn't eliminate triage. You'll still need people making judgment calls on the higher-quality inputs, and that side of the operation has its own rhythm — covered in the Moderator & Curator Playbook for High-Volume Idea Streams.

Think of microcopy as the thing that makes the moderator's job possible, not the thing that replaces it.

The core idea to hold onto: submitters aren't withholding good ideas. They're answering the questions you put in front of them, exactly as narrowly as you asked. Change the questions — the labels, the follow-ups, the order they appear in — and the same people hand you dramatically better raw material. It's the highest-leverage, lowest-cost improvement most idea programs never bother to make.