Delight is not a design goal

UX and product teams should avoid relying on delight as a design goal. Making product design decisions on the premise of delighting users can distract from more important goals and place intended outcomes at risk.

Whether it’s time-to-market, performance, maintainability, or delight, any product decision building toward a meaningful end goal requires balancing constraints based on a number of qualities. Robust discussions between designers, software engineers, and business stakeholders require alignment on quality attributes across a product in order to consistently prioritize identified requirements in product decisions. Delighting users is a well-intended goal that design and product teams frequently mistake for a meaningful quality attribute when making decisions — and take mental shortcuts in prioritizing.

Quality attributes are non-functional requirements of a system that are typically measurable, such as performance or time-to-task-completion. These attributes easy to overlook if not explicitly identified by overarching tenets, and are often measured in degree, rather than being binary features. In the ideal world, when designers, software engineers, and business partners prioritize and architect for business needs and user outcomes, they aim to deliver on certain quality attributes, often sacrificing one attribute to deliver another more critical attribute. Quality attributes exist within a matrix of constraints, where decisions must be made to prioritize or balance them in order to achieve outcomes consistent with business and product goals.

Because project stakeholders such as UX designers, software engineers, and product owners often communicate with different languages, goals otherwise understandable by all of them can easily become implicit rather than explicit. The natural consequence of this is that it leads well-intentioned teams to place their own subjective goals above the best outcomes for the product, business, or users. I’ve seen many front-end teams with well-considered goals and sentiments shared between team members, and the same for design teams, but effectively synchronizing those priorities with the surrounding context is more challenging than establishing and upholding them within a single team or group of like-minded peers.

Delight is not a useful design goal because it’s amorphous. Any team member can insert their own preferences regarding what qualities of a design are delightful. Every user has different needs, and what’s delightful to one group doesn’t necessarily apply to another. With this in mind, delight can’t be quantified or delivered consistently by team members, and even if a product truly requires delight as an outcome, aiming directly for delight as a design goal will fail to consistently deliver it for end users.

Instead, we can identify who we’re aiming to delight and how we’re going to accomplish this. We can define a target audience, and break down what key elements or tenets contribute to positive — perhaps delightful — outcomes for this group. These are the first steps to delivering an experience that is consistently positive for our users, and with a coherent product design direction that can be understood by all members of a team.

In short, we can prioritize a product to be fast, to be efficient, to be clear, or to be straightforward. But we can’t directly prioritize delight — we need to instead prioritize identifiable factors that create the intended positive experiences and outcomes.