Delight is not a quality attribute

Approaches to UX and front-end development that focus on delighting users risk prioritizing low-hanging interactions over a comprehensive, successful outcome.

Delight isn’t the only goal design and front-end teams take mental shortcuts in prioritizing. Whether it’s web performance, extensibility, or delight, any product decision building toward a meaningful end goal requires balancing considerations from a number of stakeholders. Robust discussions between designers, software engineers, and business stakeholders require alignment on quality attributes across a product — figuring out what the essential requirements of the product are.

Quality attributes are non-functional requirements of a system that are typically measurable, such as performance or time to task completion. These attributes are measured in degree, rather than being explicit features. In the ideal world, when software engineers and business partners prioritize and architect for technical and business needs, as well as user outcomes, they aim to deliver on certain quality attributes, often sacrificing one attribute to deliver another more critical attribute.

Because these disciplines often communicate with different languages, goals otherwise understandable by all of them can easily become implicit, rather than explicit priorities. This can have a consequence, leading teams to place their own pet goals above other business outcomes. 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 larger organization is another matter. That goes even in organizations that consider themselves design-driven.

What does this have to do with delight?

Delight is an ineffective quality attribute particularly 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 really requires delight as an outcome, aiming directly for delight will fail to consistently deliver it for end users.

Instead, knowing who you’re delighting, formalizing a target audience, and breaking down what key elements or tenets contribute to positive — perhaps delightful — outcomes for this group, is the necessary first step to delivering an experience that is consistently positive for a given set of users, and capable of being 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 straightforward, but perhaps not to be delightful.

or reach out to me at