Find Your Fix.

Two catastrophes, and everything downstream.

I ran a Nielsen heuristic audit of the whole help experience and scored each heuristic for severity. Two scored as catastrophes.

Fig. 2. 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.

Half the questions were already solvable.

To design the fix, I needed to know what people actually ask. So I coded 104 help posts by what the system should do with each one.

Two of those numbers are the cost, in plain sight. Four in ten askers never get a working answer at all, which is what quitting quietly looks like. And roughly one in five posts arrives without even a printer model, so the first reply is a helper asking for basics instead of helping.

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.

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.

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.

·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.

·One system, four pieces

Under the hood the system stays deliberately small. Moderators work in a web dashboard where the whole tree is drafted, reviewed, and gated. A bot does nothing but publish the reviewed result into Discord as read-only forum posts, first to a staging server, then to the live one. Members only ever touch ordinary posts, and nothing they do flows back: the bot reads no member messages and stores no member data.

One layout for editing, another for publishing.

The bot renders the flow, but moderators keep it current from a web dashboard. That tool had a design problem of its own: two very different actions living on one screen. It went from gray boxes to mid-fi to a deployed product, and the layout decision survived every step.

Editing a post happens constantly and is easy to undo. Publishing to a 40,000-member community happens rarely and is hard to take back. Those are not the same job, so I did not give them the same layout. Six gray-box wireframes each tested one question about where editing should live and what should happen the moment something goes live.

Then the two survivors moved to the jobs they suited. Editing kept the simple two-panel split, and the blocking modal became the publish confirm screen. Everything else, including the compare view, was cut.

·Validated in mid-fidelity

Wired to a live bot and real Discord data, the low-fi decisions held.

·Shipped: the working dashboard

The mid-fi screens then became the real product. What follows is not a mock. It is the deployed dashboard, running against the live bot, in the same layouts the gray boxes argued for.

One capability matters most for maintenance: the whole tree is a file. The complete 118-post flow loads from a single JSON upload, publishes to Discord in one action, and re-publishing updates the existing posts in place instead of duplicating them. The same file downloads back out, so the tree can be versioned, reviewed, batch-edited, or moved between servers. That is what let the full data-driven tree be authored offline from the 104-post analysis and go live in one click, and it is what makes handing the tool to moderators realistic: no one maintains 118 forum posts by hand.

The file format is also how the tool stays AI-friendly without running any AI itself: the dashboard hands the moderator a self-contained prompt to paste into whatever assistant they already use. One prompt interviews them and drafts a new tree; a second embeds the current tree and returns a batch of edits, with hard rules baked in, the strictest being that the AI may only cite documentation links the moderator gives it, never invented ones. The bot stays a dumb publisher of reviewed content, which is exactly what keeps the privacy promise simple.

Then the canvas learned to build the tree.

The shipped editor could show the tree and change one post at a time, but growing it, adding a branch, still meant filling out a form. The last pass on the dashboard made the structure something a moderator edits by touching it: drag a card to arrange it, pull its edge to branch, drop it on another card to connect.

·One card, one honest handle

The first version gave every card a single handle on its edge, a tail, to pull a new branch from. It shipped, and then it failed on the thing the whole tool is about: once a card had four or five branches, the tail could not say which wire belonged to which branch. So the second version moved the branches onto the card. Each outgoing link is its own chip with its own port on the edge, and each wire leaves from the chip it belongs to, so the tree is readable in both directions: what a card asks, and where each answer goes.

·Connecting is the safe move

Adding a step and connecting two posts are the same gesture: pull from a card’s edge. Drop on empty canvas and a new post appears where you left it, ready to name. Drop on another card and the two link. What matters is what the drag refuses to do. It lights a target green and offers “Link here” only when the link is valid, and warns in amber on a self-link or a duplicate, so a bad connection is caught in the gesture, before it exists.

The same rule shapes how a post is born. A new post starts as a draft that reaches no one until it is published, and the form makes you choose what it branches from before it can exist, so a post can never be created as an orphan members cannot reach.