Reams of advice have been written about how to design a highly usable user interface for software products. There are experts who have devoted their entire careers to this subject.

Far be it from me to try to compete with this body of knowledge. However, as a Product Manager, I have usually found myself in a situation where hiring expert user interface and usability design consultants was not an option. And in the rush to put in new functionality, interface improvements wound up as a low priority.

Combine that with the fact that touchy-feely user-centric thinking is not commonplace in the highly technical world of software programmers and engineers, and your product’s interface can suffer.

So today’s topic is offered as simple, basic advice on how to improve your product’s user interface when you don’t have the money and expert resources to do it the perfect way.

Read on for seven pieces of practical advice for improving the user interface.

[private]

Build a UI Review Team

Select a team of people whose job it is to review the interface and set standards. They become the “interface police” who pick apart the screens, debate improvements, and approve them. When a new type of screen comes out (perhaps a new feature calls for a new and different screen design), they review it as development is under way and determine the correct design.

As with all teams, the composition and chemistry are important. You want the teammates to be able to freely debate and discuss the interface. If the Engineering or Development team is small enough (eight people or less), you could consider having the whole department participate.

Include documentation specialists and QA testers. They have lots of good input from the user’s perspective.

If you can participate wearing your Product Manager’s hat, that’s ideal.

With time, the team members will become your own internal experts on interface design specifically for your product.

Set Standards

One of the first tasks, and an ongoing duty for the team, is to set standards for the various types of screens. These standards can start out simple and become more elaborate over time.

Having these standards will save time and guide decisions every time a new button or screen is added.

There may not be time to do much documenting of the standards. This can be minimal, especially if you put the existing standards into place somewhere in the software. In that case, the newly designed screens serve as the documentation.

Fix the Product Gradually

Wouldn’t it be great to rework all the screens following the new standards? But you may not have the luxury to redo the whole product at the expense of new capabilities that keep you up there with your competition.

Put the new design into place on modules or areas of functionality as they need to be enhanced or modified. With each release, implement the standards in additional areas, and before you know it the entire interface is redesigned.

Create Screen Templates

Whether you can actually create mechanisms in the code that serve as templates for screen design depends upon your product’s architecture. But at a minimum, you can build a library of reusable code that programmers can turn to as a starting point for new screens, buttons, and menus.

If your product uses something equivalent to Cascading Style Sheets or screen templates, make sure the standard designs are built as templates for easy use and reuse. As standards evolve, be sure to change the templates first as part of the effort to change the screens.

With a true template structure, changes to the template are all you need to make in order to change multiple screens.

Give Customers a Choice

You would want to provide this feature only if the code for your product allows for a reasonably simple solution. Provide three to five different look-and-feel templates that can be selected by an administrative user, to give the customer a sense of control over how the interface looks.

Sometimes it’s just a matter a couple different colors to make users at a company more comfortable with a product, because it looks more like their other applications.

Explain It Right On the Screen

When you find that the team is going round and round about the right name for a button or menu selection, because it’s just too hard to make it’s use clear with just a word or two, or the only applicable terms are ambiguous, or the user population is evenly split about which term to use, perhaps it’s time to write an explanation.

But not an explanation in a user guide or on a help screen. Write the help right there, in as few words as possible, right by the fields.

For example, under the Close buttons, write Click Close to save changes and exit. No more endless arguments about the merits of Close vs. Save and Close vs. Save and Exit vs. Done.

Another good example I just saw on a progress screen that appears while a report is being generated: “The report will continue running in the background if you leave this screen to continue working.” You can just imagine the number of times the simple addition of this form of user documentation, right on the screen, cleared up confusion.

It Never Stops

Setting standards and policing the interface is not a one-time effort. It will continue as long as you change or create screens in the product or as new standards arise in the industry. But with clear standards that reflect your product’s industry, users, and technology, a consistent and highly usable interface is within reach. Even when your company doesn’t have a lot of time or money to spend.

Jacques Murphy, Product Management Challenges

ProductManagementChallenges.com
[/private]