Ask Eric: Archived Questions

Question: Hi, I will shortly be working on a project which involves migration from a mainframe to a GUI-based system.Can you suggest some reading or guidelines to be kept in mind while doing the same.

Eric's response: Wow. Mainframe to GUI is a pretty old problem. Have not seen a mainframe in some time...

The most critical insight is that it is easy to make the design WORSE when you transition to a GUI. If you simply port the mainframe interface into the GUI container you will get no real positive benefits, but incur challenges with the added overhead of window manipulation.

To make the transition positive requires taking advantage of the added capabilities of a GUI. Use the benefits of windows, mice, pulldowns, direct manipulation, etc. So you really have to re-architect the interface.

Top

Question: We are currently working on an existing desktop application which needs to be converted into a Web application. Following are some of the details of the application. Can you please let me know how can user analysis be conducted for this project.
1. Accessible in 7 countries.
2. Some modules are common throughout all countries. Some are country specific.
3. The application will be developed in phases.
4. Currently users perform all the tasks through keyboard shortcuts only, which the client wants to maintain.

Eric's response: First of all I have a question. Why is the client dictating the input mode on this project? I really doubt that a "key board short cut only" interface is optimal. I would think that they would want something optimal. Generally a client should indicate their business objectives and then let the usability team work out the best way to meet their objectives.

"User Analysis" – seems like it is needed. But that requires finding the optimal solution rather then following client edicts. If the mode of operation in your organization is to have the client design the interface, then I am not at all sure what you can do.

This is a wonderful example of how impossible it can be for a usability person in some organizations. You clearly have not been given even the most basic training in usability engineering. You have no established methodology, standards, or tool sets. Your executive management does not understand or value usability work. It seems pretty hopeless.

You can try to get some training and individually work to do some good things on the projects you are given. However, the real objective should be to get your executive management to understand how desperately they need to pay attention to usability issues.

When I first started spending time in India I hoped that large system integrators would understand that usability was an incredibly powerful way to move up the value chain. I hoped that they would gain a reputation for delivering highly usable solutions. Instead, if anything, these companies are getting a well deserved reputation for promising to deliver highly usable solutions and not delivering. Sad, that.

Top

Question: Is there any website that gives awards for best usability? Like thefwa.com for favorite website award of flash sites.

Eric's response: There are primarily awards for POOR usability. ("Sites that suck" is now a cliché.)

But I do like your idea. The only challenge is that a site should be good ergonomically in the context of a set of business objectives, user profiles, and scenarios. If you just look at a site without this context, then you can't really tell if it's good or not.

We had one financial site where the government forced our client to provide free reports. The business objective did not suggest easy-to-get reports. A "poor" ergonomic design, with lots of steps, would actually be appropriate!

In persuasion design I am constantly finding examples where you may have to design a less efficient interface in order to create specific reactions (like engagement). So how do we handle that???

But the idea of an award might be good... We will think about this :)

Top

Question: As an independent CUA contractor, I've noticed some clients / potential employers are requesting me to perform a "test" of my usability skills. This usually involves time analyzing an existing site and giving recommendations. Oftentimes, after spending several hours in this review, I don't get the project / job. I am probably not alone in this situation. I suspect other CUAs get requests for "free" reviews which don't result in any work. Can you please address how to handle a request for an expert review without looking uncooperative to the client?

Eric's response: "Clients" that push for free advice is a common problem in the consulting business. I would suggest providing VERY limited samples of what you can do. Perhaps make comments on ONE page only. After that respond only with process and principles to show that you understand the issues, but not to do the work for free.

Top

Question: Hello Dr. Eric. I hope I'm in the right place. I'm not a developer, but an IT business analyst and I'm managing a major software rollout that will be a big change to the status quo process for all of our users. We've purchased a CRM package that allows us to do some custom development but we're at a place where we need to decide whether to develop for certain requirements from within the CRM application's framework or develop outside of it (perhaps .Net) and integrate. We're 51/49 in favor of doing it outside because of flexibility but I want to make sure all of the bases are covered.

My question is this: What are the types of questions I need to ask in order to make the most educated and objective recommendation possible and get everyone involved?

Things like comparing the development time of the two options and integration issues and perhaps cost are some of the questions that come to mind. What am I missing here?

Please forgive me if this question does not apply to usable interface design.

Eric's response: Sure, this is the right place.

There are, as you point out, issues of cost and development time. All things equal COTS (commercial off the shelf) software is faster and cheaper to install. But the usability issue is the other side of the issue.

The real question is to see what the users actually need. If you define this FIRST, then you can consider the best way to get it implemented. Otherwise you are just guessing. SO we recommend STARTING with an analysis of the user needs. Then the decision about method of implementation can be properly informed.

Top

Question: Has anyone done a usability study around what type of information should go into the Getting Started section of a software user guide?

Eric's response: The "Getting Started" section was a slick idea. It is NOT what you need to get started. It is what you need to have your first substantial success experience with the application. Once that happens, you have conquered the most difficult hurdle. This innovation was a node to the fact that users won't read the manual (and probably should not have to).

