Rigidity vs Flexibility: Finding the Right Balance (aka ‘Rigid Flexibility’)
When discussing Design Systems or Brand Design, I find myself often using the term “Rigid Flexibility”.
Most problems I see with design teams can be attributed to the imbalance of rigidity and flexibility. Maintaining a balance throughout the design process can help minimize friction more than perhaps any other factor.
“Rigid Flexibility”
This silly-sounding phrase basically means striking a balance between a brand or design system’s adaptability to trends & business needs while maintaining the fundamental design principles.
Rigid Flexibility as a principle lets an organization innovate without losing sight of their brand or their design systems core purpose.
Which is more important though, Rigidity or Flexibility?
Let’s look at what happens when we go too far to either side:
“Flexibility is Best!”
“We need to be as flexible as possible! We need to be ready for anything at any time.No stuffy rules to stifle our creativity, this is the best way. Every problem should be approached with complete and total freedom.”
The result of this mindset? Loss of identity, fragmentation.
Without some guardrails in the design process the result can be a diluted brand essence, leading to inconsistency and confusion in the market. As the brand or design system scales, the result can be multiple solutions to the same problem, which equals a fragmented and weak system.
A common example of too much flexibility: The “Color System” present in many design systems:
Often these are accompanied by calculations and strict adherence to rules, but this overly-complex pallette likely does more harm than good.
There may be use-cases where this complexity would be useful but most orgs don’t ever need this level of granularity.
“Rigidity is Best!”
“Strict rigidity is essential so that our entire brand / design system is perfectly in sync.” Rules help us see into the future. If everything follows prescriptive rules we can accurately determine outcomes, what could be better than that?”
The result of this mindset? Stagnation and irrelevance.
Ignoring flexibility may lead to outdated designs, stagnating appeal and less engagement with modern audiences.
When we have rigid systems and processes it becomes harder to do anything outside of those guardrails.
When projects are successful within these rigid walls, everyone else emulates them and everything looking the same. Designers end up arguing and stressing over the tiniest differences in a gradient. Beginners find a component library and a week into it think ‘I’ve made it! I can design just like the team at Linear’!
So the right answer to the question of which is more important, of course, is:
It depends.
Finding the Balance
An effective systems-designer is constantly balancing between these two mindsets.
Every client, every situation, every budget, every team structure will dictate where along the rigidity —flexibility scale you’ll aim for.
Examples
Let’s go through an example in Company X’s brand’s design system. The brand is well-defined, but our imaginary team needs a component on our website to showcase customer testimonials.
Given the above, Design comes up with the following:
It’s a great start!
Let’s continue the example by opting for complete flexibility.
Let’s build the component into our CMS with no rules!
A week later we find the following:
Yikes! That’s no good. Text is weird, images break in a few of them, readability is poor in others…
That was a mistake.
Let’s swing the pendulum to rigidity, lock down the system and create strict visual rules:
Oof. Gonna get sick of that green bg. These all start to blend in together, and even in this screenshot the brand feels icky.
Let’s spend some time considering where we want to land on the scale of flexibility — rigidity.
- We want visual variety.
- We want to cap our text length.
- We want to hide logo and quote if we just want to feature a person, such as a list of board members or employees.
We now have a quote component with variations that can be used in multiple scenarios.
The goal of a brand or design system is to accommodate all business needs perfectly. This is the goal, not always reality.
The goal of a brand or design system is to accommodate all business needs perfectly. This is the goal, not always reality. In the example above there was an instance where marketing wanted to feature two separate ppl on the same component. Our imaginary team weighted the cost and decided that it wasn’t worth the dev/design effort to accommodate that business need, which in this case was an afterthought.
*sidenote: this is one of the great things about ‘agile’ methodology; no longer is the dev/designer shouting ‘no!’ all the time. By breaking it down into features and functionality the product managers et al can understand the actual cost behind something.
Another thing our imaginary team did was go over the requirements with everyone, not just stakeholders. The dev team noted that there was a Profile component that was similar that they needed to rewrite anyway.
Our design team had that in mind when they created these elements, so porting the old component to the new style was fairly easy:
We could have designed this to also accommodate product images, or video elements, or accommodate multiple quotes into a single instance, etc. There are two cautions here:
1) Don’t over-engineer things: There’s no need to build out a super-component that accommodates all images all the time. Ultimately you end up with a behemoth that cannot be changed easily.
2) Plan for the (realistic) future: It’s great to plan for features that are on the distant roadmap, but often this planned accommodation can cost a lot of cycles; it sets you down a road of potential requirements that haven’t been fully-vetted yet.
Summary
This is just one situation where “Rigid Flexibility” is the goal. This example was a component, but the same thinking could be applied to a Button or Form Field in your Design System, to your entire Brand itself.
The more the entire team works with the goal of maintaining Rigid Flexibility, the more well-run your org will be.
