Ask Eric: Questions & Answers

September 29, 2006 – submitted by MC Smoak of Illinois, USA

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.

September 13, 2006 – submitted by Keefe Wong of Coppell, TX

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.

July 6, 2006 – submitted by Vanita Sharma of India

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.

May 25, 2006 – submitted by Miriam Perry of RI, USA

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.

May 8, 2006 – submitted by Santhosh Nadiger of Bangalore, India

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.

March 24, 2006 – submitted by Khaled Al-fagih of Jordan

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).

February 4, 2006 – submitted by Jim O'Brien of Atlanta, GA

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.

February 1, 2006 – submitted by Nupur Khanna Vij of India

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.

January 23, 2006 – submitted by Eric Edge of TX

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.