It reminds me how we learned to change the title "Introduction" into "Read this Section First!" as the reflexive response to "Introduction" was to skip it.

Top

Question: I'm doing a seminar on the user interface of Windows and Macintosh, and if their success has something to do with their GUI design. For that I need some theory of GUI design, but there is far too much that I found. Is there one book or theory, which is very well known and widely accepted? If not, could you tell me some, that you may think are good and widely accepted?

Eric's response: Medical doctors have too many books and theories of how to live longer. It's the same with interface design. It's a HUGE field and you can't expect to deal with it using a list of 10 principles!

Windows and Mac have somewhat different underlying approaches to GUI design. Windows was built more for the expert user, with more power features and visibility of the (messy) internals. As such it is harder for a novice to use. The Mac approach is simpler. It successfully insulates users from the entrails of the software code; which is good unless things start to go wrong, or you have a power user that WANTS to play with the deeper aspects of the system.

Windows also has a rather long list of amazing usability flaws. Just think of having to explain to everyone that you select the START button to STOP! (uh, you "start to stop there?") It also is a remarkable example of "feature creep" (who do you know who uses more than 2% of its functions) and repeated patches of usability problems (e.g., Drop downs are two clicks. So icons make it one click. But icons are not obvious. So we make tool tips that explain the icon).

I think conventional wisdom is that Windows won the GUI wars in spite of its design philosophy and problems. The win was more a function of VERY savvy marketing and business practices.

Top

Question: How do CASE tools fit into the data-gathering phase of the SDLC?

Eric's response: Well you would think that Computer Aided Software Engineering tools would have nice facilities for support of data gathering and analysis. Unfortunately, I have yet to see this happen. Some of them may have the ability to hold some "use cases," but this is a small fragment of the UCD data gathering material needed. So unfortunately, we end up doing the usability work separately. Then the CASE tools are used to support software design and construction.

Top

Question: I just finished attending the HFI 4-part training series. Since my company currently employs a standard software development lifecycle based on Microsoft Solutions Framework and UML, I'm curious as to how can I integrate the Schaffer-Weinschenk Method into our SDLC. When I asked one of our instructors, he said he had some sort of a mapping diagram to illustrate how the Schaffer-Weinschenk method fits into a standard SDLC based on RUP (Rational Unified Process) or MSF (Microsoft Solutions Framework). However, he didn't get a chance to provide me this diagram.

Can you help me in this regard?

Eric's response: There are a lot of nuances to the proper integration. But just consider doing the structural design at least, and maybe the detailed design BEFORE the technical work states. That is actually the meaning of User-Centered Design. UCD is not about "worrying about the user," it is CENTERED on the users. Which means the usability designers go FIRST.

We also have this chart on our Web site which shows some aspects of this integration.

Top

Question: Do you know names of roles that usually focus on usability? Our company currently uses the term User Advocate, but it seems to cause some controversy on teams. What other names for this role have you seen?

Eric's response: Well this is an entertaining question. Off the top of my head....

• Engineering Psychologist
• Software Ergonomist
• Human Performance Engineer/Specialist
• Human Factors Engineer/Specialist
• Usability Engineer/Specialist
• User Experience Designer/Specialist

There are other related terms like Information Architect (usually a library science background and only deals with categorization).

User Advocate is a bit unusual. It sounds a bit legal and does not imply an active design or testing role. It sounds like some users pulled in to "represent the user interests" (which generally does not work).

Top

Question: We know that with 5-10 users in iterative usability testing varying degrees of issues will be found; and we can expect opportunities for improvements to fall out of that testing.

However, the one thing we do not know is what does having a dedicated User Experience, Human Factors, User Interface Design, or Usability team do for a product in general terms of improvement or producing a better product for a company.

Has there been any research done to show what having a dedicated group of professional, experienced user interface designers and/or usability experts does or can do for a product as far as its quality of user experience is concerned? It seems this would be priceless information (a.k.a. ammunition) to have when trying to promote or sell the idea of such a group or even in establishing the group's value to the powers that be.

Thanks in advance.

Eric's response: No one has run that study, and yes it would be interesting. But the greatest value of this will still be in the future. We are trying to set up such operations and doing so worldwide. But the processes are not yet in place that will allow us to really leverage a dedicated usability team over time. Right now most teams basically run a series of projects (which we know have a good ROI). But any accumulation of knowledge is a bit random and dependent on individuals for the most part. So with THOSE processes in place I expect a quantum jump in value and a reduction in cost.

Top

Question: I was browsing through the HFI site and took the usability quiz for fun. I came across a question: "After determining what you want your application to do, the best next step in software development is to:" with 4 options. The correct answer revealed was 'Know the target users'. I have a doubt. Is it correct to decide what an application will do before knowing the target users? I must know the target audience before defining the boundaries of what an application will do. I would like to know your perspective on this.

