Revolution vs. Evolution: applying a design system with limited resources

Designing to an ideal doesn’t lead to ideal outcomes

TL;DR Summary

• Many (most?) digital product teams don’t have design-centric leadership and/or the resources necessary to undergo a major product redesign (or to apply a new design system comprehensively).
• However, a common designer pitfall in these organizations is to design “ideal,” aspirational patterns that represent major change in the system: that is, “let’s design the best system we can think of,” instead of a system that will best enhance the existing product.
• My preferred approach is less “revolution,” more “evolution”: by growing a system from the roots of the existing product (rather than forcing revolutionary change), you’ll achieve a more coherent, predictable, user-friendly user experience much faster.

The longer version

Companies have limited resources to facilitate design change

Organizations like Airbnb and Apple have shown us that a design-first approach to product can lead to beautiful experiences — and, hey, sometimes even commercial success! And companies like MailChimp and Google (with the launch of Material Design) have done an admirable job course-correcting into comprehensive positive design change.

Often when design teams talk about design systems, those are the companies they have in mind: “What we need is a Material Design for [our product]!” Very exciting stuff, but that’s a tall order for a team with limited, high-demand engineering resources that already have a loaded backlog: they’d love to have a well-designed product, but first they must work on [X, Y, and Z projects]… all which probably have clearer “ROI” stories than design changes.

Sound familiar? It does to me, especially in the early- to mid-stage organizations I prefer to work in.

So, you’re a designer working with a limited Engineering “budget.” You’ve got great ideas for your product, plus new patterns, behaviors, and aesthetics you’re just dying to implement. But when you step back and look at your entire product today, here’s how you feel about it:

Your product and how you feel about it. Hint: it’s an abstraction (unless your product is a bubble machine, in which case this is pretty close to the final experience :P)

There it is: you’ve got your big, core user experiences, which over time have been adjoined with sibling pages, flows, and other product branches. These were built over the course of months or years, by varied product folks with varied design directions. Some of these features were probably built as MVP solutions — “our customers need this now! We’ll add ‘design’ later” — and haven’t been touched since. All of this was built with the best intentions for the user and the business, but as a design system, you may be dealing with a rat’s nest of experiences.

So how do you, product designer, get this thing into shape?

Revolution: reaching design nirvana in one big shot

Vive la révolution! When you’re sitting in Sketch in front of your Apple Thunderbolt display, this is an easy emotional trap to get caught into: “if only I could start from scratch, I could make this product sing!”. But how do you plan on actually implementing this? Probably something like this:

Woohoo! It took a lot of (mysterious) work, but we got the product we wanted.

Great job: you’ve gotten your perfect design system! Let’s break down this approach for applying a design system.

Pros

• Your product now has the design of our dreams! IT’S MAGICAL!
• You designed everything at once, with the same designers in the room, so it’s all super cohesive and thoughtful. FEELS SO GOOD!

Cons

• This… pretty much never actually works out this way.
• Tons of resources needed to be dedicated over a long period of time.
• This was designed in a vacuum (whether it was well-researched or not), so it doesn’t consider some real-world challenges that you will inevitably discover once real users start using it.
• Lastly (but maybe mostly), your users/customers had to use the old crappy version of your product for months or years, only to face a sudden massive shift in the product design whenever you release this new thing.

Whew. This is not my recommendation. And, in fact, when I’ve seen teams go down this path, usually you end up at the fallback plan anyway…

The “North Star” model: achieving product design nirvana, one marvelous blip at a time

So, your team is designing their ideal product experience, but it turns out you don’t have the resources needed for a unilateral design revolution. Fancy that! But now that we’ve designed these great patterns, behaviors, and rules, let’s start applying them opportunistically as we work on product pages and features anyway. Here goes nothing:

The “North Star” model for redesign: shoot for the moon, but implement bit by bit.

Alright, we’ve got some movement here, and by the end of this process we’ve got some really nice experiences in our product (even if we’re still carrying some baggage with us, too).

Pros

• See your design dreams come true in your product, even if it’s just pieces.
• Much more realistic than the full Design Revolution.
• In the distant future (and if you’ve managed to keep the same design preferences through these years) you just might see the rest of the product round out to form. Maybe.

Cons

• More dramatic changes require more resources per change (as you open up edge cases, technical restraints, etc.), so the rate of change is slower than if you used old or more conservatively-changed patterns.
• You got some great design by the end, but look at the transition phases of this project: that’s months or years that your users and customers are using these this really patchy product, where the experience and style may change dramatically from screen to screen. Are you really designing so that your work will finally bear fruit years from now? Didn’t think so.
• By the time the majority of your product has migrated over to this new system, you (and the rest of the design community) have probably shifted in terms of what’s considered to be good, common, or even trendy UI design. All that work and you’re still stuck with a design (that’s right, your “new design”) that’s a few years old.

A particular, small example comes to mind when I think about this “North Star” model: using traditional form fields versus Material Design-style fields.

Old school fields vs. Material Design fields. They’re way different.

