How 16 Tools Became Too Many Entry Points

1. Hypothesis

The original assumption was that offering a large grid of single-purpose tools would let visitors quickly find exactly what they needed. It assumed visitors already knew which step of the writing or debugging process they were at — and just needed the right utility.

2. What I changed

After accumulating 16 distinct tools, I audited the site architecture. The standalone grid approach was creating a decision problem: every tool had equal visual weight, and none of them explained what job they belonged to. I shifted the primary entry points from a tools grid to problem-oriented workflows. Instead of linking directly to "Brevity Guillotine" or "Tone Switcher", the new /workflows section routes visitors through named jobs like "Improve a draft" or "Ship a tiny tool".

The tool pages themselves remain — they are still the destination once someone is inside a workflow step. What changed is the primary entry point.

3. Example: Before and After Navigation

Before: The homepage featured a grid of 16 tool cards, each with equal visual weight and no context about which job or problem it solved.

The decision: Add a /workflows section and make it the primary homepage entry. Tools are presented sequentially inside each workflow — for example, "Ship a tiny tool" chains Tiny Tool Tarot, Landing Page Lie Detector, Cursed Title Generator, and Screenshot Caption Gobbler into a coherent sequence.

After: A homepage that asks "What are you trying to do?" before offering tools.

4. What I observed

No user tracking was in place before the change, so click distribution across the original grid is not known. These are the design assumptions that drove the decision, not measured outcomes:

• Assumption: A large flat grid of equal-weight entries creates decision fatigue — visitors may reach for the first familiar-looking option rather than the most useful one for their task.
• Assumption: A tool shown inside a workflow step, with a specific instruction and a "look for" prompt, is more likely to be used intentionally than a standalone tool accessed from a directory.
• Observation: No tool page had a note or guide explaining how it connected to others. The tools were useful individually but not obviously useful together.

GA4 tracking on workflow steps and note CTAs is now in place (from 2026-05-27). Whether the workflow-based navigation actually changes usage patterns will be visible after a measurement period.

5. What changed

Five workflow pages were published: Edit a Draft, Check Launch Copy, Debug Developer Text, Structure a Prompt, and Ship a Tiny Tool. Each workflow has a starter input, step-by-step tool sequence, a before/after section, and a limitations block.

Individual tool pages remain available and continue to receive direct traffic from notes, search, and the tools index.

6. Status

changed — workflow navigation published 2026-05-27. Usage data collection started. Review planned for 2026-06-24.

FAQ

What is a workflow on Monkeybase?

A workflow chains tools into a problem-oriented sequence. Instead of picking tools from a directory, you start with a named job — like "Improve a draft" — and follow steps that tell you which tool to use and what to look for at each stage.

Were any tools removed after this audit?

No tools were removed. All 16 remain as individual pages. What changed is the primary entry point: the homepage now leads with workflows rather than a flat tool grid.

How do I find a specific tool if I already know which one I need?

Individual tool pages are accessible from the /tools index. Workflows are the recommended starting point for new tasks; going directly to a tool page is useful when you already know exactly what you need.