Eric's response: In projects there is usually an initial design concept that sounds sort of like "We want to build an application that will play music for fitness enthusiasts". This is a typical concept statement we get from clients. THEN we need to look deeply into what we MEAN by 'fitness enthusiast'. We would gather data about them and then verify that they wanted to play music. We would then begin to design off their deep mental models and overall ecosystem.

Top

Question: If I develop a Web application that looks exactly the same as Outlook (left navigation bar, colors, icons, etc.) but that does something different (inventory) am I infringing copyright? Can I be sued?

Eric's response: There are some domains were we have seen an amazing number of patents and copyright restrictions (e.g., interactive television set top boxes). That said I have NOT seen a suit for copying typical left navigation schemes. I would certainly avoid direct duplication of icons and other graphic images. I have not seen copying of a general interface structure become an issue in the environment you are describing. Check with your legal department.

Top

Question: India has tremendous potential to be a global player in the field of "user interface design" and "usability engineering," however selling "design services" in India is extremely difficult and selling "importance of usability" is even more difficult and challenging, mainly because of lack of awareness among businesses and even government bodies.

Do you think that the HFI India usability task force can help create a "usability" awareness campaign in India? I am sure all design experts, National Institute of Design (NID), Confederation of Indian Industry (CII), India National Design Policy Makers would like to join hands with HFI to take this forward.

Thank you.

Eric's response: Hi Sandeep,

We have seen a huge growth in the willingness of Indian companies to invest in usability. We have large Indian clients who pay the same rates for our Indian staff as American companies. So that is a change.

However, the REAL potential is in the EXPORT of usability work. This has the potential to move the entire Indian infotech offering up the value chain. We are proving that Indian usability staff can help to design interfaces that are absolutely world-class.

The sad thing is that we have seen little support for usability from the Indian government, or even from the large systems integrators. Since 1999, I have had many meetings begging for help in creating educational programs. But there has been very little done on a large scale. Interestingly, I suspect that China could grab the honors in Usability, even with India's head start. This is because the Chinese government is already listening and, I think, taking the opportunity very seriously.

Top

Question: I would like to have your views on how I can integrate UCD into other design methodologies such as OOA/OOD to the Waterfall approach. I believe it compliments the other. What's your view?

Eric's response: There is a direct disconnect between true UCD and other methods. In true UCD the user-centered design work (mostly) goes FIRST. Once it is clear what the user needs and the interface is designed, the technical process can ensure that it functions. So true UCD does not really integrate that well, because the other methods tend to start from a different perspective. At the same time, you can integrate usability work with most processes. You can even start at the wrong time (usually late). This takes a bit more skill, as the integration can be tricky. Mostly we try to get the interface design right as early as possible. If that is not possible, then we try to patch the design (which is SAD).

Top

Question: What ethical issues might user interface designers face when trying to reconcile the needs of the end users of a system with the needs of the organization that is paying for the system to be developed?

Eric's response: If you have a client who is trying to do something unethical, then you are likely to make them more effective at doing that unethical thing. This is in no way a special consideration for usability work. It is true if you sell bolts or phones. Because of this, HFI has a set of rules and processes for dealing with projects in this category. We probably decline 3-4 projects each year that we feel uncomfortable about.

Top

Question: I'm looking for some good questions to use in researching requirements tools for both management and creation of the requirements. Do you happen to have some suggestions?

Eric's response: Most requirements tools I have seen tend to enforce a function-oriented viewpoint. They list the software functions without a foundation in user-centered issues. From my viewpoint a good requirements tool would start with a definition of the user profiles, environment, and scenarios. Then based on this data the functional needs of the software can be defined. Without this I think any tool enforces bad practices.

Top

Question: My company recently invested in "Sharepoint" by Microsoft to be the base for our intranet. It is a data management and info sharing software. How can I convince a very reluctant IT manager that we need to invest in usability testing and user-centered design. I presume his reluctance is due to lack of skills and perceived cost, not to mention his idea that you can't redesign a purchased software package; you're stuck with what you get. How can we make improvements to an off-the-shelf software package in terms of usability? Are there settings (e.g. font size and color) and sub-programs that can be implemented to improve the usability of an off-the-shelf software package? Or perhaps studying the usability of the software and determining its good & bad features will build usability knowledge which can be translated into staff training and thus improve usability. For these reasons then, post-purchase usability testing is valid, is it not? What tools can we use to perform post-purchase usability testing?

Eric's response: Well unfortunately there is actually NOT that much you can do in many cases. We don't want to do usability testing that just shows us problems that we can't fix. We don't want to invest in design work that won't pay off quickly.

Most purchased packages are not very configurable and there is little you can do to improve them. The usability work needed to be done by the development team.

You can have input into the SELECTION of Commercial-off-the-Shelf (COTS) packages. With a bit of usability work you can give structured input that can be factored into other issues like cost and stability. That is worthwhile.

But real customization is generally only justified with very large installations (lots of users) and for very involved applications (like ERP systems). These "involved" applications are sometimes built with an expectation of customization, which helps some.

Top

Question: Is there a place in an Agile Development process to conduct a formal Heuristic Evaluation by a Usability Expert. If yes, when in the process would it be a good time to conduct this evaluation.

