The system was built by one designer for a small team with shifting priorities. That meant making conscious decisions about where to invest time and where to leave things good enough.

I documented the components that needed it most. Ones with multiple variants, non-obvious rules, or behaviors that differed across platforms got short descriptions and usage guidelines. But I didn't reach that level of detail for every component. The simpler, more self-explanatory ones shipped without written guidance and relied on clear naming and consistent structure to communicate intent.

The same pragmatism applied to the library itself. Some components lived inline in specific feature files and never graduated to the shared library. I had a clear rule: if a pattern appeared across multiple features or surfaces, it earned a place in the system. If it didn't, it stayed local. That kept the library honest. But I wish I'd organized those inline components more consistently. When a project ended, the local pieces sometimes stayed scattered across files rather than being cleaned up or promoted.

We also made a mutual decision with engineering not to invest in a full documentation layer at that stage. At our team size and pace, the system could be understood from the file itself. Naming and structure were shaped with engineering input specifically so the system wouldn't need a manual to use. That was the right call for where we were, but it was a tradeoff, not an ideal.

If I were building this again, I'd set a minimum from the start: one line per component explaining when to use it and when not to. I'd also build a simple index of inline components per project so nothing gets lost between files. The system worked well because we were small and in constant communication. For a larger team or a handoff to another designer, those gaps would matter.