Ask Eric: Questions & Answers

Each month Dr. Eric Schaffer answers selected questions on usable interface design.

Ask your question | Archived questions by topic

Here are the most recent questions you asked with Eric's answers.

Question: I have a client who wants:
1. A single landing page site. He insists that it is a long page, around 12,000 pixels which means the user will have to scroll through 16 pages and reach the CTA at the bottom of the page.
2. He wants very heavy graphics with the text. In some places the graphics are bigger and take most of the width of the page and are very distracting. He wants glossy effects, vibrant colors, arrows running around the page etc.
How do I convince him that this is not the best practice?

Eric's response: Well your client seems to want something pretty intensely! It MIGHT be a horrid and unusable experience for the users. But I expect the real desire is for a persuasive interface that will engage users and influence them in their decisions. If that's the case your client might best join me for the next PET design class :)

There are excellent research-based principles that result in user engagement, commitment, and retention. These work wonderfully in online environments. But the approach needs to be careful, systematic, and scientific. It is easy to be hard, hard to be easy, and an even greater piece of work to be persuasive.

Top

Question: What is your view on trouble-shooting online? I refer to a decision-tree pattern (I think that's how it's called) when a user tries to resolve a problem via answering a set of questions, each question is dependant on answers on previous questions, leading to a proposed solution for the problem. Do you think it is a convenient pattern to use? Is it for novice or expert users? If you can refer me to any research/articles on this topic it would be great! Thanks.

Eric's response: Yep. Trouble shooting is generally in a decision tree mode. If you have expert users just go for a tree view where they can quickly see large parts of the tree and scan through it as needed. For novices step them through one point at a time and let the system branch.

Top

Question: How do we get real feedback from users who are using a badly designed application but got used to it so well they couldn't find it bad anymore? When a redesign is initiated from the top management, should we make the application more efficient with proven standards or leave it as is (some parts at least) because users will have a new learning curve or fear abandoning it? Thanks in advance

Eric's response: Interesting question this! If the application is used continuously, the user will learn how to use it. So it will seem to make sense to them. What to do?

Well, you can get new users and test it with them. This will show that it is not easy for new users to learn. This may be important, if you have high turnover. But what you really care most about may be the efficiency of the expert users. They will indeed THINK it makes sense.

But the point is that the design may be PHYSICALLY inefficient. So what we do is to mathematically model the amount of physical work needed to accomplish a basket of tasks with the current design. Then we can contrast this with a potentially better design. We can then show the time saving possible FOR EXPERT USERS.

You also have a concern about switching to a new design when you have expert users who are familiar with a old (bad) design. You must be very careful not to confuse the experienced users with changes to established motor programs. For example, if the users normally hit ENTER to go to the next field, if you make ENTER complete the page they will want to kill you. On the other hand pretty much no one complains about clear error message text. And structural design that improves efficiency significantly will generally get kudos and not knocks.

Top

Question: I am working on a thick-client canvas usability wherein the objects may be about 500-1000 database objects (tables) realistically. Can you throw some light on what features are really useful to the user while dealing with a large number of objects? For example: groupings, navigator (as in photoshop) etc.

Eric's response: The key here is understanding what the user will actually DO with these heavy objects. You must model the user scenarios. So if the user will come with a specific object name in hand, then a search works great. If they don't know the name you might need grouping, or a wizard of logical questions to narrow down the list. As usual in this field, it is about knowing the user.

Top

Question: Eric, I just completed the last of the 4 courses for certification! Looking forward to the exam. I'm leading an internal group tasked with performing a needs analysis for the organization's intranet redesign. I've chosen to build the analysis on two deliverables: 1) The Design Strategy 2) The User Conceptual Model.

My question regards the Design Strategy. I feel that the half-page examples offered in the HFI course book are two broad (vague) for our audience (Sr. Execs, Steering Committee, etc) Yet, I DO NOT want to offer them 20 or 30 pages that get down into the weeds. What's a happy medium for a good Design Strategy? In other words, what average length should the Design Strategy be to gain the most visibility as well and impact? Thanks!

Eric's response: While the wrapper for a design strategy could be 6-7 pages, the core strategy is usually 1-2 visuals. Sometimes it is 5-6 WORDS. The amazing thing about the higher level work is that it must be distilled to its essence, rather than documented in detail. I'm working on our innovation and strategy course and trying to think of how to convey this!

Top

