First and foremost, no one ever wants to hear a statement that something is becoming obsolete (the quote Arnold Schwarzenegger repeats in “Terminator Genisys” immediately springs to mind: “Old, not Obsolete”). In the particular case of a Design solution, there’s invariably an attachment which can take different natures towards it. That attachment can come from Designers, Product Teams, Development Teams, and even from Clients themselves. And the attachment itself can be translated as either an emotional connection, one that is driven by a considerable investment, both monetary and time wise, or one that is driven by a systematic and repeated usage, suffice to say, it can be diverse in its nature. All these statements can’t deny the fact that, it ultimately doesn’t mean that the product/solution isn’t moving towards obsoletion (remember what happened to the Blackberry phones). This brief article is indeed a reflection on what happens when Design Languages/Solutions eventually become obsolete, how to tackle this issue, and be strategic about it (as in, think and plan ahead).

Maturing Occurs — Every product solution that is consumed in the market eventually hits a point of maturation. The most obvious case is of course the iPhone or Smartphones in general (as much as it can be disputed, for all intended purposes the iPhone has become undissociated from smartphones in general). Maturity of course does not equate with decline, it just more often than not means that transformative innovation cycles are not as frequent as they were before. For products that manage to have a sound balance of evolution, innovation, married with a strong emphasis on client experience (and understanding), that translates into lengthy product existences.

Evolution Matters — For a product or solution to mature, an evolutionary stance must occur from those who support its existence. And that’s part of the responsibility of the teams involved in the Design process. The Product Design narrative does not end when a product goes to market. The experience provided should continue to evolve and continuously finessed. That’s where analytics, voice of the customer, user interviews, field studies, should continue to be performed, so teams can learn from the actual utilization of the solution. This plethora of data and information in turn should impact how new features are prioritized, and how the product experience itself is finessed, to better adjust to clients needs.

Clients Evolve, Needs Evolve — These days every Designer has the laws of UX at the tip of their tongue and typically bring them up on any conversation with colleagues or even stakeholders. I applaud it, but also recommend that for those who do, to contextualize them appropriately as not everyone is knowledgeable of what they are, what they’re for, and why they are meaningful. All this to say, Jakob’s Law is in fact a reality, and not just an Academic topic used to justify a discussion. Clients these days are probably more fickle than they were before (check this article on trends and how social media for instance now plays such a huge role in driving usage/adoption), but what this means is as follows: users have become more aware of other options, of how to consume product solutions based on how they’re designed. They have also realized that product solutions have evolved to be more personalized, customizable and user friendly, essentially morphed to adapt to who they are. Users’ habits have changed, and that’s not just for B2C products, it also has become applicable to B2B solutions. That’s why organizations such as Calendly, Duolingo, AirBNB, to name but a few, have become so successful. They have found opportunities on the market, and pierced through those needs with product solutions that adhere to how people actually want to consume product and technology solutions these days: usable, understandable, findable, accessible, credible. Users expect technology and product solutions to serve them, as opposed to what was the case for many years, where people had to accept underwhelming solutions as their only option. How users consume product solutions is not the same now as it was 10 years ago. Habits have changed, disruption in society has occurred (yes, Covid included), and all this finds its way to how people behave, what they expect, in any tools or solutions they work with.

Design Languages Should Evolve — I’ve worked in organizations where there were legacy products built with Design Systems that had existed for years, that had never been changed or altered in as many years as they had existed. When some of these organizations decided to move ahead with the topic of Digital Transformation, this obviously impacted the evolution of that Design Language. For some it meant building a completely new Design Language (or new Design System), which of course is a considerable investment. However the risk always lies with asking yourself from a business and longevity perspective: can one afford not to evolve, and not to listen to what your clients are saying. And just to reinstate the obvious: evolving a Design Language isn’t synonymous with building more components for a legacy system.
Evolving a Design Language means having the self-awareness to realize that much like any language, there are neologisms, there are changes that occur in something that is used every day. A language is a living organism, and as such it needs to be aware of the context in which it operates. And much like point number 3 illustrates: users expect evolution, not a gratuitous evolution for the sake of just changing something randomly, but evolving to reflect the needs they have. Users expect at least a level of familiarity/parity with how other products have also evolved in the market and therefore they will always compare how your solution is stacking against those expectations. Designers in particular should always remember: users don’t live and operate in a tiny bubble of exposure to your solution alone. They’re exposed to so many other product solutions, which impacts how they work, how they perform, and what they expect from a solution. This point can be succinctly summarized as such: as good as your Design Language (and System) is, it has to evolve in order to satisfy the needs of your users/clients. It’s unthinkable to keep delivering the same type of experience now that was delivered 10 years ago (for some professionals in the Design/Product arena that time gap is even shorter). Users expect more, because the cycles of innovation have dictated as such, because technology has evolved, because trends have evolved (even the iPhone’s Design Language has evolved). Denying users of something like a mobile experience in 2024 is as nonsensical as forcing people to stop buying items online. Designers and their peers need to move with their clients, not against them.

Obsoletion — Not every product solution lives forever. Not every brand lives forever (remember 20th Century Fox, which is now 20th Century). These are very self evident facts. As I mentioned on prior articles, the qualities of long lasting brands include: self awareness, being principled, deliberate, focused and adaptive. These are qualities that are applicable to Design solutions and Design Languages in equal terms. Knowing that every solution has an eventual decline, does not mean that the investment in its longevity should be of a lesser extent: quite the opposite. If anything, Design solutions should always be prepared to weather that lifecycle, and be supported by a Design Language that makes sure they remain as relevant and vital for their users as the day they started.

Theodore Roosevelt wrote:

“There can be no life without change, and to be afraid of what is different or unfamiliar is to be afraid of life.”

Brief Considerations on Design Topics: 21. Obsoletion of a Design Language was originally published in UX Planet on Medium, where people are continuing the conversation by highlighting and responding to this story.