Problem
Growth often adds navigation before it adds clarity. New pages, packages, and experiments accumulate until the public interface begins to describe internal history instead of useful choices.
Summary
Keep the public interface small by grouping work around the question a visitor has. Projects are things to use. Engineering is how decisions were made. Open source is what can be inspected. Labs are what is still being tested.
Implementation
Every new section needs an explicit contract: who it is for, what it contains, and what it must never contain. That contract is more useful than a long navigation list.
A concrete homepage decision
Birdor.dev has four technical collections: Projects, Engineering, Open Source and Labs. The current homepage puts an actual engineering article and recent records before the complete collection map. A first-time visitor can begin reading without first learning every section name.
The navigation remains available in the header. On the page, the route sequence is hero → notes → project → map → public source and Labs. Each section has a distinct job: offer a first read, expose recent work, show a project, explain the directory, then provide source and research entry points.
This was a change in information order, not evidence that readers prefer one visual style. The earlier implementation record includes desktop/mobile and static checks. It contains no controlled reader study, so we cannot attribute higher engagement or conversion to the change.
Assign each destination one question
| Destination | Primary question | Useful next action |
|---|---|---|
| Project | Can this help my work? | Run a guide or inspect documentation |
| Engineering | Why was this decision made? | Read its evidence and trade-offs |
| Open Source | Where is the implementation? | Open the owning repository |
| Labs | What was tested and what remains uncertain? | Reproduce the experiment |
A project can link to an experiment without duplicating its full report. An article can link to a repository without becoming a second issue tracker. The relationship should carry readers toward evidence instead of giving every page the same collection of controls.
For example, the [PlumeGo project](/projects/plumego) now connects a [first service](/engineering/plumego-first-service), an [architecture explanation](/engineering/plumego-architecture), and a [reference-services review](/engineering/plumego-reference-services-review). Those are successive questions, not three interchangeable cards.
Keep optional controls discoverable
The Engineering filter panel can be opened when the reader needs to narrow results; the article list remains available without that interaction. Saved reading records stay in the current browser. RSS provides a separate way to follow published content. None of these requires a visitor account to read an article.
Every extra control adds states that need explanations: empty results, failed storage, unavailable data and keyboard focus. Before adding another control, name the reader decision it improves and the failure path it introduces. If it merely repeats an existing link, improving that link's context is usually smaller work.
Review the interface as content grows
For each addition, check that it has one owning collection, a stable URL, a meaningful inbound link, and an explicit next step. Verify the same route with and without JavaScript. On narrow screens, preserve the order in which those questions are answered; do not let a large control panel displace the first useful record.
The remaining unknown is how real readers use these paths. A future reader study could ask participants to find a suitable project, reproduce a first example and locate its limitations. Until that study exists, report navigation and accessibility checks as checks, not as user-success measurements.
Conclusion
A small interface is not less ambitious. It is easier to learn, easier to maintain, and more honest about where work is ready to be used.