Ask Eric: Questions & Answers

December 12, 2002 – submitted by Wanda Richards of IBM

Eric's response: I am delighted to find IBM moving in this direction. There were long years when IBM kept trying to make 'object-oriented' interfaces. These made sense to technical people, but were almost always a poor match to the requirements for a good interface structure.

The idea of a task-based interface structure is so central and fundamental to good interface design that I cannot recall a study that specifically tests it. I did a demonstration that I used for years in class called the pain machine. It had an instruction that was logical and object-oriented (which took an average of about 13 minutes) and a task-oriented interface (taking 3 minutes). That kind of difference would not be uncommon.

In general I would say you can easily compare the logical vs. task-oriented structure by preparing a list of representative tasks and modeling the effort to complete each task in each of the structures. You will find the task-oriented structure has fewer mouse clicks, less mouse movement, less keying, and also less complexity.

December 10, 2002 – submitted by Robert Noyes of Puerto Rico

Question: Do you have any information on the affect of changing a free-access site to a registration-required site? Does this change cause loyal visitors to abandon the use of your site, or does it turn away potential new visitors?

Eric's response: There are few circumstances where we would expect registration to be a positive and reinforcing experience. As such it will always reduce the likelihood of customers joining or using the site. Where it is required there must be sufficient positive reinforcement to motivate the registration.

Think about it like the Columbia Obstruction Device. There is a single alley maze. At one end is a hungry rat (your customer), and in the middle of the maze is an electric grid (your registration form). You need a big enough piece of cheese at the other end to draw the rat over the grid.

September 9, 2002 – submitted by Sharon Merritt of USA

Question: Does advertising the impending redesign of a site improve or diminish the user experience?

Eric's response: Advertising a site redesign can get customers to come and look at the redesign. If the site was bad and turned off customers, some may come back from the advertising. HOWEVER, advertising the redesign also increases user expectations (unless of course you tell them you made it worse). Therefore the perceived user experience may be LESS positive due to advertising that raises expectations.

If the marketing department wants to use the redesign as a selling proposition that is a fine decision. But that puts an even greater burden on the usability design work. It is a bit like sites that say "This is easy" and are horribly complex. If you are advertising increased usability, it better be VERY much increased.

July 1, 2002 – submitted by Robi Ray of Mumbai, India

Question: Our site deals with the following practices: Application Development, Sybase & NAI support & OneWorld. How to reengineer our site in all terms so as to increase traffic? Kindly advise.

Eric's response: There are several different ways to increase traffic. The first is to get users TO the site. This means different types of advertising. It also means designing the site for search engine dominance. Be sure you are registered with the search engines. Be sure you have good meta tags, with appropriate keywords.

Once users are on your site there is a clear dynamic of value vs. pain. If your site gives a lot of value and is easy to use they will use the site, come back often, and tell their friends. Be sure your site gives real, practical value. Also be sure your site applies current usability principles of structure, wording, layout, color, graphics, and control usage.

Today, most useful sites are in some way dynamic. The type of site you describe cries out for increased interactivity and community. This does NOT mean making a button called "Community". But it does mean adding a bulletin board, chat, newsletter, Web cast, and other types of capabilities that draw users in and let them interact with each other.

March 20, 2002 – submitted by Erwin Van Trier of Plano,TX

Question: A decade ago my company used command line interfaces for operator input. A plan was made to replace the command line interface by GUIs.

As a first step some research was done to determine the profile of the operator that would be using these GUIs. At the time we had 2 big customers, a Belgian and a German telecom company.

The German customer wanted to reduce cost and planned to have employees with lower skills to execute the GUIs. The Belgian customer however stuck to the plan to have technical experts to execute these GUIs. As a result we had 2 types of GUIs: full functional GUIs and 'auto'-GUIs (being nothing more than a nice representation of the parameters for the command line ).

The full functional GUIs seemed to be the right choice from a usability perspective but also VERY expensive. The auto-GUIs could be generated by an automation tool and became very cheap.

As a result we delivered software packages having both kind of GUIs that resulted in 'NO CONSISTENCY'.

How should this problem have been handled at the start ?

How do we handle it now ?