Question: Most recently I have been designing web applications with a lot of form input fields. Usually I align all the action buttons to the bottom right of the page, for example "Save, Cancel, Previous and Next".

I would like to know if the sequence needs to be "Save, Cancel, Previous and Next" or "Previous, Next, Cancel and Save".

Eric's response: There are a number of different approaches to the placement of action buttons. There are design objectives like trying to avoid accidentally hitting "Cancel" and keeping the default button in the same place spatially. But the core question for you is about your UI standards.

Do you HAVE a set of UI standards? I rather gather not, since if you did this question would go away. The most critical thing is to have a set of standards and follow them. Because it's a problem if you have a bad design. But if you have MULTIPLE bad designs then the user cannot really learn and adapt.

So the real objective is to have a GOOD standard!

Top

Question: I am creating a very clean initial interaction "homepage" when a user comes to my site (not launched yet.) I would like to have only a banner-styled graphic as the upper element, a two panel display under that graphic (which exactly spans the width of the graphic) with a short intro and what-we-do narrative on the left and a login/register tool on the right. Underneath that, all I want is a copyright statement.

I do not see any sites out there that do this simplified "welcome mat". Is there a reason why this is a bad design concept?

Thank you for your thoughts!

Eric's response: It is certainly a very poor design indeed! It would seem to work poorly in pretty much every respect.

From the viewpoint of classic usability you are wasting half your screen with a banner.

From the viewpoint of PET (Persuasion, Emotion, and Trust) you are talking about what YOU do, and not what the customer does or wants. Big mistake! You have also put a registration field on the home page. Research clearly shows that this reduces registrations substantially. It is far better to have the customer involved, committed, and having a positive experience. THEN you can ask for a registration.

Top

Question: What is your view on having a welcome note when a user logs into an application?( e.g. Welcome Eric, Thursday, 11th March)

Two additional sub-questions...

1. What if the application is an external facing application? (e.g. Online Banking site)

2. What if the application is internal facing? (e.g. leave application system within an organization)

Thanks in advance!

Eric's response: The welcome message is an interesting issue.

From the viewpoint of classic usability it is clearly a bad idea. It adds unnecessary clutter. The only possible justification is to validate that the user has logged in as him/her self. Not much value there. The date would be valuable only if one expects the user to be temporally disorientated and need the current date.

From the viewpoint of PET (Persuasion, Emotion, and Trust) there is a bit of value for a "Welcome". We find that computers function as social actors. So we expect that people will feel welcomed from the message. But this is a rather weak emotional effect. It would be important to have a more complete and extensive plan for emotional interaction. I'm very much unsure about the value of the date. It is great to give a customer a gift (law of reciprocation) but it seems unlikely that the date will act as a gift...

Top

Question: The delete phase of a CRUD system is destructive in nature. I can see 2 different ways of dealing with this.

1. Ask the user to confirm the delete.
2. Allow the user to undelete.

The first option has the advantage of being more consistent with what the user expects to see (at least on windows systems). On the negative side it interrupts the user and is prone to habituation (i.e. automatic clicking of yes).

The second option has the advantage of being non-intrusive but may mean that the user does not know where to look for the undelete. Also, it is less common to see.

Do you prefer one approach over the other, or is there a third way (perhaps a dialog that can be dismissed forever followed by sending to an undelete folder).

Eric's response: Best practice is to delete without confirmation, and then offer an obvious place to undelete.

The "Are you Sure?" message is only useful for infrequent tasks (as you point out, the user will habituate). For frequent tasks, the question really only helps for accidental actuation.

Top

Question: I hold diversified degrees and multi-industry professional experience as I switched my profession from Industrial banking to HCI. I am MBA(Finance) and MSc. in Analysis, Design & Management of ISs (LSE.UK). In total I have around 4 years of product designing experience in terms of functionality and graphics. I am now wondering if HFI CUA will benefit me in terms of knowledge and enhancing my skills in usability. I am working for a product based company.

Secondly, I'll also appreciate if you could also direct me to some good resources for enhancing my knowledge and skills.

Eric's response: Rubina, you certainly sound like a sharp person with a good foundation in analytic and creative thought. There is no question that the HFI training programs will be useful and that you will be able to manage the content well. Particularly in Pakistan, I think the HFI skills will be a very scarce and valuable commodity indeed.

Top

