Sometimes, easy is a bad thing
As designers, we spend lots of time and thought on optimizing our users' experience. One common goal is to save the user's time and effort, to make tasks easy. But, as we all know, easy is hard. There's lots of grunt work and trial-and-error behind an elegant design.
And is ease-of-use always desirable, anyway? Surely, we expect challenges and roadblocks in a good game application. In this genre, "User Experience" arguably has a different set of standards. But a current client has illustrated the need for a judicious amount of user difficulty in the workplace as well.
Her company produces an application designed to create and manage vast amounts of data, with a crucial functionality designed to create reports. In two specific instances, she has advocated for making things a bit hard for the users (initially, at least). First, in the case of creating a report, she specifically cautioned against locating a "Submit" button near the area for selecting a report domain, and instead obliging the users to go through a short series of intermediary screens designed to filter down the selected data. The reason? Users have a tendency to select report criteria that may pull a majority of the database records, possibly resulting in reports that may run well over 10,000 pages. These screens serve as a cognitive intervention, causing a small amount of initial pain in exchange for the consequences of an unconscious and automatic reaction.
In the other instance, our client requested that we make the report function neither too easy nor too difficult, in order to provide clients with a variety of options in creating reports. Clearly, user control trumps a "one size fits all" model of speed.
Of course, gatekeeping should never be oppressive, awkward or frustrating for users. But neither should a taskflow or online process be so stripped down and streamlined that the user is propelled, unthinking, through the process windtunnel.
Comments: 2 so far
Leave a comment
About Pathfinder
Follow the Blog
-
Get a monthly update on best practices for delivering successful software.
Subscribe via email
Subscribe via RSS
Categories
Topics
Archives
- July 2009
- June 2009
- May 2009
- April 2009
- March 2009
- February 2009
- January 2009
- December 2008
- November 2008
- October 2008
- September 2008
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- March 2007
- February 2007
- January 2007
- December 2006
- November 2006
- October 2006
- September 2006
- August 2006
- July 2006
- June 2006
- May 2006
- April 2006
- March 2006
Blogroll
Recent
- Elements of Testing Style
- Aesthetics and Web Design
- Asterisk-Java Testing with Groovy
- 3 Misuses of Code Comments
- Fluently NHibernate
- Digging a Hole and Covering it with Leaves — The Software Development Version
- The Importance of User Experience - Do You Understand It in Your Bones?
- Writing Your Own Protocol With NSURLProtocol
- What’s In Your Dock: iPhone edition
- Feature Fatigue

Yet another story where paying attention to one aspect is inappropriate.
Keeping things simple, easy user experience, only write what you need. All these are typical short-term objectives that may obfuscate long-term issues.
For many little applications this may be of no concern but these ‘agile’ techniques are used more and more on big applications with lots of complexity that arguably can’t be handled efficiently with simple strategies.
Agile techniques are very useful but I haven’t encountered ways of working yet that take Eric Evans’ “approach to design” cause for complexity into account.
Comment by Steven Devijver, Wednesday, July 19, 2006 @ 6:06 pm
Talking about “user experience”, it would be nice if a redirect would be issued after submitting a post to this blog.
Avoids the infamous brower repost popup box.
Comment by Steven Devijver, Wednesday, July 19, 2006 @ 6:09 pm