Get to Know Your Work

One of the biggest hurdles of creating an extensive design system is keeping track of all the small decisions that make up the full project. Throughout a project so many tiny bits of information are created, delivered, revised, and approved. These small decisions, in the form of design rationale, client feedback, and meeting notes, end up defining the larger project, and are usually collected in various Basecamp threads and emails. At the end of a project they are revisited in some type of formal documentation—as style guides, annotations, and/or a functional spec. But as I’ve worked on larger-scale projects that span a greater number of months, I’ve found the method of waiting til I’m finished designing to write down how things work no longer suits my project needs (and I wonder if it ever did?). Crucial details can be overlooked or forgotten.

As I go, I collect all these small decisions in one long Google Doc, which, for me, is convenient for ease of organization. For example, I paste in client feedback that doesn’t necessarily relate to design but will be important to keep in mind later for development. I write up my design rationale and functionality logic to be sure it all makes sense. A side benefit I’ve found when doing this is that putting these planned design interactions into words helps me rationalize my design decisions and find holes in my logic. I use this as an exercise in getting to know my own work better. Above all, compiling all these smaller parts helps me see patterns and not lose sight of the larger system.

Once that first chunk of my design system is fleshed out, it’s helpful to have a constantly-updating log of wayfinding, navigation, and functionality rules that I can reference at any point in the project. These pieces will typically help form the bones of a more formalized style guide.

Depending on the size of the project, timing for when to begin this log varies. I’ve found it helpful to begin just after approval of an initial design direction. This is a good time to write down my conceptual choices and my expectations for how things will begin to work—core concepts that I can come back to when I get stuck. After a few diverse pages are completed, it may be time to write about my type hierarchy and perhaps limit the number of colors I’m using. This is typically the most useful information to help get front-end development started more swiftly, since these stylistic building blocks are gathered in one place.

But since the log is only an internal draft, there’s enough wiggle room to change things if new styles or revisions are needed. The key is finding the balance between defining styles efficiently and defining them too early. I want flexibility and structure in equal measure, which can become challenging. It’s hard to know when in the design process it’s time to define design system styles in some sort of formalized documentation (for example, a style guide). Set everything in stone too early, and you’ve got a boring and limited design system on your hands—too late, and you’ll be herding cats later on, as you narrow down oodles of typography and link styles.

As it stands, my running notes are only used for internal reference, but in the future, I hope to find a way to turn them into a more collaborative process. Since the full Google Doc is often too much information when shared all at once, I’ve found it best to pull apart this document near the beginning of front-end development. This allows me to surface exact design styles as a style guide draft, but keep more detailed functionality notes as a personal reference tool for writing annotations and answering QA questions. Setting important snippets of information aside as they come in has been helpful to me as an internal tool, saving me hours later down the line when it’s time to confidently communicate design decisions to whomever else will help maintain the system in the future.

Back to Top