Eric's response: It is interesting that you refer to the 'Auto' interface as cheap. It may have been cheap in hardware and software. But if it is poor in usability you will find training costs and performance decrements quickly add up to make that design VERY expensive.

Without knowing the task I am actually not sure if the command interface is in fact a usability problem. There are tasks best handled by commands. These are generally random in sequence and completed by full time users (which is likely to be true for both your customers). So take a hard look. Do you really know the command design is bad?

One solution that is common is to have both a GUI facility and a command capability combined. This can be done in a way that is consistent and efficient.

In the initial design process there is a real issue about the number of versions of a design that should be made. You had two different populations. SHOULD there be just one interface? There are many considerations that effect this including the cost of multiple interface designs and the potential benefit for the users. The only solution to this is based on good analysis of the business imperatives and the user needs.

Now that you have these two designs, with the resulting inconsistency; consider combining the two into a single coherent interface. It can allow users to select the mode they are most comfortable with.

February 2, 2002 – submitted by Dan Grubbs of Virginia Beach, VA

Question: I have been through several frustrating iterations with a customer regarding explaining our high-level design for the system he has asked us to develop. The first approach was to explain a Model-View-Controller approach which, at the time, seemed to be OK. Later, with a new 'player' on the team, this was suddenly confusing and yet another design approach/diagram/discussion was done. Again, that appeared to be accepted but I'm not sure this time due to the history to date (many details left out here, of course). Is there some fundamental guidance or example of how Software Engineers can reliably and successfully explain a complex system design in terms a layman can understand?

Eric's response: There is a science, art, and process of creating interface structures that can be understood by a target user population. This is one of the 'high arts' of the usability engineering field. But your question sounds like a different problem. It sounds like you are trying to satisfy a 'customer' who is NOT the user and who keeps changing.

The Schaffer Method™ has a 'contract for design'. It is a document that identifies who the real users are and what their taskflow should be. It identifies the human experience and performance objectives. With this agreed to by all stakeholders, the design should NOT be a function of making a 'customer' happy. It should be about getting successful numbers in the objective testing of the interface. If you created a structure that users do not understand in the usability test... it does not matter if the customer loves it... you need to do some serious rework.

January 4, 2002 – submitted anonymously

Question: Hi Eric – thank you for providing this forum, and thanks for all the helpful information you have on your site. A little background first: Our Intranet originally started out as most others did, as a decentralized, grassroots project where each department did their own thing. We have since managed to morph into a second generation intranet, with a template, publishing standards based on proven usability techniques, etc. However, we are still very much a decentralized operation – each department is responsible for providing its own publishing support. Therefore, we find ourselves struggling on a daily basis to maintain the standards we've set.

Question 1a: Since we do not have direct control over our publishers (if it came down to it, we could always refuse to publish their content, but that makes for a PR nightmare), what is a good method of educating them about the why's and wherefores of sticking with the template? Most have no experience with usability and have no idea what it is.

Question 1b: Is it absolutely vital that no one deviate from the template in any way, e.g. color changes, font face changes?

Question 2: Another holdover from the first generation is that our publishers often link to documents (Word, PowerPoint, etc.), not for users to download, but for them to read as they would other HTML pages. What is your advice on this practice?

Thank you for any advice you can give.

Eric's response: Question 1a:
Be proactive in supporting your standard. A policing action may be useful, but it is FAR better to avert the problems before they arise. Give designers training in the standard. We almost always deliver a half day customized class with every standard we build. Also give them training in usability. You may not be able to justify a 3-day course. In this case, we have used a half-day course "The Basics of Web Usability" to good effect. This at least acquaints the designers with the usability issues.

Provide tool support for your standard. If designers and developers have reusable code or a content management system template, they must work to violate the standard. Also, provide consultative support. Help the designers to work with the standard.

Question 1b:
Part of the art of doing good standards work is knowing what NOT to standardize. Many of the items you listed should probably NOT be standards. In addition, using a standard well is a little like having a good jazz theme. You use the standard but then improvise well around it. Be aware that no standard should ever try to standardize more then about 85% of pages that will be designed.

Question 2:
Word and PowerPoint are not terribly good Web page generation tools. This is a quick and dirty approach that is only appropriate where there are very few users and the stakes of the site are very low.