Debate #1: Usability vs. delight


Topic: We should design for usability, then add delight.

As Zoltán Gócza of states in Myth #27: UX design is about usability

Designing for the user experience has a lot more to it than making a product usable. Usability allows people to easily accomplish their goals. UX design covers more than that, it’s about giving people a delightful and meaningful experience.

Benjamin Tollady asks on

Should we design something delightful, then make it usable? Or should we make it usable first, then add delight afterwards?

We’ll begin with opening statements. Luke, as the affirmative team, you’re up first.

Can You Help Me With A Brief Product Development Survey?

Whenever you’re ready Luke—you just take your time. No hurry …


The idea [I]“useful, usable and delightful”[/I] originates from a treatise by Roman architect Vitruvius, who said ([URL=“*.html#3.2”]in Latin): [I]“The ideal building has three elements; it is sturdy, useful, and beautiful.”[/I] Via [URL=“”]an interpretation into software design, it has been articulated as a design problem, not an engineering problem, and is now handy for qualifying UX and explaining its holistic aims for our projects.

These three words are used in that order for an important reason. Let’s have a quick look at their definitions:
[][B]‘Useful’[/B] stresses that a product must answer a specific need (the business case, if you like). This is the purpose for the product or website to exist. Without it there is no product. A clear initiation for the project.
][B]‘Usable’[/B] describes how that product can succeed by being appropriately functional, in order to deliver the promised value successfully to the intended users. It [I]delivers[/I] the use.
[*][B]‘Delightful’[/B] is the cherry on top that exceeds the expectations of a user and takes the product to a new level of relevance, humour and personality. It’s the final master stroke that demonstrates finesse in our understanding of users.
[/LIST] Delight is the final and critical consideration when delivering a successful UX project. It works by enhancing context and meaning to ensure that a product is relatable and has personality. It has a powerful effect on the way a site is perceived and experienced, but it cannot work without a usable foundation.

[SIZE=12px][SIZE=14px][B][SIZE=16px]Don’t half-bake your cherries[/SIZE][/B]

There are not many parallels between baking and UX, but the few that exist are as full of goodness as your grandma’s home-cooked meals. Just as we put cherries on top of cakes - not inside them (that’d be a fruitcake) [/SIZE][/SIZE]UX must be value-driven, not ‘bling’ driven with cherries half-baked in.

Here are four important reasons ‘delight’ must be considered with deference to usability.

[B][SIZE=16px]1. Delight is best used with subtlety[/SIZE][/B]

Here are some excellent examples of delight, collected from various websites and mobile apps thanks to​ Kintan Brahmbhatt and [URL=“”]Ben Tollady:
[]a page background that changes to match the search term in a restaurant search app
]anticipating desires using simple cues such as time of day to recommend music playlists based on common moods or activities at that time
[]an iOS icon that changes its look when re-arranging a wriggling icon
]microcopy used on a 404 page to reveal human personality behind the site
[]animated dropdown menus that have a purposeful transition and actually dropdown (rather than abruptly appear)
]image rollovers that feel tactile are a unique and interesting interaction
[]humour as a way of blurring the lines between a human user and a computer website
]images on an about page that poke fun at stereotypes and create humour
[]asking the user if they’re a time traveller if a future date is added in the birth date field
]skeuomorphic page turns/curls in reading apps
[]zooming all the way into the surface of the moon in a mapping app rendered it as a piece of swiss cheese
]no functional purpose, but a sense of discovery when clicking on a profile image to discover R2D2 instead
[]pulling the screen down in a popular bookshelf app has a positive impact on brand loyalty
]a lack of distracting buttons and options to leave an uncluttered writing experience
[/LIST] You can see they are composed of witty asides, intentional simplification, clever attention to detail, and the element of surprise. Delight doesn’t work when used as a sledgehammer - the above examples all use delight with [I]subtlety[/I], not as the primary purpose of the design.

[B][SIZE=16px]2. Delight can not be used as the primary foundation of a product[/SIZE][/B]

The premise that delight is an attention to detail, an element of surprise, or an unexpected feature suggests that these things are a bonus for the user, and not part of the [I]required functionality. [/I]

It would therefore seem unusual to base a design project for a product on [I]non-required[/I] functionality - and especially so if it comes before an understanding of what the [I]required[/I] functionality actually is. As Walter Sobchak says in The Big Lebowski: “My friend, you’re entering a world of pain.”

There are be three sobering consequences of making delight the emphasis of the experience: [LIST=1]
[]We’d spend a lot of time obsessing over small components, rather than getting the basics right and then chasing the details
]We’d spend a lot of time inventing new interactions that are clever but ultimately just gimmicks
[*]Our projects would be defined by fads, rather than focussing on delivering something that addresses the core need, is timelessly usable and has appropriate elements of delight.
[/LIST] Any successful attempt to add delight to a UX project must first consider usability before it can seek to take engagement to the next level.

