Solid Design System —
documentation, patterns, launch page

Learning a system I hadn't built. This was my first design system of that size, so I read a lot. The components. How other design systems structure their documentation. And how the bank's older components had actually been applied across its products, which turned out to be the most useful part, because it showed me which inconsistencies were accidents and which were teams working around something the system hadn't covered.

Asking the people using it. I surveyed designers and developers about where the documentation let them down. Not what they thought it should contain in principle, but what had cost them time recently.

A language for the documentation. From that I defined how each component gets written up. What an entry contains, how things are named, where accessibility notes go, how edge cases are handled. The aim was that someone joining in two years could add a component without the whole thing drifting.

A disagreement with the client. Phase two was a pattern library, and the client's first idea was ready-made blocks, a form, a search bar, a navigation, that teams could drop in. I thought that would age badly across so many products. Prescriptive blocks tend to get used where they don't fit or not at all. We went back and forth on it over a couple of sessions.

Finding the patterns. I went looking for where teams had independently built the same thing, then talked to stakeholders to check my reading and to catch the patterns obvious to them and invisible to me. Forms, search, navigation, first-time user flows, data visualisation, some others.

The landing page. With a visual designer, I wrote the narrative for the system's public page. The audience was internal teams who hadn't adopted the system yet, so the job was to make the case for it.