Delight is not a quality attribute

UX and product teams should avoid relying on delight as a design tenet. Making product design decisions on the premise of delighting users can distract teams 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 considerations 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 quality requirements in product design decisions. Delighting users is a well-intentioned goal that design and product teams frequently mistake for a meaningful quality attribute or source of information 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 as overarching tenets, and are often measured in degree, rather than being explicit 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 priorities. 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.

Delight is an ineffective quality attribute because it’s amorphous. Any team member can assume 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. From that standpoint, 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 tenet will fail to consistently deliver it for end users.

Instead, know exactly who you’re aiming to delight. Formalize a target audience, and break down what key elements or tenets contribute to positive — perhaps delightful — outcomes for this group. This the necessary first step to delivering an experience that is consistently positive for a given set of users, and where a coherent product design direction can be worked toward by all members of a team.

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