[B][SIZE=16px]3. Usability is as fundamental for UXers as spelling is for writers[/SIZE][/B]

The rise to fame of user experience design, especially over the past 10 years, and its subsequent [URL=“,d.dGI”]subsuming of the ‘usability’ role, is testament to the importance of not putting the ‘gimmick’ cart before the design horse. UX assumes that ‘usable’ is a mandatory value of the UX process - that usability is as fundamental for UXers as spelling is for writers.

Without decent spelling and good grammar some of the finest works of literature would be painful to endure, or perhaps totally unreadable. And anyone with experience working on a book-length project will appreciate that bad writing makes the editing process difficult, no matter how inspired the thoughts attempting to be communicated.

This is the same with user experience design - fundamentals such as usability must be designed into the product (at a certain level of quality) from the very beginning. Retrofitting usability will be a painful process with limited success - no matter how inspired or delightful the original vision is.

[B][SIZE=16px]4. Delight by itself doesn’t make up for poor usability[/SIZE][/B]

The Peak-End rule is a heuristic theory that describes how people judge an experience by its most intense point and its end point (as opposed to the total sum or average of every moment of the experience).

Consider our virtual friend Bob. He needs to transfer funds to his friend’s bank account. Bob’s bank provides an online banking service allowing him to transfer funds using his mobile phone. Let’s look at two ways this site could have been created: [LIST=1]
[][B]Delightful first, with retrofitted usability - [/B]Bob’s experience is interrupted by distracting options and some usability issues. He starts getting frustrated when he can’t find where to initiate a bank transfer, but manages to find it eventually (below a parallax-effect menu). He is left confused and unsure if the transaction was actually successful. The experience was certainly novel, but Bob doesn’t really care if he couldn’t complete his task quickly and satisfactorily.
][B]Usable first, then adding delight - [/B]Bob can easily identify and use the core functionality of the app. He proceeds smoothly, is confident, and impressed with the product - mainly because it feels friendly and personal. He finishes on a ‘successful transfer’ message that leaves him with a good impression. He tells his friend (and anyone else who will listen) about the cool banking app he uses.
[/LIST] It’s an exaggerated example, but we can see that if delight is the primary objective, elements of use and usability come off second-best.

Delight by itself doesn’t make a product more useful or usable, but it can help. For this to be successful, a clear understanding of a product’s usability needs to be balanced with innovations, and usability issues need to be cleared out of the way.

[B][SIZE=16px]We put cherries on cakes after they’re baked and iced, not before.[/SIZE][/B]

We all agree that without usability, a product is doomed to fail its primary goal of being useful. This means that if a product isn’t given the best chance to be usable, delight will subsequently be wasted.

Founding a project primarily on ‘delight’ distracts us from our responsibility as user experience designers to deliver value to the people who will be using the product. We’d be in danger of simply providing entertainment without delivering on purpose.

We are more than just creators of entertainment and have a strategic role to play in our workplaces. We can’t afford to compromise a meaningful, delightful experience by neglecting usability.

So, don’t be a fruitcake - put your cherry on top. The correct way to bake your UX cake is to make it [I]useful[/I], then [I]usable[/I], then [I]delightful[/I].


Jeepers. Perhaps we should have agreed on a word count limit beforehand. I didn’t know you were going to write a book for your opening statement.

I’m travelling for the rest of the week, so there might be a delay before I’m able to respond to all of this properly…


Wow Matt, he’s calling you a fruitcake!

Nice start Luke. Perhaps slightly longer than your average opening statement, as Matt says, but a solid argument.

In the interests of fairness, I think it would be prudent to hold all comments until Matt has had a chance to rebut, and then I’ll throw it open to the floor.

Over to you Matt (when you’re ready).


Wowsers!!! A fruitcake aye…??? Looks like the gloves are coming off for this one. :slight_smile:


I’d wave the white flag if I were you! Plus as UXers aren’t we already conditioned to side with making it more usable first and foremost? - as an aside, I’m very curious if you have a screencap of the “Are you a time traveller?” screen - it points to Yahoo, would love to see that.


OK, here goes.

As I’m sure you’ll all agree, my esteemed opponent has presented what, on the surface, would appear to be a convincing foundation for this conversation.

However, while he’s dispensed some sage wisdom, unfortunately (for him) he’s made several rookie mistakes—mistakes that make it easy for me to cast aside these foundations and replace it with much more convincing facts.

Sure, he’s bamboozled you with link after link after link, hoping you’ll view his treatise as “well-researched”. And he’s broken down his argument into a solid structure. But even a well-structured building will crumble if it’s made of cheap materials.

[B]What are we arguing here?[/B]

The first mistake Luke has made is to not explore any kind of definition of the topic. He just launched straight into an historical derivation of the phrase “useful, usable and delightful”.

