A case for design systems

How design systems enable a tighter focus on what matters

I’d recently stumbled onto a thread on Twitter where one of the tweeters twittered (ok, I’ll stop) that current-day digital designers are no more than glorified digital “scrap bookers”— taking pieces and parts from things already created to slap something together and call it their own. The original arguer was making his case that modern-day digital products (and in turn producers) have become lazy and complacent, and are stifling design innovation. I understand the frustration this individual was feeling, though my experience may be different. I just think the complaint misses a larger point.

Let’s look at the ‘glorified scrap booker’ argument, this idea that most sites or digital products now produced are a smattering of already-set frameworks, APIs, code snippets, and repos that should work together to create something, as opposed to something uniquely created from scratch for a single purpose. I admit that there’s some truth to this. For instance, our agency leverages Boostrap‘s core for many of our projects (among other tools). This in turn gives us access to many UI components and built-in experience mechanisms and default styling that can be adjusted to fit the specific project need. It also allows us to quickly prototype and help make first-pass iterations on projects in a timely, and more affordable fashion.

There are dozens of common frameworks similar to Bootstrap that serve a similar purpose, such as Materialize CSS, Semantic UI, Material UI, UIkit and Foundation. Take your pick. Most offer similar functionality and serve similar purposes. Like any tool, they’re only as effective as the particular implementation.

Our goal with using such tools isn’t to diminish product value by using preset functionality. It’s to reduce effort on the mundane task of building things that can be shared or re-used, and focusing attention instead on the client’s/user’s specific issue or project goals to create something that suits the need.

It may be helpful to think of houses and what makes a house a home.

At a macro-level, when you look at a neighborhood of houses, everything seems the same. Think about when taking off on an airplane, and you look down and see all the rooftops. There’s some amount of truth to this. The majority of houses all have a basic, similar framework. You have a roof, windows that (normally) open and close, a door at the front, and at least four walls holding it all up, with separate rooms within that each serve a purpose. We all use or benefit from the ‘standard’ house and all its out-of-the-box ‘functionality’ and uses. Door frames all share a set of sizes that they might come in. You can expect ceiling heights to fall into a certain range. You could remove the ceiling fan from one house and reinstall it in the next with little or no question of how to make that adjustment. This similarity and sharing of general features and parts is intentional to allow for more efficient, affordable building and maintenance, while still giving the owner choice to make this house their home.

While a basic house framework is shared by all, there’s still the opportunity within these constraints to use those components to make something specifically tailored to the “user”. Looking at a more detailed view of a house, we see that people make it their own, either on their own (thanks Chip and Joanna) or with the aid of an architect/interior designer/contractor. We paint and remodel. Decorate and stage. Some hire builders to come in and take these general concepts of the house structure, and custom tailor that into home exactly to the owner’s requirements.

A great example of someone who took the foundation of a structure and then tailored it to the individual is Franklin Lloyd Wright.

Wright was famous for taking every detail into account for his clients when it came to making his houses into homes, down to the smallest detail. He was known to take into consideration the height of his client when determining the height of things like the windows, counters and even the furniture that he’d have made, so that line of sight, working heights and how a person lived in the home was completely tailored to that person. He worked with his clients to sort out exactly what was needed to make the project successful. Wright’s empathic and independent perspective played such a crucial role in the success of his designs, and is why he’s considered one of most prominent architects of a generation. Wright considered the “end user”, used general, shared frameworks and concepts, and then applied his ability to communicate design decisions tailored to his customer, which ultimately led to his success and timeless designs. Wright’s ability to harness the frameworks that he worked within while understanding his customer helped pave the way for not only his personal success, but also allowed him to innovate and drive architectural design forward.

Charles and Ray Eames, as described by Eames Demetrios in the book The Eames Primer describes our roles as designers well:

 “… the role of the architect, or the designer, is that of a very good, thoughtful host, whose energy goes into trying to anticipate the needs of his guests…We decided that this was an essential ingredient in the design of a building or a useful object.”

Our roles as designers and our relationship with our clients is one that we’re to use our tools and skills in such a way that when we take into account our end products, we’re doing so with an anticipation the end-user, how our products functionality effects its intended use, how scalability and maintainability of the project plays into all of it.