Eric's response: I'm not sure a systematic review is a natural-required part of Agile. In general the Agile methods seem pretty tough to retrofit with a systematic user-centric design process. Most of the usability approaches I have seen involve sort of wading into the fray. This was great in the 80s... But not today.

Top

Question: What are the design principles and methods that can optimize sites in general.

Eric's response: Well the whole field of software usability optimizes sites. But no one who is knowledgeable will optimize a site "in general". We optimize sites for very specific user performance and experience objectives. The decisions you would make to increase speed would be different than the decisions you would make to eliminate the need for training. With entertainment sites and games you may only care about user satisfaction. With government sites your main concern may be making citizens feel that they are well served. Once we have a clear set of objectives we can proceed to optimize the site.

There is easily a billion dollars of research that tells us HOW to optimize a site. We have recommendations on layout, wording, color, highlighting, control selection, etc. There is also a whole process (generally referred to as "user-centered design") which we follow to ensure that a site is optimized. It includes data gathering with users, iterative design, and testing. So there is a well-defined way to do usability work.

Top

Question: Is there a specific way to calculate the costing for
creating a UI & Prototype?

Eric's response: Well you just add up the days of work multiplied by the labor rate of the various levels of staff.

At HFI we have our complete methodology broken down in terms of estimated days for each type of staff member. For each new project we need only tweak the number of days to the circumstance and the cost estimate is done.

Top

Question: Can you comment on your success of your Usability Analysts in Mumbai working with global clients? Have you found challenges having offshore usability analysts? How many are out there in Mumbai? We currently have developers and business analysts working in Chennai and Hyderabad, but were wondering if UE folks could also operate efficiently "away" from the business groups? Thanks.

Eric's response: We have about 100 staff in Mumbai. We also have secondary offices in Bangalore and Pondicherry, India. It is certainly not a trivial task to create global teams. But we currently have 50% of all HFI consulting hours completed by staff from the India office. We have now spent nearly seven years developing methods to make this work effectively. This includes infrastructure, work processes, organizational structures, and governance issues. I guess at this point I would say that it is certainly not trivial. It takes a serious investment. But once done, we are doing world-class usability work with our model of "'local proximity and global resources" on a large scale and at competitive costs.

Top

Question: Long URLs can be tough to decipher; initial caps make them more readable. For example: GetMoreUsability.com is far easier to read than getmoreusability.com. Is there a reason against using initial caps in a URL?

Eric's response: First, please get a good URL. But if you have to have a long one then you can indeed show it with the initial caps. But happily the user need not type the initial caps.

Top

Question: Given new technologies or newly branded, already existing technologies, like AJAX or Laszlo, etc., what are the advantages and disadvantages of replicating Windows (fat-client) applications on the Web? Do you really want to? Or why would you want to?

Eric's response: From a user interface viewpoint the key distinction is asynchronous vs. bisynchronous interfaces. If the interface must send the input to a remote CPU for processing (like mainframes and Web) then you are in a bisynchronous environment and have some serious restrictions. You can't do immediate error handling, you can't drag and drop, etc. The GUI and Web2 are both asynchronous and therefore they are pretty much similar. The question is really one of persistence. If you have a dedicated machine with full-time workers there is much to be said for the fat client (especially with technologies that allow easy remote updates). If it is a distributed part-time usage scenario (like Google Earth) then the Web2 technology works better.

Top

Question: I'm a UI Designer with 3 years of experience in both graphic and Web UI designing. I just wanted to ask which are the best Web sites designed according to "user-centered design principles".

Eric's response: Well Santhosh, people often ask this. But it is neither a simple nor useful question. It is complex because "Best" does not reference a clear metric. The Dell site (which HFI has worked on quite a bit) is quite high on the list of "Best" sites if you count sales volume (in dollars). If you look at effective use of community and cross selling you might look at Amazon. If you want an effective structure and good fit with the users' workflow look at Staples (another site with HFI inputs).

But the key point is that you cannot copy these sites and thereby make your site usable. Sites have to be tuned to a given user and environment. In addition, even the best sites have design decisions forced by politics and technology that are not at all optimal.

So instead of asking to look at a "Best" site to copy, it is better to ask what are the design principles and methods that can optimize sites in general.

Top

Question: Hello Eric: I would like to know how to design a better user interface for Intranet portlets. Is there a standard that I can see which talks about the number of portlets that can be displayed on a portal page (max 4-5). I'm designing a portal page for my team which started with 2,3 and now the requirements. are that one of our customer would like to see all information at one go. To my knowledge too many portlets cluster the page and it gets too busy. What would be your suggestion on this? Please could you also refer me some url's on the Web where I see some sample of a portlet design from a User Interface Designer's perspective.

Eric's response: I think you are looking at it from the wrong angle. Certainly increasing the number of portlets will increase clutter. But the real question is what data do people need. Do a user-centered analysis to work out the information need, and let this drive the design. In addition, studies have generally shown that it is better to provide MORE information (potentially more portlets) then people generally expect. It is better to have the information you need right there and together, than to have lots of white space.

