In the past, I’ve written a lot about Modular Design as it applies to CSS via SMACSS, OOCSS, and BEM (or, collectively, Modular CSS). Although I don’t work much in the front-end these days (and it seems like everyone has moved on to building everything with React), I still love these methodologies and continue to believe strongly in their value for what they teach us about design.

It has changed the way I work so much that I use BEM naming conventions in my InDesign character and paragraph styles. In Sketch, when creating Symbols, I continue to think in terms of base objects and extensions (or classes and sub-classes) just like OOCSS and SMACSS taught me. And although I haven’t tweeted about it much on Twitter, I’m a fan of the ideas discussed in Brad Frost’s Atomic Design, Alla Kholmatova’s Language of Modular Design, and Sophia Voychehovski’s Object-Oriented UX. What we’re really talking about here is designing systems.

Thinking in terms of systems design is something that I believe a UXer needs to be capable of. That ability to zoom out and consider the system as a whole and how it coincides with the overall experience together with the ability to zoom in and understand the importance of details. When applying modular design to this level of thinking, we begin asking ourselves questions about standards and patterns and, when appropriate, why we are breaking them.

Seeing the patterns from the most basic of modules and holding them to specific standards allows us to create consistency within the system. This consistency translates into usability gains for our users because we aren’t constantly making the relearn interfaces and interactions. It also translates into workflow efficiencies as we are no longer constantly reinventing the wheel, but instead building off of existing objects, mindfully augmenting them only when necessary.

In turn, the modules that we create can be compared to one another to look for deviations, question their reason for being, and adjust as needed. This prevents us from muddling the interface with modules that look similar but behave differently as well as increase contrast where the differences aren’t sufficiently clear.

Just like in Modular CSS, modules should be designed for reuse and extension. This adds scalability to our projects that one-off design cannot offer. Once the modular system hits a point of maturation, we can extend applications with new features without the fear of a break in design because, more often than not, the majority of the modules we need will already be accounted for. And if something new has to be created, we think a little harder about why we’re introducing a new pattern, vetting it first to make sure it doesn’t already exist in some form within the system.

But the main reason that I’m writing this is because I’m amazed to see that the skills I acquired from writing scalable and modular CSS are still applicable to design even when I’m no longer writing code. In a follow-up letter, I’ll write a little more about how the specific principles that I learned from SMACSS, OOCSS, and BEM can be still be applied to interface design outside of CSS.