The natural instinct when designing a tool for a domain is to design it for domain experts. It feels respectful. It feels rigorous. It's almost always wrong.
I ran into this while sketching a DSL for a creative-composition domain. The obvious user was the domain expert. But experts in that field already have tools they know, workflows they've internalised, and a low tolerance for switching costs. They don't need my tool. What they need is for their existing tools to stop annoying them, which isn't a market I can serve.
The layperson is different. The layperson has no tools, no workflow, and a high tolerance for anything that lets them participate at all.
Designing for the layperson forces the abstractions to be honest. If a non-expert can produce meaningful output using your DSL, an expert can too, because the expert already understands the underlying domain better than any DSL exposes. The reverse isn't true. An expert-facing DSL almost always assumes prior knowledge that a layperson doesn't have, and no amount of documentation closes that gap.
There's a broader pattern here. The most interesting vertical tools of the current era are the ones that let non-lawyers do legal work, non-designers do design work, non-analysts do analysis. Not by pretending expertise doesn't matter, but by exposing the useful primitives of the domain in a form a beginner can operate.
The design rule I've come to:
If your target user needs to already know the domain to use your tool, you've built a productivity aid for people who don't need one.
If a layperson can use it and produce something worthwhile, you've built a market-maker.
Which of these you want to build is a strategic choice. But be honest that they're different products with different users, and the first one is almost always a smaller opportunity than it looks.
Drafted in January 2023
Updated for site in 2026