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!