Tidy up!
By constantly optimizing and simplifying our designs and implementations, we prune away redundancies and imperfections.
Last updated
Was this helpful?
By constantly optimizing and simplifying our designs and implementations, we prune away redundancies and imperfections.
Last updated
Was this helpful?
Lean Design System encourages an approach of letting structures, workflows, and components evolve through project work and design explorations instead of having a long upfront (Waterfall-like) planning phase. If left entirely unchecked, such a natural flow may lead to clutter, unwanted variance, and other deficiencies we better avoid if we are to develop an effective and efficient design system.
In software development, the term refactoring describes the improvement of existing code without changing its (external) behavior. This can refer to better aligning code with agreed-upon conventions, eliminating redundancies, or the act of simplification. When cultivating a dynamic design system (and especially when following Lean Design System methodology) everyone involved should make a habit of refactoring any deficient artifact they come in contact with. What this means is, after completing a task, we should always try to clean up a couple issues we noticed—a good rule-of-thumb is aiming to fix slightly more issues than we caused. When we add a new component to a library (whether in our , in our repository, or our ) we make it a part of our routine to repair the world around it. Even just a little regular pruning can prevent our system from cluttering up. As long as we all commit to it and stay diligent, our system will steadily evolve towards its optimal design—one refactoring at a time. Collective ownership of design system components, as outlined in and enabled by , helps us to adopt this habit, as it allows us to work on any component without having to wait for somebody else. If we notice an imperfection, we can eradicate it right away. Improving a design system component can mean many things, including:
More clearly defining its role and dependencies within the system
Simplifying its design and definitions without sacrificing functionality
Improving its consistency (i.e., eliminating unwanted variance)
Improving its usability and visual design
Eliminating any redundancies (in the code, but also in our )
Improving written documentation (see: )
Eliminating discrepancies between repositories (see: )
Besides regular clean-ups, we should also consider setting aside a few hours a week to implement a planned beach cleaning session. During such a beach cleaning, we only refactor and optimize existing components. We can either agree on specific areas per session or choose individually. This might be a tough sacrifice (time-wise), especially for smaller teams— but it will almost certainly be worth it in the long run. We should view it as a steady deposit, allowing us to constantly pay down design and technical debt, which would otherwise accumulate and clog up our machine.
Adopting collective ownership as outlined in Win Friends, not Battles will help us properly and quickly refactor the individual components of our design system.
D. Kurfess