Members Only Logo  

or Subscribe by Email by entering your address below:

Powered by FeedBlitz
Learn about Subscriptions Follow me on Twitter!

The topics discussed here grow out of the bread-and-butter issues that confront my consulting and software clients on a daily basis. We'll talk about prosaic stuff like Membership Management, Meetings and Events Management and Fundraising, broader ideas like security and software project management, and the social, cultural, and organizational issues that impact IT decision-making.

Wednesday, March 14, 2007

Navigating complexity

Maybe I'm just thinking out loud here. In the last post I mused about the complexity of striving for simplicity in design. For every effort to simplify, you discover you have made another user's life more complicated.

Usability means several things.Tasks should be easy to learn, quick to complete, and hard to screw up. Data displays should be complete, uncluttered, and easy to comprehend. But even these straightforward goals can work against each other. Do we show less information on a page to make it easier to read, or do we show more, so users do not need to click or scroll? The jury is always out on this one - we once recieved an email asking us to use a larger font, allow more white space, and add several columns of information to a particular display.

At the heart of the problem are the complex business requirements that organizations create. I've written before about the importance of weeding out needless complexity. But non-profit staff can only go so far in eliminating requirements from government, insurers, the board, and the ultimately the nature of their work itself. So the software designer's task is to mask or conceal this complexity.

Here are some of the trade-offs I've run into as we work with our users to make software more usable.

Design Approach
It's simple because
It's not simple because
Context sensitivity: only show inputs and options when they apply.
The user does not find herself clicking buttons only to get a message like "You cannot Place a Hat on this Zebra" . In situations where zebra's do not wear hats, the button is hidden. For sessions where transporation is unavailable, the transportation link is hidden.

Users are never sure when a menu choice or option will appear. "There used to be a button for Putting a hat on the Zebra", they report.
The WIZARD Approach: have users perform tasks through a series of simple forms that step them linearly through the process.
Little or no training is required. The stripped down dialogs on each page come with instructions and are not threatening to the user.
Getting through the process requires many clicks. Worse, making a mistake requires the the user to click BACK repeatedly to find the page where the correction can be made. So work is taking twice as long.

NOVICE and EXPERT forms: Have stripped down pages for users performing simpler tasks and more complex pages for the advanced users.
Everyone wins. The simplified pages require no training, and allow less skilled users to perform a majority of possible tasks. The Expert pages provide access to all capabilities.

Everyone prefers the simplified pages but are constantly frustrated that the one other capability they need is not there.
User configuration: Let users configure the capabilities and elements available on their view of complex forms.
This is even better. Each user gets exactly what they need and no more.
This is even worse. Users need to learn how to configure the pages. Users remove items from their page they actually need. Support staff find their life has been complicated because each user is looking at a different page.

Strict Enforcement. Make it virtually impossible for the user to make a mistake by building in rules to enforce all data entry and setup requirements. If each customer MUST have a date of birth, for example, require it to be filled in for the form to be saved.
Users do not need to know all the decisions of management about data requirements. The system will enforce the rules and pop up messages to tell you what you need. It's what computers are for!
No one can get their work done. The system is constantly complaining that they cannot use this membertype or you must enter an employer. People are entering 01/01/2000 for everyone's birthday. The data is in terrible shape because people are forced to work around the system.

It seems no design idea is a panacea. Each must be employed judiciously as users and developers navigate the seas of complexity.

Labels: , ,

Comments on "Navigating complexity"


Anonymous Anonymous said ... (March 14, 2007 at 12:42 PM) : 

I think you're right on here, most design is a matter of making the right tradeoffs. And it's worth saying, because sometimes clients (and colleagues) aren't thinking about what they're giving up when they push for a particular approach.

But I think there are often ways to reduce the downside. In several of your examples, if the "not simple" is a problem, it can be ameliorated somewhat by making the "simple" less strictly so.

For example, the last one on your list, enforcement. The "it's so strict I can't move on with my work, and I don't have the info it's demanding" is a real common problem. So a good compromise might be: rather than demand the data absolutely, the system can use messaging, reports & modeless feedback to make sure that users are aware of incompleteness, but let them move on for now and come back to it later. In an app I'm working on now, I use a checkbox-in-a-circle graphic to indicate when a record is complete, and an empty circle when it's not. Users can hover over the circle to get a tooltip detailing what's missing.

Same with context sensitivity: if disappearing elements are a problem, you could visually indicate them as disabled rather than removing them entirely.

I guess I'm just saying: in many instances there are ways to compromise.


Blogger Dan said ... (September 24, 2007 at 12:19 PM) : 

Interesting stuff - lots of good things to think about here.

You might get a kick out of a little design book I wrote, titled The Simplicity Cycle. It's available as a free preview / download at

I describe it as a graphical exploration of the relationship between complexity, goodness and time. I'd love to hear what you think of it - hope you find it useful!


post a comment