Practical ASP.NET

'U' Scream, 'I' Scream: A UI Rant

Set aside ASP.NET for now. Let's talk about the most fundamental error developers make in designing their site's user interface.

What has constantly amazed me in all my Internet wanderings is how many Web sites seem designed to punish the people using them. The problems aren't restricted to ASP.NET sites, of course, but I'm not going to pass up the opportunity this column gives me to vent some spleen.

The First Rule
The one criteria that a good UI needs to meet is simple: The user must always know what to do next. I've heard that phrased as "Don't make me think!" but it would be more accurate to say, "Don't force me to waste what little time I have on this earth figuring out your user interface."

If you want to ensure that your user always knows what to do next, then you have to know what your user wants to do. You may think you're already doing that. You're wrong. I bet what you're doing is building a UI to get the user to do what you want them to do.

No, it's not the same thing.

Let me give you an example: Do you have a button on a page with a caption that says "Submit"? Think about it. Do your users want to submit? Probably not. Do you want your users to submit? Probably (at least the cute ones).

I've discussed this caption with multiple developers and it's amazing how many of them can't imagine any other caption to put on the button. "After all," they say, "the user is going to submit their page, aren't they?" No, the user is not going to submit their page.

Ask your users if they're going to submit a page. They'll say, no, they're going to save their data, or process their order, or update their profile, or post this year's sales, or do any one of a million things other than "submit" to you or anyone else.

From the Trivial to the Extreme
That devil is in the details, and it exhibits a fundamental mistake -- the failure to learn what the user is doing and building the UI to support that. Sometimes it's not just a button but the whole page that's wrong.

Time after time, I've had developers show me a page and say, "A user can do anything they want on this page." The problem is that a user doesn't want to do "anything." When a user opens a page on your site, they want to do just one specific thing and then go on with the rest of their lives. If you create a page that does "anything," then you can't provide your user with a page that walks them through that one specific thing the user wants. Not surprisingly, when faced with a "do anything" page, the user invariably flounders around trying to figure out how to achieve their goal and, in the end, gives up and calls the help desk.

The answer is to figure out each different thing that your user wants to do and build a separate page for each of those things. A page centered on what the user wants can provide them with support and direction. Of course, to develop those pages, you'll have to figure out all the different things that your user wants to do.

And if that sounds like more work than you want to do, I don't really have a problem with that. After all, I make a good part of my living writing user manuals.

About the Author

Peter Vogel is a system architect and principal in PH&V Information Services. PH&V provides full-stack consulting from UX design through object modeling to database design. Peter tweets about his VSM columns with the hashtag #vogelarticles. His blog posts on user experience design can be found at http://blog.learningtree.com/tag/ui/.

comments powered by Disqus
Upcoming Events

.NET Insight

Sign up for our newsletter.

I agree to this site's Privacy Policy.