Design systems and trade-offs

Effective Product Design is a cascading series of trade-offs. There is no right, no wrong, there’s only trade-offs. – Tim Meaney, VP of Software at SageSure

At SageSure, our software is not the product we offer our customers. It’s a means to an end, a tool our customers use to gain access to our core product: insurance built on continuous capacity and long-term financial stability.

That is what we aim to deliver our customers. It just so happens that software makes that happen.

The faster we can build quality, effective software, the faster we can deliver to our customers.

One trade-off: useful software over creative expression

Over the last few years the software team at SageSure had developed several threads of systematic design—style guides, pattern libraries, and components—which have together constituted the building blocks of our varied digital products.

These threads of systematic design were loosely defined and controlled, in turn granting broad freedom and creative interpretation to individual team members. And while the discrete threads were consistent in themselves, the assembled whole often was not.

But given the nature of our organization—its size, structure, and resources—the trade-off of consistency around narrow sets of patterns at the expense of the whole, and individual creativity at the expense of cohesion and team velocity, worked.

Until it didn’t.

We had freedom and a sense of creativity in assembling the building blocks, but our teams felt an ever-growing desire to relinquish that kind of freedom in exchange for increased clarity and velocity. We wanted to ship more useful, quality software to our customers over being more individually expressive.

This was one of the key trade-offs we documented in assessing our needs to build a design system.

Resources are finite for our team. We wanted to leverage this constraint as an advantage, allowing necessity and creative constraints to be the mother of invention.

Trade-offs

The word “trade-off” can carry a negative connotation in software. Rich Hickey points this out in his talk “Hammock Driven Development”:

Everybody says design is about tradeoffs. Everybody knows this. Usually when they talk about tradeoffs in their software, they are talking about the parts of their software that suck. “I had to make these tradeoffs.” That is not what a tradeoff is, right?

You have to look at, at least, two solutions to your problem. At least two. And you have to figure out what is good and bad about those things before you can say, “I made a tradeoff.” So I really recommend that you do that. And when you do it, you might want to write that down somewhere.

Given a small team and a small organization, we can’t create a system like Material Design from Google or Lightning from Salesforce.

Then again, why would we want to? Their design systems are solving an entirely different set of organizational problems than we are.

This is why it is so critical to pinpoint what you want to accomplish and then, per Rich’s advice, document the trade-offs you’re willing to make to get there—because there will be some!

Understanding the trade-offs you’re willing to make helps guide your decision making and reveals your priorities. It’s similar to principles where you state X over Y, but with a trade-off it can be X instead of Y. If you don’t acknowledge that limitation, that trade-off, you’ll mistakenly think you can have both. Only later will you realize the universe isn’t so generous.

Surface and document your trade-offs now

Consider again the quote that began this article from Tim. I’m going to swap out “Product Design” for “design systems” and I think it still holds:

[a design system] is a cascading series of trade-offs. There is no right, no wrong, there’s only trade-offs.

The faster you understand the needs of your organization and the outcomes you want in service of your customers, the faster you can state, document, and make the inevitable trade-offs that come with creating a design system.

You’ll have to make trade-offs in creating a design system sooner or later. If you make them later, you’ll suffer from them longer. Better to document and make them sooner.