Most rejected submissions are not lazy. They come from people who genuinely did the task and then described it in a way that carries no information. The gap between an accepted submission and a rejected one is usually a matter of habit, and habits are learnable.
Say what happened, not how you felt about it
"The signup was confusing" is a feeling. It cannot be acted on, because six different problems produce that same sentence.
"The signup asked for a company name before it told me the product was for teams, so I thought I was on the wrong page" is an observation. It identifies the moment, the cause and the consequence. A designer can fix it on Monday.
The reliable trick: whenever you are about to write an adjective, write the moment that produced it instead.
Keep the order intact
Researchers reconstruct your experience from your description. If you summarise, you remove the sequence, and the sequence is where the problem usually hides. Try to narrate: I did this, then this happened, so I did that.
Dead ends are especially valuable. The route you tried that turned out to be wrong tells the team what your mental model was — and mental models are what they are really testing. People often delete these from their write-up because they feel like mistakes. They are the most useful thing in the submission.
Be specific about where you were
"A button did not work" is nearly unusable. Which screen, which button, what did you expect it to do, what did it do instead, and could you make it happen again? If a developer cannot reproduce it, they cannot fix it, and a bug report that cannot be reproduced gets closed.
Device details matter for the same reason. The same layout can be fine on one phone and broken on another, and the team has no idea which one you were holding unless you say.
Answer the question that was asked
Studies have a focus. If the study is about whether a pricing page is clear, a long paragraph about the logo is off-target — even if you are right about the logo. Say the logo thing briefly at the end if there is a free-text field, then spend your effort on what was asked.
Do not be polite at the cost of being accurate
A surprising number of people soften their feedback because it feels rude. Nobody is hurt by "I could not find the export button and gave up after two minutes". That is the whole reason the study exists. Softening it into "export could maybe be slightly easier to find" costs the team the finding and costs you the acceptance.
The reverse also holds: if something worked well, say so, and say why. Teams need to know which parts not to touch as much as which parts to fix.
Match the effort to the task
A fifteen-minute study asking for a walkthrough expects several sentences per question. A three-minute survey does not. Padding a short survey with essays is not rewarded, and answering a walkthrough in four words is the single most common reason for rejection. The estimated time is a reasonable guide to how much detail is expected.
Write it yourself
Text pasted from app store reviews, copied from another member, or generated by a language model without doing the task gets caught, and it gets caught more easily than people assume. Generated text describes a plausible generic experience rather than your actual one — no specific screen names, no dead ends, no device quirks, and a tone that is oddly even throughout. Reviewers see hundreds of submissions a week and the pattern is obvious.
It is also the fastest way to lose an account, which is a poor trade for saving ten minutes.
A worked example
Rejected: "App was okay but a bit confusing in places. The design is nice. I would use it."
Accepted: "Installed on an iPhone 13. The welcome screen said 'Start tracking' with no explanation of what would be tracked, so I hesitated before tapping it. After tapping, it asked for location access — at that point I understood, but I would have preferred knowing before granting permission. Setting up the first goal took under a minute and was clear. I could not find how to delete a goal; I looked in the goal detail screen and in Settings, then found it by swiping the row, which I only tried by accident."
Same task, same twenty minutes. The second one gets paid, and it gets a product changed.
Written by the Nemodits team. Questions about anything here go to support@nemodits.net.