steve kwan user experience designer

The pitfalls of generic UI components

(October 6th, 2008 - 5:05PM)

We're in the process of redesigning protectedpdf, a product that hasn't had a UI refresh in several years. We're rebuilding the UI using Microsoft SharePoint. During prototyping, an interesting issue came up that I thought I'd share here.

Microsoft SharePoint, like many application platforms, comes with a library of generic UI components: list views, data grids, entry forms, etc. Also like many application platforms, these pre-made components suck. Although ready-made components save time, they're invariably too generic.

Since thousands of developers use SharePoint, Microsoft needs to ensure that its UI components are generic enough to accomodate the nearly unlimited number of ways they could be used. This means they designed for the lowest common denominator. And while these "lowest common denominator" components can do thousands of different jobs, they aren't designed to do any of them particularly well.

Of course, developers love generic UI components because they greatly speed up development time. Developers hate nothing more than reinventing the wheel. When prototyping protectedpdf, our development team encouraged me to use SharePoint's generic components wherever possible.

But after a few days of prototyping, it became clear that bending my design around these generic components would result in a hard-to-use application. I wouldn't be building something intuitive; I'd be stacking together a pile of generic components.

Have you ever used an application that felt like an endless assortment of lists and forms, all tenuously linked together? That's not good design. A well-designed application should feel smooth and continuous when used. It should clearly navigate your users through their goals.

A lot of developers make mistake the mistake of thinking like this:

"I'm building a course registration system for a school. Well, the major entities are the course, the student, and the registration, so I'll just use generic lists and entry forms for each. Done!"

Unfortunately, the ubiquity of generic UI components makes it easy to create systems like this one.

The problem is, this is a data-oriented view of the universe, whereas most users think in a goal-oriented view. When you present someone with a kludge of lists and forms, they often don't understand where to start or what to do. In fact, almost all badly-designed UI I've seen has this commonality: the application is basically a pile of generic list vies and entry forms.

So let's wrap all this up into a single thesis: Generic UI has no notion of your user's goals. It encourages you to build a data-oriented system. Most users prefer a goal-oriented system.

Canadian "Do Not Call" List

(October 3rd, 2008 - 4:49PM)

Now, like our American neighbours, we have a national "Do Not Call" list. I'm not sure how well it'll work, but I recommend all Canadians register.

www.dncl.gc.ca