In terms of style and behavior, these are very different, so if you’re migrating portions of your UX bit by bit, you’re going to have dramatically different forms and inputs presented across your product. It’s a small example that represents a larger problem in making dramatic design changes in a piecemeal way.

But, there’s hope! You can avoid difficult, sloppy design change by designing a system that builds on what you have. One might even say you should “evolve” your product from where it is today…

It’s Evolution, Baby: getting to a better product, faster, by appreciating what you’ve got

For a design team with limited Engineering budget, I recommend you build (or enhance) your design system by taking the best of what your product does already and building on it. Even if you’re the first designer on a small startup team, somebody (whether it was a designer, product lead, or developer) chose to make these UI decisions for real reasons. Your steps will vary depending on the current state of your product, but the process starts something like this:

1. Learn about your current design system (if any): where do components come from? Is there a core styles sheet or library somewhere in your org? How are these organized? Who built it? Who uses it the most, and which parts of it do they use? When do they have to go off-road without it?
2. Inventory the patterns and behaviors that you see in your product: how do you present different types of information to users? How do users choose what they want to see? How do they input information? For interface elements: do you see tabs, cards, lists, or forms? In what situations does each element come up?
3. Write down the rules that your product seems to follow; then tighten the rules up yourself: somewhere behind all the design debt, there’s a logic to how your product has been put together. Understand the design rules that your product seems to follow, then double down on them. “We seem to use tables for a lot of things, including when users have to choose what to engage with” perhaps turns into a rule: “we use table rows to let users choose between related, but independent items.”
4. Get consensus from your team(s): communicate your evaluation and your plan. Consensus building is easier said than done, but that you built this system from the existing product will make this conversation and transition easier than if you make up brand new patterns and rules. Surely a lot of these stakeholders were also contributors to how the product looks today, so this path is more respectful of their roles, and all of the organizational knowledge baked into the existing designs.
5. Start building with this system: now that you know what rules to follow and patterns to use, spec those patterns out and start following the rules! The next time your engineers are putting in a table, a card, a form, etc., make sure it’s that spec’d element and that they’re using it in the right way. In time, more of your interface will be using this new design system, but it should blend relatively well with the older portions of the interface.

Let’s see how this “Evolution” model works out for you…

The “Evolution” model for applying a design system. Hey, things get green pretty quickly!

Pros

• SO MUCH GREEN. By basing the new system loosely off of existing patterns, you get to “good” faster.
• The “good experiences” mix relatively well with the “old experiences,” making for a more seamless experience — yep, even during those tough transitional months and/or years.
• Less dramatic change means you can apply your new components and patterns faster. Then when they’re all plugged into the system, you can change and update them at a system level: that increases the odds that you be able to keep up with the Jones’s next door (i.e., your competitors) later on once they inevitably get a new UI of their own.
• Less dramatic change can also be good from the user’s perspective: users somewhat-famously dislike change (see every Facebook redesign, ever, or a large scale redesign of your favorite B2B tool), so avoiding huge leaps may mitigate bumps in your relationship with your users/customers.
• This is less resource-intensive and more natural to your organic organization. As opposed to “revolution” and giant executive initiatives, this can better maintain team goodwill. It makes doing good design feel right, rather than it just feeling like a lot of really difficult work.

Cons

• None!
• Just kidding. As you can see, we didn’t actually get to the “ideal” phase of design nirvana in this model. The more conservative “Evolution” model got us good design faster and easier, but perhaps we didn’t embrace some ‘big idea’ opportunities that we otherwise may have.
• At times, working small and not planning a “grand vision” can cause you to miss some dependencies and/or opportunities later on in your design system evolution. There are ways to mitigate this — e.g., by having some sort of vision other than “take baby steps” — which I’ll get into in a more detailed post later on.
• Sometimes the “old” product design in your product is really, truly bad, so it may not even be a good starting point. (This is a tempting mental road to follow, but I’d discourage you from doing so: in most cases, if you are working on even a moderately successful product then something in the old design is working well, whether you prefer it or not).

So wait, in the Evolution model we didn’t end up getting to the ‘ideal!’ stuff! Isn’t it my job as a product designer to make the BEST DESIGNS EVER for my users!?

Your job is to improve the experiences that your customers and users have with your product. If you shoot for the moon on every little design and then burn a bunch of Engineering resources making those changes a reality, you could be “spending” those resources poorly and thereby limiting the amount of work you can do to improve other stuff for your users. Is making one user flow perfect better than making three user flows good? Maybe for you, but probably not for your users.

By being more realistic with your design system — by building it from existing foundations and keeping it transition-friendly — you can more quickly adopt a new system and you (and your users) can start reaping the benefits.

So, go forth and Evolve!

Update (a year or so later)

I’ve written another piece about this design system I was working on for Hired — the same project that inspired this “Evolution” piece a year prior.

Triumphs, losses, and lessons from building a design system

I’ve softened my position a bit on a “North Star-like” approach given some lessons from that project, but the core tenants of this post still stand: In most cases, Evolution is still the responsible approach for your users, your product, and your organization.