Great write-up! I’ve been pondering over the topic of consistency since quite a while now, sitting on it hoping to write on it someday. I am, however, constantly oscillating between trying to enforce consistency in the products I design, versus breaking the consistency with hope of moving forward.

Consistency draws out many parallels;

• Consistency within a product’s design and consistency across the range of product offerings.

Google Calendar has almost zero similarity to say, YouTube. Its not even consistent with other productivity apps of theirs such as Sheets. Heck, even the mobile app and the web version of Calendar has different UX patterns, even completely opposite patterns. They are inconsistent.

• Consistency versus familiarity.

How Apple’s design language creeps into their third party apps built for Apple products is mostly an example of familiarity. Since if you get out of the Settings page of that said third party app, the rest of the experience is often different. Ergo, inconsistent.

• Consistency in product line when users are never overlapping.

Say, Amazon seller side versus the usual buyer portal. Or even their cloud analysis products. Then is it the user experience consistency or the marketing/brand consistency? There are many aspects of it. Does the analysis product need to inculcate the dark patterns the buying page? Does it need the same components? Does it need a dark mode?

• Consistency across geographies.

Demographics compel inconsistencies. Cultural connotations of colors and symbols, language and translations reading direction. Enterprise products are heavily influenced by these. Incidentally, I wrote an article on this.

• Inconsistent tech stacks.

Usually, enterprises end up having silo pillars, which have almost never seen each other after that second round of funding. They departed their ways long back and all efforts to keep the architecture decisions similar, went for a toss with each resignation. These pillars distance each other even further owing to the abyss of human ego. Then, one product line is built on Apache and other on Angular. And then some product manager decides to have one inside the other in an iFrame. (If the designer doesn’t jump out the window at this point, it is advised to seek professional help!)

Problem with enterprise products is that they might have been consistent decades ago when they were launched, but simply cannot be at all times. The life-cycles of enterprise products are such. In my experience a lot of times, consistency usually ends up as a classic hindrance to upgrading a design system.

With almost little to no possibility for large scale changes at once, you cannot, and anyway should not change the whole product suite’s design.

The tech debt is so ginormous, that thinking of having design consistencies is a privilege an enterprise legacy product cannot afford.

But what to do if the product and its design is a decade old. You try to make incremental successions. Almost all work in enterprise products are such. At these times, it becomes almost mandatory to decide between changing what can pass through in one release, and it almost always is bound to break this consistency.

The designer is usually broken between maintaining consistency and keeping up with the times, given the tardiness of complex org structures and scattered development priorities and efforts.

Consistency, quite usually becomes a peril and even an antonym for progress.

Consistency, often, results in trying to maintain the status quo.

P.S. Medium has a consistent design in writing an article and a comment, ergo, I ended up writing a comment as I write an article!