Top

Question: What usability issues and dimensions would you consider when studying usability for not-for-profit Web sites?

Eric's response: Look at the business objectives! Not-for-profit probably means you are looking for donations. So amount donated seems like a good metric. To reach that I might look to increase page views, and subjective ratings of involvement and interest. Also reduce the time to physically make a donation. You might also look at methods of involvement, like community functions and outreach (like newsletters).

Top

Question: The integration of usability in software engineering perspective in finding out how usability theory could be used in the software development of the mobile Web application.

Eric's response: User-centered design applies to mobile Web applications just as it applies to full Web sites, weapons systems, cockpits, sewing machines, hairdryers, medical devices, and most anything else. The same process. The same principles. There are certainly a few interesting challenges and tricks with such "baby face" designs. But those are just minor tricks of the trade. A good user-centered design background will apply to pretty much ANYTHING you want to design.

Top

Question: "Users like and expect it to work like Outlook, so that's what we're going to do. Make it look like Outlook."

This could be a "design" decision because of an (false) assumption or it could be an edict passed down for whatever reason.

I argue that Outlook is a PIM (personal information manager) and does not necessarily work for (all) other applications.

The problem I have heard AND seen with using an established paradigm for something new is that only the LOOK usually gets carried through. If you are going to make something like something else, then it must be identical, meaning the look and FEEL (functionality). I argue it is the functionality, along with the look, that users are used to and supposedly prefer.

A new application then gets pushed further off path (away from being usable) because needed functionality has to be made to fit into an ill-suited
paradigm.

This is in addition to the simple fact I do not believe the Outlook paradigm can be used for every application in the world anyway.

What do you say to this?

Eric's response: RIGHT ON.

This problem dates back a long way. People think that by copying a well known application they will make their application usable. Unfortunately, software has to be customized to a given user, taskflow, and environment. When you force fit another user/taskflow/environment the result is a disaster.

Top

Question: What are the UI standards for the Web site and a web application?

Eric's response: There is no universal standard for Web site and application design. The most important thing to reference is the de facto standards, which are reflected in the users' expectations. Besides this you will need detailed standards that fit your application's domain and previous conventions. At HFI we keep a set of "vanilla" standards, but then we generally customize these to a given company or product suite. It takes some work (like 8 weeks) but then it speeds design by about 10% overall. So it is quite worthwhile.

Top

Question: I want to decide on the evaluation method for conducting usability on a LMS (Learning Management System) product. It's critical that the approach that I choose be cost effective and convincing because it's just been a few months of realization from the clients that the "product needs to be usable". Usability is still a term not understood by everyone in the organization.

Correct me if I am wrong in my decision.

Knowing I do not have access to the users because of wide spread different domain use (educational, corporate, healthcare), I would rather combine a Heuristic Review first and then conduct Usability Testing. A heuristic Review first to identify the problems associated with the lower levels of perception and performance. Once those problems have been addressed through Paper Prototypes, I would conduct a Usability Testing with actual users (get the management to budget for it) to focus on higher level of interaction issues.

To elaborate further, the problems that I have identified on just scanning the product seems like flaws in the design of the task flows that do not reflect the order the users "expect". The problems that surface here are the result of a mismatch between the expected/intended and the actual task flow.

Also there is a lot of system inconsistency such as interface design specific.

Interestingly there were no use cases/user tasks created when the product was built.

My question to you is what should be the best method and how to go about it?

Eric's response: Right. You are very not correct.

"Doing Usability" is NOT just about usability testing. You will not develop usable software IN THIS LIFETIME by just testing. God (natural selection) designs by usability testing. Not people.

You need a full user-centered design process. This means working early in the process to form the application positioning, purpose and navigational structure.

Your idea of first doing an expert review and then testing is good. But that is only for the small part of the process that evaluates the current application. Use those results to fund real user-centered design.

Top

Question: My company is currently developing an online style guide for our Intranet Technical Writers and Web Designers to use. We are having trouble agreeing on a standard for describing the Buttons, Tabs and Keys in our documentation. Do you suggest listing them as they appear on the screen or keyboard, such as press the Ctrl key versus press the Control key? Is it best to follow the Microsoft guide and capitalize the first letter and bold the text? Have you done any studies on this?

Eric's response: The main thing is to HAVE a standard. Then as long as the standard clearly differentiates and is perhaps a bit self-evident, you will be fine. It is nice to have the verb and also the label distinguish between keys and screen buttons. For example...

Select the 'Ok' Button
Select the 'Equities' Tab
Press the [Enter] Key

Top

Question: I'm a product manager working in a scrum environment where our group provides requirement documents that include wireframes, workflows and a description of the proposed system. The main audience for these documents has been the engineers who divide work along two week cycles. However, when we do a public facing product the user experience team uses these documents as a basis for their interaction and creative designs.

The creative team claims responsibility for both front facing and back-end UIs. They even desire, as we all do, user testing at the paper prototype level. A lofty goal considering how it impacts our schedules. It requires we map it out, creative take 2-4 weeks to return with creative comps, this is tested, recommendations made and finally coded.

