One product can serve different education levels.
Write the first interaction for the least specialized reasonable user. Preserve exact terminology, evidence and deeper controls behind progressive disclosure.
What 001 taught beyond human review.
These are the parts of the build process meant to travel: principles another designer, founder, lawyer, researcher, student, or technologist can apply elsewhere.
Complexity belongs in the system until the user needs it.
A sophisticated implementation is not a reason to expose sophisticated vocabulary or setup. Every extra concept on the surface must earn its place.
Reduce the distance between curiosity and usefulness.
For 001 that meant structured choices, no account, no integration, no essay-length intake, and an immediate diagnosis before the deeper protocol.
Do not build software if a document would do the same job.
Interaction should change the result: personalize, diagnose, compare, simulate, prioritize, map, retrieve, calculate, generate or otherwise do something a static page cannot.
Use the most advanced technology that materially improves the outcome.
The goal is not maximum complexity. It is maximum warranted capability with minimum user burden.
The making can become useful infrastructure too.
Publish the mistakes, revisions and reusable rules after translating internal notes into lessons for others. Do not publish production chatter merely because it exists.
Applying these outside build 001.
These six came out of one build about review authority, but none of them are specific to that subject. The test for whether a principle travels is whether it still constrains you when the domain changes, and each of these was kept because it did: layered comprehension is as load-bearing in a clinical explainer as in a compliance tool, and the software test rules out roughly as many ideas in research tooling as it does in consumer products.
They are also ordered deliberately. The first three govern what the user meets, and they matter most before anything is built, because they change what gets built rather than how it is finished. The last three govern what the maker does with the result, and they tend to be applied too late — a build that reaches the sixth principle without having honoured the fourth usually publishes a great deal of process about something that should have stayed a document.
The most common failure in practice is treating them as a checklist to satisfy at review time. They work better as a set of refusals: do not open with the specialist word, do not make someone configure before they see value, do not ship software where a page would do, and do not publish process that teaches nobody anything. Read that way, they are cheap to apply and awkward to fake, which is the property that made them worth extracting from the build in the first place.