Document it Now, Thank Yourself Later
“I’m not writing it down to remember it later, I’m writing it down to remember it now.” Easily one of my favorite product taglines, it comes from Field Notes, a popular pocket memo book, and is printed in every notebook they make. It’s a pleasant reminder to take a little extra time to document what you are doing. Taking this time to reflect helps reinforce and edit our ideas so they make more sense to others and to ourselves.
The concept of review and iteration is incredibly important in design. It is this step where we begin to consciously shape our work away from certain preconceived ideas and toward what we determine are better solutions. One of the best ways we can review and share ideas about a product is by documenting what we call a design system.
A design system is a way of laying out all the pieces of a product in one place. This acts as a library of the elements for your team or stakeholders to review and see if you are making a consistent design solution. The system should be as expansive as your product, but should not be repetitive. In fact, one of the main goals is to break down designed pages to a reusable grouping of elements.
Building a design system helps anyone involved in using, creating, or maintaining a product, namely, the user, the client and the team.
When you document a design system you are helping build consistency and avoiding confusing or redundant components. By laying out the components of your product you are actively reviewing them and making sure they work like other components in your system. These reviews will help users in wayfinding and understanding the controls of your product. When a user understands a product they are more likely to keep using it and refer it to others.
Good design systems are recognizable and create consistent interface signifiers, helping users accomplish their goals. These signifiers build up a confidence in the product and make the user feel clever. When you build a confidence-inspiring system you relieve pressure on the user to decipher how your product works and empower them to more easily accomplish their task. Jeffery Zeldman has a great thought on this, “Don’t design to prove you’re clever. Design to make the user think she is.” This should be the goal of anyone working on software – to make the user feel confident and proud of what they can do using the software you helped create.
The items we build are never direct lines from idea to implementation. Iteration is a vital part of producing great work. These are things that your internal team will know and understand but the stakeholder you are presenting to will not. It’s likely they weren’t there along the entire path when specific choices were made that ultimately affected the user interface. Having a design system and documentation of choices and rational to show your stakeholder helps them better understand why you made the decisions you made and helps to gain their approval. Not only does the documentation help build confidence in the stakeholder while you are making the product, but it is even more important after the work is done.
When a current phase of a project is completed, the team may not end up working on that section of the product for a while, or someone else might work on it later down the road. In either case, leaving detailed visual and code artifacts are important for the client to have so they know what components are already built and how they can further expand their product. When possible, make sure to retain any additional documentation to help future product builders know what reasoning was behind the system you helped create.
Breaking down screen mockups into individual components greatly helps both developers on your project and other designers. Contemporary development practices ask that a reusable block of code be created instead of rewriting the same component repeatedly—this is often referred to as keeping your code “dry”. Code reuse helps reduce the number of bugs in an application and simplifies any future changes that the components might need.
Unless you are the only one working on a project, there will be communication amongst team members. Having a single library for components reduces accidental duplication of work. Larger teams may be unaware of differentiation of UI made and could create a split in the types of controls produced. A single component library lets your team easily see what work is completed and allows the team to more easily implement it in new places.
If you’re not sure where to start with a design system, you may want to start with some methodologies that are already defined, such as Atomic Design. Atomic is a design methodology where you move from the smallest individual components to larger units until you have a full page completed. Start by learning about components and funnels, moving into development CSS styling methodologies and naming conventions like SMACSS (Scalable and Modular Architecture for CSS) or BEM (Block, Element, Modifier).
The only way these design artifacts and documentation are helpful is if they’re maintained over iterations. This always seems to be the point where the system breaks down - when there are changes that haven’t been updated in the documentation. It is important (albeit challenging) to take away as many hurdles from this process. If you have been working in a design-centric tool (Sketch, Illustrator, Photoshop) make sure you’re using symbols or linking to different artboard files. This way you only need to update the documentation once, letting the changes update across your documents.
The key to having a successful design system is to have a strategy that can stick with the product as it grows. As a rule of thumb, you want to build a maintainable, scalable and easily transferable system, making decisions as a team on what works best for the project. Always remember that above all else, the best type of documentation is the one that gets used. Find a system that makes a better product for you, stakeholders, and most importantly the user.