Find Your Fix.
A 40,000-member 3D-printing community had a great help wiki that almost nobody read. The fix was never more content. It was delivering the right answer the moment someone asks.
Evidence. A Nielsen heuristic audit flagged two catastrophes. A content analysis of 104 posts found about half were self-serve-solvable, and ~15% were hardware defects mis-routed as user error.
Role. A self-initiated project: research, information architecture, and design. We help moderate the community.
Outcome. “Find Your Fix,” a guided flow that finds the fix before a post is made, and protects the people who answer. Greenlit by the lead moderator for a live trial.
The help already existed. It just never reached people when they needed it. And answering the same question every day was wearing out the volunteers. Find Your Fix closes both gaps at once.
The same questions, over and over.
The community is one of the largest for a consumer 3D-printer brand. Most members are first-time owners, and they land in the #help forum stuck on the same handful of problems.
A content analysis of 104 posts made the pattern clear. About half had a known fix, and the same issues kept coming back: software and slicing, filament that will not feed, prints that will not stick.
The answers already exist. The manufacturer publishes a good wiki, and a bot auto-links it on every post. But the wiki lives off Discord. There is no quick, standard way to step through it and find what is actually wrong. So people skip it, post “help!”, and wait.
The community: a 40,000-member 3D-printing forum, mostly beginners.There is a second problem, and we see it from the inside. We moderate the community and answer the forum, so we know the volunteers are burning out. The advice gets ignored (the classic “wash your plate”). The same questions come back the next day. Some people treat free help like paid support. Good helpers go quiet, and they are the only safety net there is.
More content was never the answer. A helper had even built a supplementary site on top of the wiki, and the repeats did not stop. The lever is not publishing more. It is getting people to the answer that already exists, the moment they are about to post.
Two catastrophes, and everything downstream.
We ran a Nielsen heuristic audit of the whole help experience and scored each heuristic for severity. Two scored as catastrophes.
Fig. 1. The full Nielsen pass. The two catastrophes, H4 (no standard for asking) and H5 (nothing preventive), drive almost every other failure. Fix those two and most of the rest go with them.
The core insight. The bot only ever reacted after a post, with a generic link. Nothing happened before, when a duplicate or a low-context “help!” could still be prevented. The lever is structured intake, not more content.
Half the questions were already solvable.
To design the fix, we needed to know what people actually ask. So we coded 104 help posts by what the system should do with each one.
The topic was not the useful cut. What mattered was a different question: what should the system actually do with each post? Coded that way, the 104 posts fell into three buckets.
Guide to the known fix
Clogs, bed adhesion, AMS loading, nozzle cleaning, slicing settings, error-code lookups. A known answer already exists.
Structure it, then hand off
“Does anyone recognize this?” cases that genuinely need a photo and a person, but should arrive with the context already gathered.
Stop, and route to support
A dead heating module, force-sensor errors, screen corruption. Troubleshooting a defective unit just wastes a frustrated person's time.
That third bucket is the important one. Knowing when the system should stop helping and escalate is the real judgment call. An assistant that tries to troubleshoot a defect is worse than no assistant at all.
“About to give up… I just don't understand what I'm doing wrong.”A beginner in the help forum (45 replies)
That is who the flow is for: the three-weeks-in beginner who cannot tell a setting from a clog from a defect, and is one bad night from quitting.
Find Your Fix, in three parts.
Find Your Fix has three parts. A flow people click through before they post. A tool that lets moderators keep that flow current. And a standard for how to ask when a post is still needed.
A click-through flow, inside Discord
Before posting, a member picks their problem and clicks through a short flowchart. It walks them through the quick, standard fixes that usually work, like “wash the plate” for bed adhesion. Every path ends in one of three places: the fix, a route to official support if it looks like a defect, or a pre-filled post if they are still stuck. Most never need to post.
A bot moderators run from the web
A simple bot renders the flow inside Discord. Moderators edit and publish the whole flowchart in bulk from a web dashboard, so the content stays current without anyone touching code.
A standard way to ask
When a post is still needed, a required format makes sure it includes the printer model, the symptom, and what was already tried. The people answering start from a clear report, not “plz help.” That saves their time, and their patience.
·Every path ends in one of three exits
The bed-adhesion tree at the top is the pattern in miniature. The standard fix, wash the plate, is the advice helpers give constantly and beginners ignore, so it becomes step one of a flow they click through, not a line they skim past. And whichever branch they take, every tree ends the same way.
·Every part traces to a finding
- H4, no standard for asking → the required format standardizes the ask.
- H5, nothing preventive → the flow deflects duplicates and catches defects before a post happens.
- H2, jargon → plain-language problem names, not vocabulary a beginner lacks.
- H9, no diagnosis → the flow is guided diagnosis, including the route to official support.
- H10, delivery → the specific answer at the point of need, never a generic link.
And it all lives where the question gets asked, inside Discord. The wiki failed because it was a link. A separate site would be another link. The answer belongs in the room. The flow covers the top three or four problems, which account for most of the volume, not an unmaintainable everything-tree.
Greenlit for a live trial.
We brought the proposal, the full flow, and the ask standard to the moderation team. The lead moderator greenlit it for a real trial.
That is what matters most. This is not a hypothetical redesign. It is a researched, designed system that a 40,000-member community agreed to put in front of real users. The trial starts with one tree, bed adhesion, in a staging space, with a before-and-after baseline so the deflection can be measured.
The real goal: keep the helpers helping. The volunteers are the community's only safety net, and they are not paid. Every duplicate the flow deflects, and every clean report the standard produces, is volunteer time and patience handed back. Protect the helpers, and the help survives.
Findability beats more content. Every time.
- The lever is delivery, not volume. More content had already been tried here, a supplementary site on top of the wiki, and it did not stop the repeats.
- A help system has two users. The people answering need protecting as much as the people asking.
- Knowing when to stop is a design decision. Routing the ~15% defects away from troubleshooting was the highest-leverage call.
- Meet people where they already are. Native in Discord beat any separate site, because the separate site was the problem.