From our point of view, what is the value add that user experience provides? Can you really separate the responsibility for the UI and the responsibility for requirements when they are so intertwined? It seems to me that showing the end user the UI is a validation, a first chance they can see what they are going to get? Furthermore, how can we streamline the process so it doesn't require planning creatives involvement well in advance?

We believe we know the answer. The user experience needs to provide us with dedicated resources (interaction designers and graphic
designer) within our unit. The interaction designer would be brought into our design process and work alongside a product manager. Together they would share the responsibility of meeting with internal and external users, participating in the design of the process and drafting up the wireframes and UI descriptions for the PRDs.

Our creative team has bought in on the need for a dedicated resource but not the role and responsibility itself. They remain resolute on knowing exactly what the requirements are and it's solely our responsibility to provide that.

This contradicts my understanding of user-centered design. How can you claim to be the user advocate if you are relying on other teams to define tasks the user wants to accomplish? How can we more closely align our goals to work in a agile environment?

How have other teams dealt with this issue?

Eric's response: Great question.

There are really two approaches currently in use. The old and not so good way is to have a design team go through a process and create initial designs (which are sometimes coded and released) and then have a usability team come in to try to fix the interface afterwards. In this case the costs are sky high and the team has little they can do to really influence the important parts of the design. They end up struggling to fix detailed design flaws. But the purpose, structure, and flow of the facility is fixed. The usability team can be of very limited value.

Currently companies are turing to user-centered design. This means that the usability team is involved from the early concept phase. In fact, the usability team generally takes the business and technical concepts out to the field and comes back with insights from the user community. By studying how the users work and think the team can tell how the facility will fit into the user's workflow and how the application should be structured. The usability team then turns out a tested detailed design specification for the entire user interface. This is the way that maximum value is provided.

Top

Question: I read with interest your resolutions for 2006. You mention that the potential market it $55 billion. I want to know how you arrived at this figure.

Wish you a fulfilling 2006.

Eric's response: I looked at the worldwide software development spending ($550 billion) and I took 10% of that. You can also look at Nielsen's recent calculation of needing 1 million usability people. That suggests an average loaded labor cost of $55,000 per person. This is a bit conservative ($55K is loaded labor rate for India, it is quite low for the developed world).

Top

Question: My question is actually in continuation to the question and its answer: December 13 , 2005 – submitted by Dan Pelman of Oklahoma City, OK

The usability staff, most of the time, in most of the companies is not 10% of the total team size – is it still possible to attain the same level of usability in a product? What are the non-essential parts we can do away with, considering that the time frames do not change and we have limited budgets. In other words, how to decide which methods to use for design, which to use for evaluation and testing and whether post-implementation UI inspection should be conducted or not?

Eric's response: Indeed, today we usually have less than the required 10% of the development population allocated to usability work. In some cases this means that the UI design will be done by computer specialists, and other types of analysts who are amateurs at usability work. In this case they tend to spend the same amount of time and budget on UI design, but have poor results. This is not smart.

In some cases the limited usability team must prioritize their attention. They need to rank the projects based on business imperative and then can only work fully on the top priorities. This is the best way to handle a limited team. But clearly, one hates to see anything built that is not usable.

As the level of usability staff gets very low they often shift into an evaluative mode. This is also attractive since doing usability testing is the easiest of the usability engineering skills. But this is truly horrible. Amateurs create poor designs. We test them and identify that they are bad, perhaps showing where the problems are. The amateurs try to fix the designs. They do this poorly and then make more problems as a spinoff of the fixes. Then we test again. This is not smart.

Top

Question: Is there a general cost percentage for designing Human Factors compliance into software design? Say the software is going to cost 3 million to build. What percentage of that cost is put into including appropriate design for human factors?

Eric's response: Generally usability work will take 10% of the overall development budget. This number might fluctuate a bit based on the type of applications or sites. Facilities where usability is critical and the interface is complex can take more. Facilities where there is mostly back-end processing or the interface is simple will be less. But a bound would be about 8-12 percent.

Importantly, this means if you have a development department with 200 people, then 20 should be doing usability work. It is scary when I hear 200 developers and a usability staff of three people.

Top

Question: Since the writing of your book "Institutionalization of Usability", can you provide me with some organizations who have adopted the matrix infrastructure? Also, are you aware of any organizations who have a CXO (Chief User Experience Officer)?

Eric's response: The Chief User Experience Officers are currently few and far between. In fact, about half of the ones I have encountered have been more gimmick than substance. But the matrix structure is almost everywhere. While there might be some variations, EVERY large company I know who seriously does usability work uses a matrix.

Top

Question: How do we train users who are currently very used to a UNIX- and Fox Pro-based GUI to move to a Web-based (J2EE) GUI. They are more comfortable to use the Enter key than the Tab key or mouse.

Eric's response: Well first, remember that the users do not care what coding language we use. They only care about the interface operation and performance. Your switch is particularly at risk from things like the "enter key to tab switch." There is an effect called proactive inhibition which means that humans who overlearn a behavior do it again intermittently even when they know the rules have changed. So you will frustrate your users with that.