Unfortunately, this interesting etymological detour only serves to help my cause, which is to argue the negative: [I]that we should [/I][B][I]not[/I][/B][I] design for usability, then add delight. [/I]Note that my goal here is to [B]disprove[/B] the stated topic—[B]not[/B] to prove any one particular alternative is better.

Of the three adjectives Luke has launched into, that first one, [I]useful,[/I] is the most important. We should always do work that matters; we should strive to design something that is useful first, over and above everything else. I would much rather have an app that was difficult to use and uninspiring, but made my life better in some way, than an app that was easy to use but pointless. Usefulness should come first. As Luke said, “Without it there is no product.”

[B]Looking beyond semantics[/B]

Some of you might be thinking: “That’s a cop-out, Matt. Sure, you got him on a technicality, but we’re not convinced until you [B]really[/B] tackle the topic at hand.”

Fair enough. I’m happy to look past this amateurish oversight and, for the sake of this exercise, tackle his assertions head on.

[B]Let’s define delight then, shall we?[/B]

In his opening statement, Luke relegates [I]delight[/I] to “the cherry on the top”, but in the sentence that follows, refers to it using words like “critical”. Which is it, I ask? If delight is indeed critical (and I agree that it is) then surely it should be represented by something more critical to baking a cake than a cherry? Doing so completely discounts [I]the importance of delight as part of the solution to a problem.[/I]

Delight is an emotion. We [I]feel[/I] it. We humans are far more difficult to impress, far too cynical than to be really [I]moved[/I] by novelty transitions and image rollovers—at least after the first couple of times we interact with them. Here are some personal examples of when I can remember being truly delighted by technology:
[]About 18 months ago when iOS6 came out, Apple decided to replace the excellent Google Maps app with their own version. Unfortunately it sucked. To keep using Google Maps I had to manually go and get it from the app store. However, when I installed it, the new app suddenly had this incredible new “driving directions” feature. Mrs Google herself guides me to my destination with a voice that manages to straddle being both sultry and efficient. This feature was integrated beautifully into the Maps app that I knew and loved, but it added an entirely new dimension to the world around me. I was giddy at the new-found freedom that this opened up for me and my poor sense of direction. [B]This was not a cherry—this was core functionality[/B]. This feature still delights me; I am constantly impressed when I take a wrong turn and Maps re-routes my trip in a second or two—less time than it takes for me to comprehend the sheer volume of processing and data going on behind the scenes for that to happen.
]Here’s another example: BadLand, an addictive side-scrolling game that I bought for my iPad. When you buy the game, you’re launched immediately into the first level, with no tutorial, no onboarding … nothing. At first I was a bit thrown—there are no obvious hot spots to indicate what the controls might be. You’re left to your own devices. I touched the screen, and—whoah—the cute little bat flapped his wings and moved. Then I let go, and he fell back down to the ground. I touched somewhere else on the screen and he did it again. And so I came to learn that the game works by touching [I]anywhere[/I] on the screen to flap the bat’s wings, and letting go to stop flapping. It’s possibly the simplest game control ever devised, but it works beautifully, and as you master the control, you learn the extraordinary degree of variance that you’re empowered with. [B]This control is not a cherry—it is the core mechanic upon which the game is built.[/B]
[/LIST] [B]Aren’t you just choosing a different definition to win the debate?[/B]

No, I’m not. Delight is a core element to strive for when designing, because design is first and foremost about solving problems, and to use a quote that I know is one of Luke’s favourites: “Designing an interface to be usable is like a chef creating edible food.” (Aaron Walters). That’s why I believe we should start with delight first. Here’s a diagram that shows what happens if we don’t:
If we start with usable, and only add delight at the end, then what we’re doing is refining too early. We’re assuming that microcopy, novelty transitions, skeuomorphic page turns and the like will be enough to turn our users into passionate fans. We’re assuming that these things will delight them. [B]They won’t. [/B]

True delight comes from wowing your users by solving their problem in an innovative way, whether that’s because it’s super-fast, or over-delivers on context, or just [I]nails it[/I]. Not by looking pretty. When we’re exploring solutions, we should entertain [I]all[/I] ideas on the off chance that one of them is truly innovative. Those ideas are not the kinds of things you can just bolt on at the end.

Sure, by doing so we run the risk of heading down a path that is so crazy that it would be impossible to make it useable. But that’s when we need to refine or, if necessary, discard and try another option. That’s how it’s supposed to work. It’s why we iterate and test and validate our prototypes. It’s much better to have explored that option and discounted it, than to never have known it was there at all.

After all, if all you’re aiming for is to put a cherry on top, then you’ll only ever get a lukewarm response (bada-boom tish).

[B]But what about that example banking app?[/B]

This is a poor example that assumes that a delight-first approach would compromise on usability. It shouldn’t. We’re not arguing that usability should be compromised. We’re arguing that it should be considered [I]after[/I] delight. The other way round limits the possibilities.