Freeing Ourselves to Focus on Expected Usability

Another benefit to leveraging tools and frameworks is that it allows us to then focus on other important, user-focused ideas like expected usability. Certain things that we do have an expectation of what the outcome should be once it’s completed. If we turn a door knob, we expect a door to open. A water knob that’s labeled with a blue sticker should pour out cold water.

Like a home, digital products have these same considerations that we need to account for. A user understands what a content tab is, and there’s an expectation behind what will happen when a tab is clicked. Buttons are expected to do a certain thing when clicked. We’re even seeing a meshing of experiences between applications and other SaaS products with websites and other traditional digital platforms as users become more ingrained with navigating a digital world. Users are becoming more proficient, but this shift also means that we have larger audiences to account for, and the need for focusing on consistency in user experience and usability in our products is going to only increase.

A Case For Design Systems

Over the past number of years, I’ve noticed a rise in discussion around design systems, and see more and more companies integrating these into their DNA. Google’s Material Design is a good example. Apple has its Human Interface Design standards. Even the U.S. Government has their own design system.

In its simplest definition, a design system is a collection of design rules, constraints and principles that are implemented and managed by design and code.

What a design system is not is just a style guide (though a style guide may be used as part of a design system). It’s also not a pattern library, and not just a front-end framework.

What is a Design System?

In a very basic sense, a design system is the classification of components, along with the process that is built and maintained by the company to help develop a superior user experience, and to strengthen the companiy’s overall brand perception.

A design system takes into account those expected usability considerations in the form of components, cohesive design, as well as tone and voice with how content is presented. When they’re executed well, it helps to eliminate users ‘pulling when they should push’, which in turn increases their overall experience with your product, while also helping to minimize design and development debt. When we integrate tools like were described earlier as well, we’re able to further reduce that design and development debt.

But, I Can’t Afford to Allocate Resources to This…

Although I hope you can see how a design system being implemented is important and that there’s value in proactively looking at how and why you’re designing and developing your digital product, I get it… putting together a thought-out, documented design system takes time, resources and money.

Before you completely shrug off the idea that you could afford having a design system be a part of your project, think about the cost of not at least taking these thoughts into consideration.

Design Systems Reduce Design and Development Debt

When we’re putting together a digital product, one of the questions that’s important to address is the idea of scalability. What are the short- and long-term projections for the product that should be accounted for? Having a design system in place helps to address this concept of design and development debt. As your product grows, more features are added to the original base design, and in turn, other features and design aspects become outdated and need to be replaced. Teams on the client-side contract and expand. Product/project focus may shift. Without some form of a design system in place, the original product can loose its originally intended identity, and might start looking like that scrapbook. It also can quickly become a maintenance nightmare, and you may find yourself in a place where even the simplest of front-end updates end up taking exponentially longer than you’d expect.

With a design system in place, as changes occur, be it to the product or the teams that manage the product, there’s always a baseline to return to for reference on what should be managed, changed and built upon.

We’re Already Getting You Started with Design Systems, Though You Might Not Know It 😉

That might be a surprise, but it’s true! When you work with us on creating a digital product, we’re getting you started on the right track with some form of a design system. As I mentioned before, by using Bootstrap we’re able to leverage UI libraries and components that we can custom-tailor to the product and implementation, and do so in a way that future-proofs the design for scalability, design updates, and enhancements. Our teams of designers and developers work together to write code that is maintainable and semantic, and we’re using tools like Sketch and Zeplin that work together to create style guides, component libraries, and design hierarchies.

While the examples I’ve cited above don’t replace a fully built-out, documented design system, we integrate design-system thinking into our design and development process to allow these concepts to take effect, regardless the project size. It’s a great first-step for our customers to have a design-system approach that helps to minimize that design and development debt that can accumulate over time, and as well it makes use more efficient and proficient designers and developers. It’s really a win-win for us and our clients.

I believe as we venture into this new year, we’re going to continue hearing more about design-system methodology, and my hope is that you see how these processes and concepts are beneficial, and find ways to implement some of these concepts for yourself on your products and projects. As always, if you need a hand getting started, our door is always open.