Design Questions

May 13, 2010

Stakeholder alignment

I’m designing the UI for an application, and people here have different ideas about what this product should do. How am I supposed to design when I don’t know what I’m designing?

This is a common problem, especially when requirements haven’t been written down and agreed on by the project and business stakeholders. We recommend doing a stakeholder survey early in the project, to help align the stakeholders. The survey should ask each stakeholder to define:

key business goals of the project (increase user adoption, reduce support costs, etc.)
user experience metrics (efficiency, learnability, etc.)
which personas or user types to target
key use cases or user tasks
the top features and functions
relevant technologies that will affect the user interface
branding guidelines
etc.

Try to limit the number of stakeholders here to 6 people. Good luck with that.

Some of the stakeholders won’t have data or opinions about some of the questions, and that’s fine. They can skip those questions.

Analyze and summarize the data, and present the results to the stakeholder team. Get everybody in one meeting, and point out where there is agreement and disagreement. Where there’s disagreement (and there might be a lot), get the stakeholders to discuss, iron out the differences, and achieve alignment/Nirvana.

Often, stakeholders disagree because they rely too much on their personal opinions and guesses instead of on data from customers and end-users. You can make this whole process go smoother if you are armed with good data to inform the team’s decisions.

Filed under: Design, Process_and_Strategy | Permalink

June 05, 2008

Displaying the site map on every page

Someone on our website redesign team wants to include a list of 100+ links at the bottom of every page (to mirror Salesforce.com’s approach). Are a lot of companies including essentially their site map on every page?

Most sites don’t put their site maps on every page, and certainly not 100+ links. Doing so clutters each page and makes the content hard to scan and read. It also increases scrolling, which annoys some users.

Our advice instead is to perfect the information architecture, navigation and terminology in your site, and make the site map easy to access (if you are convinced you need a site map).

Why do some sites list a bunch of links on every page? For some companies, it appears to be search engine optimization (SEO). However, our experience shows that these lists often do not provide high value to users. If SEO is a big concern, then you might try it, but keep in mind that search engines are pretty sophisticated these days and don’t give much weight to extra “keywords” on the page.

Filed under: Design, Content | Permalink

February 27, 2008

Removing left-hand navigation

Our consultant recommended removing our site’s left-hand navigation on top and 2nd-level pages (and making it an option only on the 3rd level), and instead integrating the navigation elements into the main content well. Is this a newly accepted best practice?

Your IA consultant may have good data on which he is basing his suggestions. End-user data would be very valuable.

That said, general best practices you want to consider include making navigation and terminology predictable and consistent.

Navigation and terminology should be predictable, meaning that the information is where users would expect to find it and the name or label of the information clearly and accurately describes it.

Be consistent with your navigation. Your current website has some sections where the left side is totally redundant with the top horizontal 2nd-tier navigation, while elsewhere those areas offer different navigation options. You should pick one method and stick with it: Either 2nd-level horizontal navigation drives the next level of navigation on the left that is unique to each page, or eliminate the 2nd-level horizontal and deliver 2nd-tier navigation on the left of each page.

Filed under: Design, Usability | Permalink

March 22, 2007

Wizards for startup pages

For setup pages which are generally only used for getting started, do you recommend wizards to guide the user through the steps?

Wizards are very useful in some circumstances, but can be very annoying to users in others. When deciding on whether wizards are the right approach, consider the experience and skill sets of the users who will be responsible for setup pages.

If the users of the system you are developing regularly configure and set up similar systems, then a wizard approach, which usually takes more time and chunks data into smaller subsets, may annoy and frustrate those who just want to check boxes for preferences and get started using the system.

If, however, users of your system will have to make fairly complex choices that include words and preferences that they may not be familiar with, a wizard may be the best choice.

Other considerations include the length of the setup pages. If a setup page is really only one or two pages, it might be best to keep the information short and provide appropriate within-page links to more help.

Filed under: Design | Permalink

March 15, 2007

“Rabbit hole” hierarchies

When is a hierarchy too deep, and what are the alternatives to using a deep hierarchy to access and organize information?

Hierarchies are often abused, plagued by issues that can lead to a frustrating user experience. Hierarchies can become overloaded, creating an Alice in Wonderland-like experience down a never-ending rabbit hole. Besides being tedious to navigate, deep hierarchies can take up valuable horizontal screen real estate. They can cause extra clicks to resize windows or force the user to guess at the truncated information. Large hierarchies can also introduce performance issues, taking several seconds to expand a single node.

When a hierarchy becomes overloaded, it’s time to examine the design of the user experience at a higher level. Ask whether there’s a better way to organize the information architecture or overall navigation scheme to take some of the burden off of the hierarchy. For example, some of the higher-level nodes in the hierarchy should be broken into separate navigation.

Another remedy to the overload dilemma is adding a drop-down or other filters that limit the information displayed by one or more attributes. For example, add a drop-down above a hierarchy that filters the information contained in the hierarchy by date or status.

A more sophisticated solution to improving the hierarchy experience is adding search functionality. Searching a hierarchy allows the user to drop into it at a deep level without having to make the entire trip down the rabbit hole. Searching can be as simple as a keyword match, or something more in-depth, like providing entire paths as a result set.

An example of this is eBay’s revised navigation paradigm for classifying items on their site. Previously, eBay users had to click through five or more levels to ensure that an item for sale was listed in the proper category. For example, suppose you wanted to sell a coffee press on eBay. To ensure that it was displayed in the right category, the user would traverse a path similar to this:

collectibles > home > kitchen > small kitchen appliances > coffee making > coffee press

The above example illustrates a seven-level hierarchy—and that’s for those who know what they’re doing. There are many decision points in categorizing an item that may cause the novice eBay user even more clicks. eBay’s new navigation adds a search paradigm on top of the hierarchy structure. Users save time by searching on the name of an item. eBay then suggests a categorization(s) or path for the item. The paths that best match are auto-assembled for the user. The user can choose a suggested path in its entirety, or customize parts of it.

There’s no hard and fast rule when using hierarchies. Their use really depends on the situation and the user audience. However, if users need to go more than three or four levels deep in a hierarchy, it’s worth examining other options.