To bring it back to Luke’s baking analogy, why assume that your users want to eat cake? Perhaps what they truly want is for you to bake them a freaking 2-metre tall croquembouche!

You’ll never know if you just start baking.


Oooh getting good.

Not to pick sides (and can we jump in or not?)…but…

In some usability tests I heard about, people were saying “This looks intimidating”, and “It looks like a torture device”

After use:

“I’d buy it!”


This is getting good!

Absolutely! Please do. The floor is open for support and heckling.

Low blow, but I love it.

Very good point Matt. Perhaps key to your argument.

Luke, I invite you back when you’re ready, to make rebuttals and enlarge on the points of your case.


[SIZE=15px]Thanks Matt. It’s good to hear what you’re thinking. [/SIZE]

[SIZE=15px]I’m glad Matt has come to the party and continued in the spirit of my cake references. And it’s good to see him remembering one of my favourite quotes too:[/SIZE] [INDENT][I][SIZE=15px]“Designing an interface to be usable is like a chef creating edible food.”[/SIZE][/I][SIZE=15px] - Aaron Walter (Director of UX at MailChimp). [/SIZE][/INDENT] [SIZE=15px]I’ll illustrate why this quote undermines Matt’s whole argument in a minute. [/SIZE]

[SIZE=15px]Matt has chosen to enter the debate with a clever repositioning of his topic in light of my opening salvo. It doesn’t do much for his actual arguments, but fortunately you’re all enjoying the scenic route as he rambles from one point to another, so at least it’s educational! To make sure it is so, let’s together pick apart Matt’s points, one by one. [/SIZE]

[SIZE=15px][B]The fundamental problem with Matt’s position[/B]

Matt seems to be arguing that exploratory design should only consider usability [/SIZE][I][SIZE=15px]after[/SIZE][/I][SIZE=15px] an innovative idea has been generated. This is counter to my demonstrations that delight is achieved as an over-delivery or extension of usability, and that innovation and usability are not mutually exclusive.[/SIZE]

[SIZE=15px]Dean shared an excellent point above; that being able to overlook the face-value of usability tests can be important, in his example because the bottle opener actually performed its use excellently. Its delightfulness came through the fundamental usability redefining the solution, transforming an unsavoury initial impression into passionate advocacy.

This is where Matt’s [/SIZE][SIZE=15px]rookie mistake comes in. The logical extension of his opinion that delight can only be injected through creativity (not usability) is that user research overly defines the project’s functional scope. This isn’t true. Seeing as we’re peppering our debate posts with quotes, let’s use this one that Henry [SIZE=14px]Ford didn’t say, but does help explain things:[/SIZE][/SIZE] [INDENT][SIZE=14px][I]“If I had asked people what they wanted, they would have said faster horses.” - Not Henry Ford[/I][/SIZE][/INDENT] [SIZE=14px]Essentially, we shouldn’t limit our ability to provide innovative, usable solutions by taking our users at face value. Understand their context behind what they say, and use this as the basis of our design. How can we design for accessibility, and even make it delightful, unless we know accessibility is an issue?[/SIZE]

[SIZE=15px][B]“You’ll never know if you just start baking.”[/B]

Indeed! Although Matt’s idea of exploring delight without a foundation is surely the same thing? It proceeds by jumping in the deep end and seeing where you end up, so I’m a little unclear what he’s trying to say. At least building from usable to delightful has a solid foundation and a clear, repeatable, reliable process with the ability to add infinite delight where appropriate.

Luckily the first thing I [/SIZE][I][SIZE=15px]don’t[/SIZE][/I][SIZE=15px] do when I first start my food planning is to start baking. Well, of course there’s nothing to bake yet! Instead, my first task is to research the intended users (my partner or family) about their needs and context. Are they hungry? Are their preferences sweet or savoury? Are they on a health-kick? Do they have any allergies? I then survey the available resources (neatly kept in the pantry), my own goals (goal: to feed a group of four with dessert and make them want to come back again next time) and my own mood (my intentions to improve how I provide for my diners). I set a direction and define my project. [/SIZE][SIZE=15px]I know two novel ingredients have particular properties and decide to combine them. I [/SIZE][SIZE=15px]then enter an iterative phase of taste-testing, experimenting and adjusting. [/SIZE][I][SIZE=15px]Then[/SIZE][/I][SIZE=15px] I put it in the oven to bake it and deliver to the waiting diners.[/SIZE]

[B][SIZE=15px]Delight is an over-delivery on expectations[/SIZE][/B]