However, the trick is to make the new version overall a much better experience. Then a few sources of frustration will be offset by a tidal wave of good experience. This means designing for the advantages of a more flexible GUI interface. The physical operation must be more efficient (for the expert users) and at the same time self-evidency must be enhanced for both new users and ease of transition to the new version.

Top

Question: Our application is 20 years old, from DOS to JAVA interfaces. No real usability work was ever done on it. Now I'm asked to fix the GUI. But when I presented the usability principles a big question arose. My users have acquired certain habits of using the old GUI, even though the system is badly designed. What kind of arguments can I use to convince management to implement usability principles and standards even if those will have a tremendous impact on the users' old navigation habits. How can we migrate without creating user frustrations.

Many thanks.

Eric's response: No one ever complains because you have clearer error message wording.

I have never heard a user complain because of a truly better interface structure and navigation.

But there are things to watch for. In particular "proactive inhibition" is dangerous. This means that if a user has learned, and overlearned, a behavior (for example using ENTER to go to the next field), and then you switch it (Enter sends the whole screen). Then the old way will occur occasionally, even after YEARS have gone by. So you have to make sure nothing bad happens when they do things the old way by accident.

Top

Question: 1)Why is it that many software developers don't pay enough attention to requirements engineering? Are there ever circumstances where you can skip it?
2)Is there ever a case when the generic activities of the software engineering process don't apply?
3)Is it possible to combine process models?

Eric's response: The generic process models are all just guides to remind good developers of the things that have to get done. You must always adapt them to the particular project. You could certainly find a situation where the requirements are specified elsewhere. But in all cases requirements have to be done SOMEWHERE.

In terms of blending processes, this is almost always the case. For example we always blend our user-centered process with a technology-centric process. You then need to blend in some quality process and security process. The methodologies give us a foundation for working. But they are just a toolset to be used my smart project managers.

Top

Question: I need to know the roles of language/culture development on the decision making.

Eric's response: Language and culture have a huge impact on decision making.

They frame the goals (values) that underlie decisions. For example: getting things done fast is less important in an Asian culture where time is seen as cyclical.

They frame the practicalities. For example, in China, the main concern of a purchaser is that the goods might be fakes.

They frame the style of decisions. For example, Asian cultures will depend more on hierarchy (the senior/rich person decides) and communalism (the perception of the group is important). In Arabic countries people are quite averse to risk-taking. In America we value risk-takers.

Much of the international conflict in the world may result from disconnects on these important cultural contexts and conventions. Arabic statesmen don't "get" our President saying "Dead or Alive," and Mr. Bush has no idea of the context of their statements about "hospitality."

Top

Question: I'm interested to know your thoughts about whether Web Designers and User Experience Architects should report to the same boss? Or have different ones? In our organization, they are all part of eBusiness, but each has its own manager. I'm wondering if it would help to have them report to the same boss – yet many of their skills are different. thanks.

Eric's response: Well I'm not really sure what you mean by "web designer." If you mean graphics staff I think it is fine that usability and graphic people report to the same boss. If you mean IT staff, then I think it's a bit more problematic. While individual situations vary, most IT staff care about technology and getting an application out on time. They are not really focused on the issue of the usefulness or usability of their work. It is often better to have the usability staff report to marketing, product management, business areas, or even better a "chief user experience officer." These people have goals more centered on the challenges of the usability team.

Top

Question: As one of your certified usability analysts I have a question:

How should I organize usability issues / criteria? John Meech has been talking about Navigation, Content, Presentation, Interaction. But what should be the subcategories. Is there any best practices, white paper or other content about this?

Eric's response: Ronald, thanks for the question. Always love to hear from CUAs.

Navigation, Content, Presentation, Interaction works for sure.

Another model that I like is focused more on the presentation and interaction issues. This is to break considerations down by visual, intellectual, memory, and motor systems. This is particularly nice when looking at research results. So you might list all research on visual access to pages.

Yet another way to categorize insights is by the dependent variables of usability work. That is: speed, accuracy, training requirements, satisfaction, and safety. So you can list insights that help limit training requirements (make an application self-evident).

Of course you can also look at the categorizations we have developed for the "Putting Research into Practice" course.

Top

Question: I am working with a company in implementing a strategic plan that encompasses 8 initiatives. The plan to date addresses hw and sw acquisition and deployment issues; and has a placeholder for communications. The factors affecting the end user and ultimate success are yet to be defined. That is my value added! As an IT/HR fogie I have done this many times and factors such as training, LR implications, staffing... are in my mental research library. But in all my research, I don't find anything that looks like a comprehensive checklist. Or even better, one that provides recommended lead times (it's always "we'll implement and then it is the business' problem if they need to increase or decrease staff.") Do you have any suggestions on where I might find a comprehensive list since my old brain has holes in it and stuff falls out regularly!