Question: As per best practices, what would be the correct number of items that could be listed down as sub-menu? The challenge is accessing information with reduced clicks. I have visited many sites to explore the answer but got confused as few of them showed 15-16 items as sub-menu. Let me know your views please.

Eric's response: Sure, I can help.

Optimal search happens when you have 18-24 items on a menu, placed in groups of no more then 10 items each. There is a slight exception when the resulting menu is overwhelming for users (rare to find if it is well worded and structured). In this case a smaller number of selections is provided at a time and you have more menus to go through (a technique called funneling).

The issue you are referring to is known as the "Depth vs. Breadth" question in the literature. This is because shorter menus force you through more menu levels (more depth) and long menus (more breadth) give you fewer menu levels to reach your target. In ancient history we recommended 7 plus or minus 2 menu choices, or a maximum of 10. This advice was based on the mistaken idea that the user needed to hold the whole menu in memory. But that was solidly disproved.

Top

Question: Hi Eric! I've been going nuts Googling for any standards or approaches for
a) using tech support logs to identify usability issues that are driving support costs
b) training support teams to identify usability issues when talking to customers.

Have you run across this information in your sojourns?

Eric's response: Yes and no. :)

It is absolutely common practice to review the tech support data. This does not usually involve reviewing detailed logs. Every large operation has a report of the number of calls in each class. So check how many 'password resets' calls. Check how many 'navigation support' calls. This data can give you an indication of where the big-ticket improvements will be. Do be a bit careful, as tech support people do not take much care with their logging and can insert some artifacts. For example they will tend to classify calls under categories that require less follow up, or give them more performance credit.

In terms of training support staff, that is usually not practical. If you CAN train them to do this effectively, you can give them a big raise and transfer them to the usability team. It is more practical to have a trained usability team member plug in to observe calls for a week or two.

Top

Question: Several of our error messages display UserIDs of other users. I would like to replace User IDs with something more appropriate (user name for eg.). UserID does not necessarily identify the intended person. Also exposing User IDs is a security threat. If you know the UserID of a person, you are halfway to cracking his login. Am I correct? Any other drawbacks of using UserIDs?

Eric's response: Sita, I'm a bit confused. I'm not sure why you are showing a User ID at all on an error message. If the error message is specifically about an incorrect User ID then I can understand ( perhaps an administrator has entered a duplicate ID). But otherwise, it is hard to see the value of showing an ID or a name. I assume that your user has no confusion about his/her identity.

Even in the unusual case where users have multiple IDs and must be logged in with the correct ID to complete some functions, it is better to show the TYPE of ID (ADMINISTRATOR or EASTERN REGION) rather then the ID.

Top

Question: Have you ever seen a site that was half translated, half not? We are looking to translate a large e-commerce site into Spanish, but the budget doesn't allow the whole site to be translated. Since most of the site is products, my inclination is to keep some of the products in English, but still include them.

Is it a major "best practices for user experience" no-no to do that? Does the marketing value of including English-language pages trump user experience? Or is giving that extra info to users a good trade-off for the user?

Have you ever seen a half translated site

Eric's response: I asked our globalization expert, Apala Lahiri Chavan, to weigh in on this one. Here's what she had to say:

A half-translated site is a VERY bad idea. Users' trust about the site is severely damaged when they see parts of a site in English and parts in their local language. They assume that this is a shabby job! We found this to be the case in several Usability Tests that we conducted.

Top

Question: What are the key differences between User Experience design for Thick client and Thin client applications? Are there any good books and online resources available to understand UX for thick client vs. thin client? To be more specific, UX for desktop applications vs. browser-based applications?

Eric's response: There is not that much to worry about. ALL the process and models apply in both technologies. There is simply a bit of difference in the technical capabilities that makes the interface design different. The client-server application is asynchronous and so you have the ability to have more direct manipulation, a few more controls (like combo boxes and sliders), and immediate error handing. In fact technological advances (like AJAX) make the Web-based application more and more similar to the thick client.

The thin client has some special advantages for software update, and some weaknesses with slow lines. So those can be significant in some situations, but have little impact of the UI design.

Good user experience design is tough work. But the important design differences between thin and thick client hardly fill a pamphlet much less a book.

Top

Question: Are there any best practices (or usability findings) about using "My" vs. "Your" on a website? For example, do user's prefer "My Account" or "Your Account"?

Eric's response: The "MY" everything fad was over in 2001. It was rather pathetic even at its height! "Your" is also generally extraneous. Would it be someone else's account?