[SIZE=15px]I’m an advocate of experimentation and new approaches, but I don’t believe [/SIZE][I]delight[/I][SIZE=15px] can be properly considered before [/SIZE][I]fundamental usability[/I][SIZE=15px]. When pushing design boundaries we redefine experiences and thus ultimately change behaviour. Matt already recognises this in his story about Google Maps going above and beyond with the voice of Mrs Google, so it should be easy to help him make the rest of the connection; at the time he experienced the ‘driving directions’ feature it added an entirely new dimension. However, after his expectations changed, this cherry became essential functionality. This demonstrates how tomorrow’s cherries are an extension of today’s expected and usable functionality.[/SIZE]

[SIZE=15px]Becoming a connoisseur of something often means you expect more and notice subtle differences that other people may miss. We’re all becoming connoisseurs of a particular experience when we use it, and thus our experience-noses are becoming better attuned to the benefits that a particular delight opens up to us.

As with the quote from Aaron Walters, aspiring only to create something usable is like a chef aspiring to create something edible. A truly fine dining experience is not only getting the basics right, but also considering emotion in a way that can help define that experience. Delight comes in when [/SIZE]Heston Blumenthal[SIZE=15px] understands these basics and uses them to take dishes to an entirely new level, to extend and expand on basic edibility in astonishing ways, to over-deliver on expectations. His experimentation comes through understanding the science of [/SIZE][URL=“”]molecular gastronomy[SIZE=15px] - what happens chemically when certain foods combine or cook. Note that molecular gastronomy is also known as ‘avante-garde cuisine’, ‘emotional cuisine’, or ‘the forward-thinking movement’. See how this grounding in an understanding of science is not mutually exclusive with delight? In fact, see how it [I]accentuates[/I] delight? Our understanding of usability can also propel us to the cutting-edge of delight and emotional design in our projects. [/SIZE]

[B][SIZE=15px]During ideation, ‘Delight’ is not the same as ‘creativity’[/SIZE][/B]

[SIZE=15px]It’s an important difference. The refinement vs exploration diagram Matt linked to cannot be used for his argument. Refinement and exploration are two approaches commonly used together consecutively to consolidate ideas or explode potential within a single project, as Matt even mentioned himself when he said:[/SIZE] [INDENT][I][SIZE=14px]"… a path that is so crazy that it would be impossible to make it useable. But that’s when we need to refine."[/SIZE][/I][/INDENT] [SIZE=15px]Refinement is an essential part of the user-centred design process, and exploration is essential for identifying user needs (and wants) as anyone who has done design work based on user research will know well. [/SIZE]

[B][SIZE=15px]Finesse is not optional for master chefs[/SIZE][/B]

[SIZE=15px]Examining all the masters who practice finesse, you’ll see that delight is what makes the difference. Sure, cherries are not essential for cakes, but when you’re a master chef aiming to create a heavenly dish with humour and emotional resonance, the presentation and delight created by that Kirsh-injected, microwaved cherry on a square of almond, with a caterpillar of stabilised egg-white are a critical point of difference. I challenge you to find a master chef that lets a dish out of their kitchen as a plain sponge, or without the garnish and that cherry looking just right.[/SIZE]

[SIZE=15px]Matt has swerved into agreement with my argument when he claims that:[/SIZE] [INDENT][SIZE=14px][I]“true delight comes from wowing users by solving their problem in an innovative way”[/I][/SIZE][/INDENT] [SIZE=15px]Although, it is more accurate when reworded as:[/SIZE] [INDENT][SIZE=14px][I]“true delight comes from wowing users with a usable solution that solves their problem in an innovative way.”[/I][/SIZE][/INDENT] [SIZE=15px]After all, speed, context and new features are all aimed at improving usability first, not delight. Delight is the emotion induced when we deliver above and beyond. Delight is therefore an over-delivery of usability, and thus can’t exist without a strong foundation in it. Our master chef Heston has finesse because he understands how human senses work, and has experimented with new ideas to connect these in new ways. He has an excellent awareness of usability that forms the basis of his thinking. [/SIZE]

[B][SIZE=15px]Usability is the mother of invention[/SIZE][/B]

[SIZE=15px]Throughout history, many noble inventions have come about through necessity - through addressing a usability need. They are a sheer delight because they improve the fundamental experience. My concerns with Matt’s approach are that designers and businesses will attempt to artificially create delight for the sake of marketing without first understanding the context. They’ll be the crazy, aspiring kitchen hands and apprentices that flail about at random, sometimes chancing upon a delightful creation. But they’ll never be able to cleverly and consistently deliver a fresh dish with delight and finesse unless they’ve taken the time (like the master chefs) to learn usability through the mistakes of others, to understand the potential of their ingredients, the intricacies of human senses, of atmosphere and the importance of presentation.

Usability must be understood, and form the foundation of a project, before delight is possible.[/SIZE]


This is more awesome than I ever imagined that it would be. I hope that I haven’t orchestrated the destruction of my own workplace!

So people, I think it’s time that we started heckling. Which way are you swaying?


Hmmm. Luke and I seem to be disagreeing over the definition of the terms we’re debating.