Eric's response: Good point! I don't think I have seen a good published list of these types of conversion issues. We created one years ago at Bell Labs (Bell System Practice 007). But that is not public domain. Perhaps you will engage the old brain and create a white paper?

Top

Question: My company is creating a new in-house implementation team in India. They will be taking responsibility for a significant part of the client code for our products. These products are written in a variety of languages such as .NET, java, tcl, oracle forms etc., and are very complex in nature. All analysis and design is being done back at European HQ and will be passed to the India team to execute. The analysis & design includes the usability aspects. Given that you have experience working with offshore teams, is there any advice you can give, or point me at, to increase the chance of success in this new way of working?

Eric's response: In working with an offshore coding team you must very precisely specify the appearance and behavior of the desired interface. You should provide a complete design and description. Consider a complete prototype of the interface. Be sure to include details of error handling as well as processing specifications.

We have been very successful in doing usability work from India. But unless you have a team in India that is specialized in usability, you can not expect good design decisions from your IT team.

For more information, see my white paper on offshore usability.

Top

Question: I am working with a small design company that has been very successful in designing GUIs for software and mobile handheld devices in China. China has yet to embrace Web and software usability and currently there are only a few companies that offer services in testing.

They are interested in developing usability testing into their list of services but are unsure about how to go about it. What do you suggest they do?

Eric's response: Yes, I've been spending a lot of time in China and see the same problem. Happily, I think Apala (our VP of Asia) is all set for us to open an office in China shortly. So we will start moving China up the Usability chain. When that office is open you can count on classes in user-centered design and testing.

Top

Question: What is meant by "institutionalized usability"?

Eric's response: Institutionalization of usability is when an organization decides to routinely include a systematic process for usability. The organization can then support this work with a refined methodology, training, certification, tools, templates, standards, and quality assurance.

Piecemeal usability is the opposite. Piecemeal is when an organization has a few good usability designers scattered around the organization and IF they happen to be assigned to the project then usability is good.

Top

Question: How to reduce the rework ratio in software?

Eric's response: This factor actually PAYS for usability work itself.

One key to controlling software cost is making changes sooner. By following user-centered design we find out what the user needs BEFORE we have coded the interface. Then we can make changes in a cheap prototype instead of designing, coding, QAing, and then finding it just doesn't meet the user's needs.

Top

Question: I was taking the usability quiz recently on your Web site. And I did fairly well! But I have one doubt about the last question which says: The most important factor leading to the development of usable software is: The correct answer was "Management Buy-in"

What is Management Buy-in? How does it help as an important factor in developing usable software?

Thank you

Eric's response: VERY good question, Prashant. You are right in thinking that management people don't do the "real work" of usability. Their hands never touch the interface design (we hope). So how can they be so important?

We are moving toward a new type of usability work. It can no longer be ad hoc and piecemeal. It must be systematic and process oriented. It needs to be a mature area of business operations; not some lonely practitioner working in a corner. Management makes all the difference in this transition. Management must make the decision and change the culture. From the trenches you might be able to do some nice design, get training, or suggest some standards. But it takes a high-level manager to build a usability factory.

Top

Question: Could you please define Self-evidency for me? I took the basic usability principles quiz, and I answered question #4 incorrectly ("The single best predictor of a software application's usability is its:"), as I thought the correct answer was Efficiency.

Eric's response: Self evidency is the inverse of training time. A completely self evident application requires no training. This is extremely important for all applications; particularly those that are used on the Web or by home users.

Top

Question: Does a Web administrator need any different skills to run an intranet vs. extranet vs. Internet site?

Eric's response: The basic operation of the site (server management and such) would seem to be quite similar. With intranets and extranets there are issues like VPN management. With public Web sites the volume of transactions can be larger than any private facility. Therefore there are likely to be issues of load balancing. Unfortunately, today security is a real concern for everyone. But the types of attack are likely to be a bit different (e.g., public sites are more likely candidates for denial of service attacks, as success makes a bigger splash in the news).

I have been referring to operating the sites administratively. If you look at design issues things are far more different. Type of users are likely to be radically different. The business goals are different. So if you are talking about design and maintenance these are worlds apart.

Top

Question: I'm a young usability specialist, and my new project is about developing style guides for a quite big company which has different software developed by different teams. I've already read your pdf "How to develop an effective GUI standard" and I was wondering if you can advise me on other articles, books, or whatever about the methodology of such a project!

Thx in advance, hoping my english writing is good enough for you to understand me ;-)

Eric's response: Celine, I am afraid there really aren't good practical texts on how to develop a UI standard. It seems it is a somewhat closely held specialty within our field. HFI has done some 160 customized standards projects. I am not sure who else has developed that specialty. I suppose your point is good that we should go ahead and write up how to do it. But the problem is that efficiently developing standards really requires a set of boiler plate that can then be customized. We have not done a standard from scratch for perhaps 15 years. It is just too inefficient. That is why we built the product "HFI's Usability Central Gold™". This is exactly that boiler plate. With that in hand it is relatively easy to do a standard. Without it the development has lots of pitfalls and, even for an expert in standards, takes at least half a year.

Top