How about...
-ACCOUNT
-PREFERENCES
-WALLET
-FRIENDS

This is not really better is it?
-MY ACCOUNT
-MY PREFERENCES
-MY WALLET
-MY FRIENDS

Incidentally, in general we avoid adding extraneous content. The "e" example is also in this category. So showing "eAccount" is usually not useful.

Top

Question: My question is related to charts. They say a picture is worth a 1,000 words, and most of us would agree with that statement. Have studies been done on the usability of charts, in a similar fashion to text (e.g. contrast, etc.)? We are trying to design a chart-intensive application and little things like "shading the walls of a chart" might sound little, but sometimes the little things can have big impact. Thanks.

Eric's response: That statement is not exactly true, and there are times when text or even a chart of numbers is better.

There is of course a LOAD of research on how to make a good chart. For example it is very well documented that gratuitous shading and three dimensional effects degrade performance significantly. This is a common problem with the fancy chart tools available today.

There are so many other issues. Picking the correct TYPE of chart is critical. I often see histograms where line charts should be used, etc. Generally avoid complex charts (like candle charts as an example) unless you have a skilled user who really needs that data.

Finally, it is a good idea to do some testing to see if your design is sending the message you intend.

Top

Question: I read and use HFI material all the time. Thanks for providing such good insights. Do you have any material on why Web site design differs from newspaper layout design, especially why they should differ?

Eric's response: There are many differences, which is why print media people don't transfer very well to the online realm. The newspaper is on a very different display space. It has no interactive capabilities. Newspapers can not be animated. They can not be interactive. And, people have very different expectations about how a newspaper will work.

Top

Question: On Windows XP search box (with that cute yellow puppy) after the search options of Pictures, Music and Video, the two buttons displayed are "Back" and "Search" respectively.

The primary goal for that little form is to search so "Search" button should be the first one rather than the "Back" button. Is that correct? Or does it matter at all? Thanks in advance.

Eric's response: Clearly, once the search options are set, the next button should be SEARCH.

Sometimes Microsoft developers seem to feel that they can disregard usability principles as they are so powerful in the market. Maybe that will catch up with them one day...

Top

Question: Hi Eric, you have answered similar questions to this before but I'd like to ask you your preference on the following which relates to mandatory and non-mandatory fields when completing applications. We are debating the following:-

Is it a better user experience to show *information is compulsory at the top of the page and mark all compulsory fields with a red asterisk

Or should we state 'all fields are compulsory unless otherwise stated' at the top of the page and mark all non-compulsory fields with (not compulsory).

Or can you make any other suggestion for how we can effectively tackle this. Also I notice on this page, the position of your indicators are next to the field - should this be the case or should it sit to the left of the title - or does this not matter?

Also, another question is around the usage of pop up windows. Is using a pop up window and greying out the rest of the page as way of confirmation (see bbc.co.uk and change your preferences as an example), more successful than showing an additional confirmation page when completing e.g., a transaction. I'll look forward to your replies.

Eric's response: It is definitely better to mark required fields, rather than mark optional fields. Marking optional fields would be counter to global conventions. Also, you need to draw attention to the fields that have to be filled in. You will sometimes need to scan to see that all required fields are completed, and this is done best when the required fields are highlighted. You never need to scan to check all optional fields.

As long as response time is the same it really does not matter if the background is greyed out. I suppose it might maintain context a little bit better to have the greyed out background. But as long as the feedback message is well constructed, it is unlikely that it will make a difference. Therefore, response time would be the main concern in this case.

Another trick is to add the confirmation on the top of the NEXT page the user would want, rather then have an interstitial display.

Top

Question: Is there a best practice for what (if anything) the computer should say to the user if they have changed no data and then pressed "save"? Some applications (e.g. Microsoft Word) say nothing and some say something along the lines of "no data needed updating". When leaving SAP you get a generic warning about losing unsaved data regardless of what you have done. Which is deemed to be best?

Eric's response: All things being equal "implicit save" is the best strategy. Implicit save means that you make changes to the display and they are saved when you leave. There is no need for an explicit SAVE action (which means "move data from RAM to Hard Drive" and that should not be a concern of the user). In this case there should be an undo capability (RESET or CANCEL). The technical limitations of the Web sometimes force you to use an explicit save method. But this will probably disappear as the technology matures.

Top