Of course, it’s to be expected. Luke is reinterpreting what delight and usability mean to him on purpose, to avoid having to backtrack and admit that I’ve got him in the corner. He’s hoping you’ll go along with his assertion that delight is merely a flashy extra that can be sprinkled on at the end.

So first thing’s first: let’s clear that up for him. Luke, my friend, I hate to break it to you, but:

[B]Delight is not a feature—it’s an emotion.[/B]

Delight is [I]not[/I] something that you or anyone finds pleasurable. Delight is[I] the pleasure itself[/I]. It lives in your users, not in your product.

The distinction is important because delight is more than “an over-delivery of usability”. To state that delight “can’t exist without a strong foundation in (usability)” doesn’t reveal the entire story—more accurate would be the statement that “time spent making a solution usable is time wasted if it’s not the [I]best[/I] solution”. The best solution [B]is[/B] one that delights, and the number of things we may take delight in are not limited to the superficial examples that Luke conveniently listed in his opening statement. Contrary to his assertions, delight may indeed be derived from an appreciation of the creativity behind a solution; or the degree that it speaks to the user’s psychological needs, or core functionality such as Mrs Google’s driving directions (which, incidentally, I still find delight in to this day). And yes, delight may even be derived from something that is wonderfully usable. But that doesn’t mean we should [I]start[/I] there—it just means that we shouldn’t compromise on usability when it comes time to considering it as an important factor.

[B]Process, Not Priorities[/B]

Luke suggests that I’m claiming usability and innovation to be mutually exclusive. He tried this last time when he attempted to steer us all away from the topic of “Which should we consider first?” and towards the very different argument of “Which is more important?” and he’s doing it again with the preposterous metaphor of an aspiring kitchen hand, flailing around at random. As I mentioned last time, we’ve already agreed that usability should never be compromised.

A more accurate metaphor (and I’m repeating myself here, which tells me that Luke found it a difficult position to combat so he conveniently chose to ignore it) would be the master chef who has indeed learned usability through the mistakes of others, and yes, who understands the potential of the ingredients in front of him and the intricacies and all of that metaphorical guff that Luke is trying to bamboozle us with. But before he begins baking, he questions whether a cake is indeed the best solution for the problem he’s been tasked with solving. Sure, he could serve up a wonderful cake, with a cherry on top and all of the finesse that he’s learned over the years. But how does he know that his customers are hungry? Or what they feel like?

[B]What is user research for?[/B]

Luke dismissed my last supporting diagram with the statement “it cannot be used for his argument”. He’s hoping that by putting this out there with an air of authority, it won’t be questioned. Apparently he thinks he’s both contestant [I]and[/I] referee. Unfortunately, he also stated that:

[SIZE=15px]Refinement is an essential part of the user-centred design process, and exploration is essential for identifying user needs (and wants) as anyone who has done design work based on user research will know well. [/SIZE]

Exactly, Luke. I couldn’t have said it better myself. But what is it that you’re hoping to achieve during that research phase? The goal is to identify user needs and wants. You know—those things that make them happy. That [B]delight[/B] them, even.

Contrary to his dismissive statement, the refinement/exploration diagram is indeed relevant here. It’s central to the argument, in fact. Luke is trying to align himself in your mind with the phrase “user-centred design process”, thereby implying that mine relates to some other inferior process. It’s pretty underhanded, but I know you’re all too smart and can see right through it. Aside from the fact that his point only reinforces my argument, what he doesn’t admit is that the exploration phase requires one to cast one’s assumptions aside—including those pertaining to usability. I’m sure many of you have participated in brainstorming sessions where you are told that during that session “there are no bad ideas”. This is no different.

Perhaps he’ll take this diagram more seriously:
My argument is that C, the best solution for the design problem at hand, is easier to arrive at from A than it is from B, because the path from A to C utilises more mature processes, techniques and principles. Usability is a mature discipline, and can be applied here to refine our proposed solution until we have arrived at a design that is both usable [I]and[/I] delightful. Sure, A is harder to get to in the first place than B, because it requires more creative thinking and user research. But unlike usability, the rules on how we create delight are much less tangible. Sure, those superficial examples that Luke listed—page curls and other cute transitions—are reasonably straightforward to add on. But how do you know there’s not a truly innovative, killer idea sitting out there in left field, if you haven’t considered all possibilities? Those superficial delight add-ons will only get you so far. By considering usability first, you’re unfortunately cutting a section of the solution space out of the equation.

When your creativity knows no bounds, however, you’re free to throw the wildest depths of your imagination on the board and see what sticks. If you find something that shows promise, then the process is reasonably straightforward. But making the leap from usable to delightful is never as straightforward (unless all you’re aiming for is sprinkles and cherries). If the best solution turns out to be a 2-metre croquembouche, then starting with “let’s bake a cake using all of my expert skills” isn’t going to cut it.

