Delight is not a design goal

Dan Willis explains why specificity is key to design success

As soon as you hear that the primary goal of the design is to delight users, you know your project is in trouble. It’s not that delighting users is a bad thing; far from it. You’re not going to argue against delighting users any more than you would avoid solutions that are ‘intuitive’ or ‘userfriendly’. These are words that everyone can comfortably agree on, but they provide little actual guidance or value.

My design principles

Delight is a weak goal, and that’s a problem for me because I expect design to take on big, fat problems. When design is ambitious, it is a powerful tool. Rather than relying on vague concepts like delight, I depend on three principles that have emerged over the course of my career.

Principle one: Expect a lot from the design; expect a lot from the designer. It might be tempting to focus on the second part of this and treat it as a challenge to the designer to perform at a high standard. In fact, this principle is primarily a challenge to the organisation. It takes organisational commitment to position design so that much can be expected of it.

Principle two: Design is what it does, and what it does is solve problems. It is not the purview of magicians squirrelled away in dark caves. Design is first a practical tool, a hammer rather than a magic wand.

The less tangibly you define design, the more you have to defend it to others. Breezily announce you’re going to design an intuitive look-and-feel that will bring delight to users, and you’re going to have endless group discussions about which shade of blue is user-friendly. But when you position design as a way to solve problems, it helps non-designers more readily understand the challenge and make meaningful contributions.

Principle three: The design process should both involve the entire team and protect the individual expertise of each team member. UX design works best as a group activity, with designers and nondesigners collaborating in order to define what the design must accomplish. Armed with a solid problem statement created by the team, people with expertise in content strategy, information architecture, design and usability should be responsible for crafting solutions.

Non-designers should continue to participate in the design process throughout the project. This means the traditional design reviews that resembled some twisted form of interior decoration (‘I like the buttons from solution one, but with the colour scheme of solution two …’) can be replaced with more helpful critiques. Based on their particular areas of expertise, team members assess how well a design solves the problem the designer intended to address.

Solving big problems

If design is only a tiny segment of your project timeline, it can only solve tiny problems. You see this when project leads think they’ve figured out a solution and bring in a designer right before launch just to make it look pretty. They’re asking little from design.

The earlier on in the project design work begins, the greater the challenges it can address. Start designing from the beginning and you’ll have the option of introducing an iterative approach. With iterative design, solutions become hypotheses, hypotheses are tested with users, and design improves well in advance of launch.

Designers must work holistically even as they deliver solutions for individual iterations, as every iteration informs the overall design. The overall design becomes like a pencil sketch, improving with each iteration. That’s asking a lot from a designer and even more from an organisation, which is exactly what I think we should be doing.

Dan is a consultant, designer, speaker, author and illustrator with clients who count on him to solve their biggest, fattest, hairiest problems

This article originally appeared in issue 278 (april 2016) of net magazine.