Joy and pain in ux design
I vividly remember sitting in a meeting, reviewing the requirements for a new product, and hearing some of the most beautiful words I’d ever heard, “I think whatever promotes the most joy of use should be what we do.” I think my heart skipped a beat hearing this sentiment coming from a senior technology executive who was steeped in code and the rigors of enterprise software development. Of course my heart about stopped when he promptly turned to me and asked me what specifically we needed to do to make a certain new functional requirement more joyous to use.
At the time, I couldn’t answer this question. Sure there are numerous heuristics we considered but no one could tell me much about the people who would be using the functionality. What we did know about these people was mostly conjecture. We really didn’t know what the motivation for using this functionality would be or, to be perfectly honest, if it was even needed. I like how NN/g describes where joy of use comes from:
… The first requirement for an exemplary user experience is to meet the exact needs of the customer, without fuss or bother. Next comes simplicity and elegance that produce products that are a joy to own, a joy to use. True user experience goes far beyond giving customers what they say they want, or providing checklist features…
So first we needed to understand the people who would be using, and paying, for this functionality and what they ultimately needed to get out of it. After that understanding had been developed we were then able to craft an appropriate solution. When tested with our customers, we didn’t hear any negative feedback with regard to the functionality in question.
If the formula for creating joy of use is pairing people’s needs with simplicity and elegance, where does pain come into play? Not the kind of pain I felt when I was put on the spot in front of 20 people but the pain we as ux designers inflict on the people who use our products. I’m probably going to be chided for saying this but I don’t think all pain in ux design is bad. Bear with me and let me explain what I mean by this.
In designing a wizard for this product, it had next, previous, and cancel navigation elements that are fairly common for these controls. The number of steps varied from five to seven depending on your selections. I started off the design to facilitate someone easily navigating between steps or canceling the entire process:
Initially this made sense but after creating and testing the prototype, I revised it:
People were having to work harder to get to the “Next” button, the primary action, due to placement. By swapping it with the “Previous” button, their eyes didn’t have to break the line of site they were already conditioned to due to form field placement. Also, they didn’t have to move their cursor further to hit the “Next” button.
But after removing this pain point, I discovered an opportunity to actually introduce pain:
I did this to make it harder to click the cancel button. I think this pain was necessary to help prevent someone from accidentally canceling the lengthy process. I also think that since it takes longer to hit the “Cancel” button, it provided a little more time to think about this decision.
Perhaps I’m being melodramatic by using the word pain but I do think these types of decisions have an impact on whether a product is perceived as being simple or elegant. While I don’t like to intentionally introduce pain, as my mother said several times, “this is going to hurt me more than it does you.”
I believe by applying this technique we can actually improve the user experience. Hopefully, when combined with the rest of the formula, this will ultimately lead to joy of use.
May 1st, 2008 at 1:49 pm
I think that in this instance you have still reduced pain by clarifying the actions the user is taking. While, yes, they have to move their mouse further to cancel, its not painful. What would be painful would be inadvertently clicking cancel while only wanting previous.
There is something to the relationship of pain and learning. It like touching a hot stove. You don’t know how much it hurts and not to do it until it burns you.
May 1st, 2008 at 4:07 pm
Saving the user from a major mistake is a feature, even if it’s a little painful.
What you did there is use Fitts’ Law to your advantage. By increasing the distance to the link, you increased the time it takes to implement a major decision.
I personally like to place constraints on software in these sorts of situations. Our ability to know to do so is what separates us from the programmers. (that and a few chromosomes)
May 12th, 2008 at 1:46 pm
There seems to be a push to leave the Cancel button off completely. Personally, I’m not a big fan of that.
I first seriously dealt with this issue many years ago when I was building the UI for a CRM Web app. Buttons aren’t just actions, they are also forms of navigation. You can even reduce that down even more to left/right and negative/positive.
Using the reduction of what multiple buttons do and reading research on the subject, I implemented a button layout that mimicked the browser functionality – which just so happens to somewhat mimic how Macs work. That meant putting the Cancel and Back button to the left of a form and putting the OK, Submit and Next button on the right side.
That of course confuses Windows users who expect the Save button to be on the far left, but it’s more consistent with the Web and how a browser works. So my argument was even if it wasn’t consistent with what the largest user base expected, it was consistent with the platform – the Internet. I also argued that Web applications should be treated differently than OS-based applications and that they should always mimic the platform.
May 12th, 2008 at 11:23 pm
We explored automatically saving these settings as drafts, in case someone abandoned the wizard, so we definitely considering not having a cancel button. In the end, mostly due to technical constraints, we decided to let this specific choice be user-initiated so we included the cancel button.
I went back and forth re: primary button placement. I have noticed the trend lately is lower right but at the time, given the platform was Windows only, this seemed like the right choice. However, the lower right choice is backed up by research done by Jared Spool (I can’t find a link but thanks to Christina for providing the info). You’re definitely in good company with that decision.