[B]A real-world example[/B]

Now, I don’t know about you, but I’m feeling like this cake metaphor has been stretched a tad beyond its expiry date. It might be convenient for Luke to draw parallels that suit his argument, but it’s not really a very practical metaphor.

Instead let’s take everyone’s design poster child—Apple.

If Apple had approached the portable music player industry with a “usable first” mindset, they probably would have invented a portable CD player that had a more intuitive series of buttons. Sure, it would probably have been a great CD player. It would have looked great. And it would have been perfectly useable. But they wouldn’t have invented an iPod.

Instead they tackled the problem free of constraints. They asked “what if?” They put crazy ideas up for consideration—storing thousands of songs in your pocket; no moving parts; white instead of grey or black; and an online ecosystem that completely disrupted music sales—and then made sure that the output of this constraint-free thinking was wonderfully usable (well, the iTunes desktop app could still do with some improving!). No user research participants told them “Gee, I wish I could carry around my entire CD library with me”. As per Luke’s helpful quote from someone who wasn’t Henry Ford, it wasn’t Apple’s users who were begging for the iPod. Before the iPod, we didn’t realise such a thing was possible, and now we can’t imagine a world without it.

[B]Usability is not the mother of invention—user research is.[/B]

In closing, usability must be applied to the [B]right[/B] problem in order to elicit true delight from our users. By considering delight first, without constraints, we increase our chances of arriving at the best possible solution. Taking a good idea and making it usable is far more likely to produce a better solution than taking a conventional idea and trying to add delight at the end.

Thank you for reading!


But just because something didn’t exist before, does that mean that its first incarnation wasn’t designed primarily with usability in mind? I’m not so sure…

So I think it’s probably time for summation and closing statements, so that you guys can get back to work!



Hey, whose side are you on?! :smiley:


The winning side. Always the winning side.


Phew, meant to comment on this earlier, but took a while to read thru it all, well done guys.
I’m with Matt I think!
A product/service should be useful and usable as a given. Making it delightful is what will set it apart. The delight should be part of the design thinking and focus from the first moment.
Its the best way to make yourself memorable, and standout.


Thanks Hawk (and Matt). I sense that my arguments supporting [I]usability first, then delight[/I] are pretty compelling and self-obvious, but lets recap a few key points in closing and address some of the things Matt has twisted to try and scrape his points across.

[B]Delight is not optional for a good user experience, but it must be founded on usability[/B]

Any successful attempt to add delight to a UX project must first consider usability before it can seek to take engagement to the next level. In this way (and responding to Matt’s stringing-out of the cake metaphor), knowing the people using the cake will help us address usability problems directly related to their context (and yes, that includes whether they’re hungry or not, Matt). [I]Usability first, then delight. [/I]

[B]Usability can arguably survive without delight, but delight cannot survive without usability[/B]

While the best experiences created for a user will contain delight, some websites can still achieve a level of utility without delight - this is historically where we’ve come from. Unfortunately for Matt, the opposite is not true; delight cannot survive without a solid base of usability. The delightful elements themselves would be unusable and ultimately uninspiring.

Usability sets the direction for a solution in a much more appropriate way than if we somehow addressed delight first. Additionally, allowing usability to slip down the priority list would compromise the product when time is tight or the budget is dwindling. That is not the way to run a project! Yes, design iterations and Lean UX mitigate the negative outcomes, but the point is the same; that we must value usability first, and consider it foremost. [I]Usability first, then delight. [/I]

[B]A process founded in usability innovates better than one founded on initially chasing delight [/B]

As I’ve argued in my last few posts, and as even as Matt now claims himself:
[INDENT][I]The goal is to identify user needs and wants. You know—those things that make them happy. That [B]delight[/B][/I][I] them, even.[/I][/INDENT]

Matt seems to have drifted so far off his course that he’s now well and truly arguing my points for me. User needs are synonymous with usability, and the ‘wants’ are identified at the same time during user research. Thus, usability helps us discover and innovate to design for a delightful experience. He’s also leapfrogging me to argue that user research is more a mother of invention than usability. [I]Usability first, then delight.[/I] Thanks Matt!

[B]Matt has mentioned Apple, so it’s time for us to end[/B]

With apologies to a well-known adage, if a UX discussion goes on long enough sooner or later someone will compare something to Apple and ultimately lose credibility.

If Matt had done his homework, he’d see that patents directly related to the iPod design have existed since 1979, but weren’t successful because their delight was too far ahead of the context of the device’s intended users - they tried to put delight before context and usability [I]and it didn’t work[/I]. As Matt says himself:
[INDENT][I]If Apple had approached the portable music player industry with a “usable first” mindset, they probably would have invented a portable CD player.[/I][/INDENT]

While Apple didn’t, others certainly did and CD players were more useful and sold better in the 1980s than any portable digital music player. Apart from correcting Matt about Apple’s over-exaggerated involvement in developing the original iPod (the scroll-wheel hardware, software and firmware came from PortalPlayer, and the system software was based on the [URL=“”]Pixo OS), I couldn’t agree more - the delight of the iPod interface indeed comes from the intuitive usability of the interface, and not because of the circular design’s delight on its own. An excellent example of [I]u[/I][I]sability first, then delight,[/I] and a satisfying way for me to trump Matt and end this debate on an unassailable high note.

I’ve had a lot of fun researching this debate, examining and maturing my own opinions and sharing these points with you all. I’m as convinced about the fundamental priority of usability over delight as I ever was, and it’s obvious there’s a lot to say in favour of making things usable first, and then adding delight (even Matt is overwhelmed by the weight of argument against him).

I hope you’ve got as much out the debate as I have. And if you haven’t, then I’m sure Matt’s slippery shenanigans have kept you well amused!




Nice summation Luke!

I get the feeling that Luke thinks he has this one in the bag, Matt. Here’s the clue:

and a satisfying way for me to trump Matt and end this debate on an unassailable high note.

So Matt, it’s over to you for your closing argument and then I’m going to open a poll.


I agree with Luke on one thing—this has been fun.

[B]But that’s where our agreement ends.[/B]

Some would call me the underdog in this debate, and Luke’s certainly presented a ton of interesting links and amusing metaphors to make his case.

But he’s also had a hard time rebutting the points I’ve raised, regularly contradicting himself in an attempt to play whack-a-mole against entirely valid reasoning. As I’ll demonstrate, unless we embrace delight-driven design, we risk our solution falling short of its potential.

Luke argues that:

Usability can arguably survive without delight, but delight cannot survive without usability

There he goes again, going off on that same tangent, as if we were ever considering the very notion that a delight-driven process would allow usability to “slip down the priority list”. I know you’re all tired of hearing him argue this other topic that we’ve all agreed on anyway. To be frank, I’m finding it a little wearisome as well. I’ve tried to reign him in, but what can I say—dog with a bone…

And while I’d normally reward him for his persistence, he then follows up with this:

Delight is not optional for a good user experience, but it must be founded on usability …

Well, which is it, Luke? Is delight optional, or is it not? Do you believe in striving for a “good enough” solution first, then hoping you’ll be able to improve it later if you have time in your budget by whacking a cherry on top? Or do you think we should take a step back, and consider other, more radical ideas before beginning the process of refining our solution?

[B]This is the crux of where Luke and I disagree. [/B]

He gloats that because I’m championing user research, I’m making his case for him. I guess it depends on how you define usability. How usable something is does not always extend to how well it solves a problem. If someone was to release a brand new portable CD player tomorrow, I’m sure it would be perfectly usable. But it would be far from the best solution. Additionally, as I’ve argued previously, it does not extend to the crazy, out-of-left-field, creative ideas that come to you in the shower because you’ve chosen to throw all constraints out the window, challenge assumptions, and ask “but what if?”. Luke wishes it did, so he could expand the scope under which he’s operating to include the ideation process. He’d probably argue that it’s impossible to have those ideas unless you have a usable (and possibly uninspiring) prototype in place to catapult from; I say sometimes the best ideas come from challenging the status quo. Sure, we might end up throwing some or even all of them away, but at least we considered them.

A process founded in usability innovates better than one founded on initially chasing delight

Hmm, you sure about that? Aside from the fact that it’s not a product that does the innovating, it’s the team behind it, I defer to the diagram I discarded this notion with in my previous post. A product may be perfectly usable, but if it is not useful or delightful, then it’s hard to argue that it’s the best solution. Sure, you may be able to add delight by resorting to superficial interactions, transitions or aesthetic touches. But true innovators challenge the status quo. They don’t look at the competition and ask “what can we change about that product to make it better than the others?”, they ask “What if we redefined the problem?” or " What if we could do [I]magic[/I]?! What would our solution look like then?"

[B]A process that considers delight first is more likely to deliver a solution that delights.[/B]

And if no truly innovative ideas come out of it, we can always fall back on usability principles. They’re always there for us as a solid Plan B.

Before I finish, I can’t resist biting back on this:

… and responding to Matt’s stringing-out of the cake metaphor

Ha! Luke, may I remind you who introduced the blasted metaphor? We’ll let the audience decide who is more guilty of flogging that dead horse!

even Matt is overwhelmed by the weight of argument against him … a satisfying way for me to trump Matt and end this debate on an unassailable high note

Au contraire, dear friend. You mistake my being hesitant to embrace the considerable task of wading through your lengthy ramblings with being overwhelmed.

Unlike Luke, I’m not going to swap the confidence I have in the case I’ve built with arrogance. Instead I’ll leave you with this quote:

“An arrogant man will still feel immortal, even on his death bed.” —[I]Unknown[/I]

Thank you for indulging us.