How to make personas useful (and it’s not stock photos)

Personas are a popular user experience deliverable, whose purpose and use are often misunderstood. This article suggests ways to make personas useful, and not just a pretty face.

As a UX consultant, this was a familiar scene: our team had worked late hours for this Friday client review. The deliverable this week: Personas. After 4 weeks of user interviews, the client was getting anxious: were these expensive consultants going to do something, or just suck up money? We distilled all of what we found into rough types; argued about the details; was this detail enough to warrant another Persona, or were 5 too many already? We put together a slick presentation and the client was suitably impressed. Tired but happy, we went home for the weekend. Months later, the project finished and I realized that, as successful as they seemed, the client and the team really didn’t do much with those Personas. Was it all just a waste of time?

What are Personas?
Many websites and software applications have multiple types of users with different needs. A data entry clerk uses an application differently than an account manager. Designing for only one user type and ignoring others’ needs leads to unsatisfied users, while mixing functionality for different users is a common cause of confusing software.

A persona is a fictitious character that represents the specific goals and needs of a type of user for a website or application. They summarize user research and business knowledge, helping the project team and stakeholders keep in mind the sometimes conflicting user needs.

Personas are used to:
• Enable stakeholders to understand users and prioritize features and functionality
• Keep the entire team focused on the goals of real users
• Add detail to use cases, describing the “who” doing the actions
• Recruit real users for usability testing

There are a number of excellent books written on the care and feeding of Personas (1).

Advancing Advanced Search

Published on Boxes and arrows on 16 Jan 2008
16 Jan 2008

Advanced search is the ugly child of interface design -always included, but never loved. Websites have come to depend on their search engines as the volume of content has increased. Yet advanced search functionality has not significantly developed in years. Poor matches and overwhelming search results remain a problem for users. Perhaps the standard search pattern deserves a new look. A progressive disclosure approach can enable users to use precision advanced search techniques to refine their searches and pinpoint the desired results.



Fig. 1: A typical separation of standard and advanced search (Yahoo!). The design discourages use of advanced search.

In the quest to make web sites more usable, we settled on a pattern of a clean, minimal search box with a link to an advanced search page. Jakob Nielsen recommended, “use an intimidating name like ‘advanced search’ to scare off novice users from getting into the page and hurting themselves.”(1) This model has been successful. Search rivals hierarchical website navigation on many sites and is the primary means of navigation on enormous sites such as Ebay and Amazon. Advanced search, however, has not fared so well, with only a small percentage of users using it.

Why most people don’t use advanced search

Despite its name, advanced search has not advanced very far. There is great power to conquer the overwhelming number of search results, but the current standard presents barriers to users. Specifically,

• The link is often small, vague, and does not describe benefits to the user
• Advanced search pages typically have confusing page design for the few who make it there.
• There is generally poor search revision functionality: Once a search is performed, the “advancedness” is lost. For example, the Google advanced search delivers the standard search results page. You have to get the query right the first time; there is no opportunity to adjust your query.

Fig. 2: Google’s advanced search is still complicated.

Who does use advanced search?

Tim Bray wrote, “The people who do use Advanced Search are your most fanatical users, the professional librarians, spooks, and private investigators.”(2) As in many situations, segmenting a population makes it harder to see whether the needs of a subgroup are shared by the majority. Current design is based on the idea that there are two separate audiences with distinct needs. The reality is that there are overlapping needs that are limited by the search pattern.

The essential problem of search — too many irrelevant results — has not gone away.

A typical user has to make a choice between doing a search and clicking a link to do a search. In other words, do you want it now, or want to go somewhere else to look? The immediacy of the search text field and the complexity of advanced search means that users will try the text search first.

Perhaps the old framing is wrong. Rather than being a matter of geeks versus normal people, the question should be whether users see a benefit to advanced search on starting. Unfortunately, there is typically no way to use advanced search at the point users realize they need it — when they haven’t found what they were looking for and have too many search results. They have “missed the exit” to advanced search. Users don’t want to lose the investment in their search; they need a way to use additional techniques to work with what they have. A new model of search can help with this problem.

Other approaches to search

Let’s take a quick look at other search innovations from the last decade. Web data has matured and become more structured. Taxonomies and tagging are now common. There are new opportunities to deal with search results overload by filtering, as long as it is clear and easy for the audience. Despite the truism that users will not go past the first page of search results, they will use obvious tools to refine their searches.

Searching by defined parameters is natural in some circumstances (for example, airline ticket searching) but the majority of sites are not sufficiently data-driven to have an interface designed around the data.

Fig. 3: travelocity.com Flight searches, in a sense, only use advanced search.

 

Tags can improve search results by better describing what someone is seeking.

Fig. 4: amazon.com’s approach to tagging a product

Faceted searching, or returning browsing categories in the search results (as eBay does) can be effective at prompting the user to select a single category.

Fig. 5: ebay.com’s faceted search

Filtering search results

Amazon and Kayak offer filters to enable users to reduce many results to a few. This can be very effective, but there are obvious constraints due to the limited space available for each filter. Only the first few filters are visible when the page loads.

Fig. 6: Filtering on amazon.com and Kayak

Another approach: Progressive disclosure of functionality

One solution to the essential problems of advanced search discoverability and complexity is to progressively disclose (3) the functionality to the user. Instead of a single, complicated page, break it into understandable units and give each to the user when they ask for it.

In this example, show the ways the user could filter the results (e.g., “Brand” or “Price”) in a highlighted banner above the search results.

Fig. 7: Filters highlighted in a banner (it doesn’t have to be green, it just has to stand out!)

When the user clicks a link, display the filter with enough space to clearly articulate how to use it. Don’t cram it in; the user asked for it. In contrast to the left-hand column filters in the examples above, which are naturally space-constrained, this method can hold many more types of filters and doesn’t show functionality they didn’t request.

Fig. 8: When the user clicks "price" above, give the module enough space to be readable.

Let’s look at an example scenario.



1. The user performs a text search normally.

Fig. 9: Searching for a DVD player using the simple search box

2. On the search results page, show options to filter the search in a prominent location above the results. Communicate the value of filtering. Order them by popularity, using size and font weight to highlight others. If there are many options, consider hiding rarely used options under an expandable section.

Fig. 10: A search results page, with options to filter.

3. When the user clicks an option, display a page module for that search parameter without reloading the page. The user should be able to change the parameters at any time to receive an updated search. If possible, show the number of results for each parameter, so the user can see how exclusive it is, and identify which parameter maybe giving them 0 results.



Fig. 11: The search results, filtered by price.

4. Enable the user to add several modules, stacked in chronological order as the user builds up a complicated query.

Fig. 12: The search results, filtered by price and rating.

Recommendations

Define an implicit method for Boolean rules (AND and OR rules) based on normal search patterns — do not ask users to compose Boolean queries. A system that has worked for me is this: If a user selects several different search parameters, perform an AND search between them (e.g., Sony AND Portable). If they choose multiple values for the same parameter, perform an OR search (e.g., Sony OR Panasonic). However, if parameters (such as product features) are clearly non-exclusive, perform an AND search (e.g., Portable AND “HD ready”).

Recognize that quick searches, text searches, and advanced searches may be built with different technologies (e.g., direct database searches, a Google box, or a content management system). You may need to work closely with the developers to make a seamless transition between technologies.

If there are many parameters (more than 15), consider reducing complexity by hiding less used ones under a “see more…” link below the displayed options. Clicking it should display all the options without a page refresh. Evaluate your search logs to make sure you are exposing the right ones. Consider rotating the exposed ones to discover potential popular features, as exposed options will naturally get more usage.

Conclusions

At its core, advanced search is an under-utilized tool hampered by its own design. By enabling the user to add specificity as they request it, designs such as the one above avoid the lonely fate of the standard advanced search page. Defusing this complexity and locating it where users will naturally find it will help advanced search be truly advanced.



References

(1) Nielsen, J. (1997). Search and You May Find. Alertbox, July 15, 1997.

(2) Bray, T. (2003). On Search: The Users.

(3) Wikipedia. Progressive Disclosure

What I learned from my failed web 2.0 project

From April till December 2006, I conceived, designed, and coded survee.com (see some cached pages), an attempt to

• build an new approach to online surveys
• explore AJAX coding
• Start a company
• try out new interaction models

Though I dropped the project, it was very satisfying and it taught me some lessons. I'm attempting here to make those clear to myself and perhaps others. This project was no big deal in the grand scheme of things, but perhaps it will provide some entertainment: here are my rough notes

When I started the project, I was very comfortable with my job and looking for new challenges. After learning about all the change that had happened to browser scripting (for example DOM scripting and XMLHTTPREQUEST, aka "AJAX") since I had stopped doing JavaScript in disgust in 2000, I was excited about the possibilities and wanted to try them out. As I am a User Experience designer/ analyst in my day job, I was also excited about the UI possibilities, and felt that the best way to come up with new ideas was to invent something. I was coincidentally unhappy with the survey tools I used (surveymonkey.com and many others) and thought this was a good opportunity, particularly as surveys consist of user-generated content. I wanted to make a tool, not a site. It was a heady time; 37Signals "Get Real" was an inspiration. After 11 years of designing sites for other people, I was in control of my own project. Sole responsibility was a great feeling.

I surveyed some friends, who thought this was a good idea, then I started designing.

I followed some interesting current ideas, including separating content from style & behavior. I learned about the power of CSS and was much impressed.

I decided to make an AJAXy interface with each survey being stored in one HTML document.
and all interaction (showing one question at a time was a key design idea) done via javascript. The same document worked for non-Javascript browsers through careful use of stylesheets. (I was very proud of this questionable feature.)


Some things I learned:
It was a lot of fun and very fulfilling. Having your own company is great. YOU did it. Plus coding something that then works is a great feeling.

It's hard to do it alone! Having someone who

1. understands what you are working on
   
2. cares

is very important. My wonderful & supportive wife has no interest in browser javascript incompatibilities (luckily for her), but when you are hacking your way through something, it is crucial for long term survival to have someone to vent to. Get a partner. As someone said: if you can't convince one person to join you, it probably isn't that good of an idea. I didn't try very hard and I couldn't figure out what I wanted to share or how to divide the work. I asked 2 people I respected, but asked too late; perhaps I was too possessive to want to share.

Other people's attention is INVALUABLE! and surprisingly hard to capture. Your best friends do not want to spend their time talking about your project. Just because it is exciting to you does not make it so for them. You become in a sense, crazy; focused on something other people don't care about (yet). Yet if you don't talk about it, you lose heart. It is hard to find out how unimportant it is to other people: that 5 minutes of time you were asking for to look at it never happens.

You have to be disciplined. I think I did OK on this. We have no TV and I canceled Netflix. I worked on it 2 hours a day and stayed up late on weekends. I stopped reading books. But it is a marathon, not a sprint.

Starting a company has to work at this time in your life. We had a baby during this time, and in the end, the lack of sleep and desire to play with our new little guy won over the project. Also, I got a great new opportunity and changed jobs. Both wonderful changes, but doom for the project. I imagine that just-post-college kids have an edge here. Every decision to work on the project is a decision to NOT do something else. For those of us who have a life: family they enjoy, a house that needs repair, cooking, washing dishes,etc , life is the real competition. A single person eating take out in an apartment is a better situation.

I had thought, after a year of hard development, I can iterate more slowly and have a life. I didn't get there.

Test it on real people. this keeps you honest. Spend time every day watching someone use the tool. Buy them coffee in a Internet cafe or something.

I should have used that most common browser for development. I worked on a mac (with Windows running via Parallels for testing). This was a mistake. My excuse: IE has poor javascript error communication. This lead to less focus on bug fixing and avoiding IE incompatibilities. I always made it work on IE, but it took longer than it should have.

You have to make each annoying development step as easy as possible, otherwise you won't do it as often as possible. Make browser shortcuts, write scripts, whatever. This is a marathon. Make your office / workspace comfortable.

Iterate in public. I fell into the trap of not rolling things out often enough. I kept adding features and delaying promoting it. "Once it has [rich text editing, whatever] people will really like it." This gave me cover to avoid facing the real word.

Build the application around the "help" content. Don't explain the how something works, focus on what it should do and write the text first, then design the way it works. I would reserve a column for it in the interface and make an initial animation highlighting it.

Technologically, we are not there yet. Expect to spend most of your time on stupid details. I decided to not support any pre 5.0 browsers with my Javascript version to keep me sane, but even so, there are still many annoying barriers to developing good ideas for people, for example browser incompatibilities, MySQL variations between the versions on my local dev box and my host, etc. My head is full of some of these quirks, which I will forget very soon and anyway will be solved and replaced with new ones.

Comment everything ad nauseum. You, or at least me, will forget everything in a few weeks. You are not writing it for others, but for your future self. Imagine you have memory loss like the movie MEMENTO. Don't just explain what is happening, explain WHY you are doing it. "This is because of an IE6 bug"


There are some ideas I was happy about in the project.

I tried out what I call EIAE Everything Is Always Editable. I had no display mode and editing mode. If you saw some text, it was an editable field. This was more javascript, but it was cool. Perhaps a bit too cool as people did not expect to change their password so easily, but in general, I think this is the future.

I cut through a lot of the user blocking interfaces. Disk space is cheap. Signup took 2 fields: email and password. If you clicked "try editing a survey" you got an account, all you needed to do was change the email address. If there were a lot of garbage abandoned accounts, I'd clean them out later.

I only got to do part of what I had initially envisioned regarding graphing (one of the main reasons I started the project in the first place). but the little I did, I think was clean and clear.

In the end, I think it was a good design, but I didn't have the time to really bring it to market. The effort of publishing and promoting was a lot more than I expected. A partner with knowledge might have changed this.

I'd like to do it again. (Once the kids are grown up a bit.)

Automatically Create Table of Contents in Visio

I use Visio to create wireframe documents, and as updating Tables of Contents in Visio is very dull, I wrote a macro (a small program) that automatically generates a Table of Contents list for a Visio document. It is stored in a Stencil.

The Table of Contents format is:
1 First Page
2 Another Page
3 Etc Page

(Where the page title comes from the page title seen in the tabs at the bottom of the page.)

How to use:

• Download Table_of_contents_creator_macro.zip , unzip and save to your My Documents > My Shapes folder
• Open Visio
• Go to Tools > Macros > Security

• Set Security to Medium (to allow Visio to run Macros)

• Close Visio
• Open a Visio Document
• Select a text box that you want to put the table of contents in
• Open the Table_of_contents_creator_macro.vss stencil
• Choose to enable macros
• Select the text box you want the Table of Contents to appear in (or it will create a new box)
  
• Select Tools > Macros > Table_of_contents_creator_macro > Module1 > Table_of_contents_creator
• That’s it!

Here is the code itself (you would write this in the visual basic editor in Microsoft Visio)

Sub table_of_contents_creator()
'this macro creates a table of contents in a visio document by
'going through the pages in the document and adds the page number and page title

'by stephen turbek s@stephenturbek.com
'written for use in microsoft visio 2003 SP1

'adapted from http://www.greenonions.com/tocscript
'I added allowing user to select a text box and replace the contents, rather than build lots of little boxes
'this way you can style the text easily, and simply replace the contents when you update the doc
'note: this is my first VB script


' define a shape to use for the Table of Contents (TOC)
Dim TOCEntry As Visio.Shape


'get selection
Dim selectedShapes As Selection
Set selectedShapes = ActiveWindow.Selection



'is any shape selected to put the ToC in?
If selectedShapes.Count > 0 Then
'take the selected shape to put the table of contents in
Set TOCEntry = ActiveWindow.Selection.Item(1)
Else
'nothing is selected, create a shape
Set TOCEntry = ActiveDocument.Pages(1).DrawRectangle(1, 1, 7.5, 10)

TOCEntry.Cells("VerticalAlign").Formula = "0" 'make text box top vertically aligned
TOCEntry.Cells("Para.HorzAlign").Formula = visHorzLeft 'make text box left aligned


End If



'clear out the shape's text
TOCEntry.Text = ""

'a variable to hold the page array
Dim PageToIndex As Visio.Page


' loop through all the pages
For Each PageToIndex In Application.ActiveDocument.Pages

'exit when it hits the first background page (don't want those in the ToC)
If PageToIndex.Background Then Exit For

'append the page number, a tab, the page name, and a return to the ToC text shape
TOCEntry.Text = TOCEntry.Text + CStr(PageToIndex.Index) + vbTab + PageToIndex.Name + vbNewLine

Next


End Sub

Labels: table of contents, visio, visual basic

Real Wireframes Get Real Results

“Just because project teams understand the purpose of wireframes, that doesn’t mean everyone will. Similar to listening to someone sing out loud to his iPod: we only hear the singing, while the person hears the whole orchestra.”

How many times have you been asked, “So, is the new website going to be black and white too?” after presenting your wireframes to a client or a usability test subject?

This question is almost a traditional part of being an information architect. Wireframes do not clearly define what they mean to convey, leading to confusion. This is most apparent in wireframe usability tests with users who don’t know anything about the project or process. Fortunately, there are a few simple steps that will make wireframes be understood by anyone. They don’t even have to be much more work. It’s simply a matter of choosing to “get real” from the start.

Real people don’t understand wireframes
Usability tests are done to get early feedback on content and functionality decisions from people outside the project team. These participants, unfortunately, are not sure how to respond to a wireframe. It is not intuitively clear what they should be doing, which site they are looking at (public site, intranet, client site)—it may not even be clear that they are looking at a web page. This lack of information and context adds a bit of cognitive friction to each step in the process. This level of confusion results in less confident answers and fewer opinions.

Wireframe tests usually take place with well-meaning, but unsophisticated users. They generously accede to poking and prodding and answer questions as best they can, despite not exactly understanding what is wanted. This realism gap is due to the lack of definition of what should and should not be looked at. “Look at the field names but not body copy.” “You can look at the forms but not images.” “Comment on the page layout but not design, and, yes, the font size but not font.” It’s no wonder that the layperson is confused.

Visual affordances, such as color and underlining links are key to using a site, and these cues make a significant difference in a usability test. Users cannot confidently predict how they would use a page if they don’t recognize links or can’t read what the page expects them to. Information architects, however, tend to shy away from these cues because they don’t want to step on designers’ toes. Wireframes, after all, are not designs.

Or are they?

Avoiding “design” elements removes visual cues that users rely on:

• Color, which identifies hyperlinks and focuses the user’s attention on an element of the page
• Branding, which confirms that the user knows where they are
• Recognizable web page elements, such as forms and search fields
• “Content,” such as account numbers or product names, which allows experienced users to focus on how they would really use the page, instead of interpreting “lorem ipsum”

The boundaries of the role of the information architect shouldn’t be more important than clarity.

Originally the term “wireframe” referred to a quickly rendered 3D model showing the model’s structure used while the model maker was working. They were much faster to work with than the full rendering. Interestingly, they are not currently used as modern tools and techniques are fast enough.

Why wireframes?
Information architects construct wireframes instead of designing final pages, in part, because:

1. Wireframes are faster.
2. Information architecture and design phases can happen in parallel.
3. Wireframes force viewers to focus on the content, not the visual design.

Notice anything? All these goals are internally focused on the project-team. Wireframes aren’t created for external audiences.

Figures 1,2: Originally the term “wireframe” referred to a quickly rendered 3D model showing the model’s structure used while the model maker was working. They were much faster to work with than the full rendering. Interestingly, they are not currently used as modern tools and techniques are fast enough.

Wireframes are conceptual models of a page that web design teams have become to interpreting. Each wireframe is surrounded by experience in reading them, knowledge about the project scope, knowledge about how the designer will use the document. Liz Danzico writes about this wireframes becoming project memory in the article “The Devil’s in the Wireframes.”

Just because project teams understand the purpose of wireframes, that doesn’t mean everyone will. Similar to listening to someone sing out loud to his iPod: we only hear the singing, while the person hears the whole orchestra. Likewise, the test subject knows only that “the page isn’t going to look like what they see,” but what they see is all they have to react to.

Wireframe makeover
Here is an example of the simple steps to transform a standard wireframe into a realistic wireframe. In this example, let’s say we are designing a registration process for Verizon.com (no special criticism is intended for the site below).

The site we are designing for Verizon.com:

Here is a standard wireframe:

And here is the same wireframe, made more real. (An additional 10 minutes was required to use the standard header and a library of realistic form elements in Visio or InDesign.)

And here is a version re-using Verizon’s standard buttons and clip art. (Additional time: two minutes.)

Which do you think would be easier for test subjects to understand?

Tips to get real
These tips are best for intranets or sites with defined styleguides, and less useful for graphical or marketing pages where the design is the content of the page.

1. Make a header bar with the company branding. It should look like the site they are used to, showing the company logo.
2. Use color. Hyperlink color is a basic requirement.
3. Put a web browser frame around the image (or at least the first page).
4. Use real form elements, not drawn replicas of them.
5. Create a template or library of real form elements (feel free to share yours in the comments below).
6. Avoid lorem ipsum. Instead, use: “Descriptive text that will explain this product.” to avoid confusion about greeked text.
7. Use accurately sized fonts (this also keeps you honest about what can fit on the page).
8. Use real detail such as products names and data. Especially on transactional tools with expert users, users care about what they are reading and recognize and use data like account numbers. It may not be important to us, but they have expectations that need to be met.

Compare the wireframe to the current site, note any changes in functionality that may trip them up.

The page doesn’t have to be perfect, just enough to give the test subject their bearings. A semi-designed page is easier to understand than a non-designed page. This is not wasted work; these decisions need to be figured out at some point. Consider bringing designers into the process earlier, cooperating on file formats and processes. It might even make their jobs easier.

Are traditional roles limiting projects?
Wireframes are in fact the first design iteration, and this overlap with visual design can be uncomfortable for teams. However, denial is not the way to fix this issue. Good collaborative relationships should make this overlap an opportunity to reduce work, not fight over ownership. Concern that wireframe might be mistaken for a visual design, or worse, be criticized for lacking design, may be holding the entire project back. It is much easier to communicate within the project team than the outside audience.

Improving Web Navigation with the "All-Menu" Nav

read the PDF

When DHTML was first introduced, there was much discussion over the complexity of dropdown menus. “Will users know to roll over the menu to display them?” “Can users handle elements that appear and disappear?”

Over time, the desire to include more links outweighed the additional complexity. Dropdown menus are a standard feature of many websites. But usability problems remain.


[image]
The dropdown menu (shown above) is a standard navigation element on many websites. The user moves the cursor over the selected item, causing a menu of items to “drop down”. No special criticism of travelocity.com is intended.

Dropdown menus can be surprisingly difficult to use
It is all too easy to forget that many people are less than expert in using the mouse. There is the inherent difficulty of accurately hitting a small target. Users must be careful to keep their mouse pointer in the proscribed areas. It can be difficult to move the mouse pointer from one menu to another. Many able mouse users have the same problem getting accustomed to a laptop track pad.


Tiny, fragile menus, as shown in this chase.com example above, are more difficult to use than they should be.


Small menus can be difficult to see on graphic-intensive pages
Dropdown menus are designed to be as minimal as possible, perhaps due to a lingering uneasiness with having something "cover" the page content. But when the user is navigating, we should help them focus on their task, allotting as much space as needed.


The tiny menu is lost on this visually complex page.

For even the most experienced users, it is often far too easy to select a wrong item or accidentally roll off the menu item. “Fly out” third level navigation menus are commonly reviled, as they underscore the precise mouse control needed to accomplish a simple task. Navigating is a basic functionality for a website; there should be no stress or difficulty involved in the task. We should question the usability tradeoff of dropdown menus and seek new solutions.

Unclear or overlapping categories require users to compare menus
Anyone who has designed a corporate website has probably found that site architecture is often a compromise among logically consistent structure, competing business needs, promotions, and company culture and values. This can lead to inconsistent, overly general, unclear, or overlapping categories.

The architect of a site sees the navigation as a set of categories, with items “bucketed” within them. The expectation is that a user chooses the correct menu item, rolls over it, and selects the correct item from the list that appears, using the structure of the site to inform the decisions.

Users, however, are not so methodical. They are learning the structure of the site as they are using it. A consistent observation in many usability tests is that the user slowly, carefully moves the mouse pointer over each menu item, reads each menu and finally goes back to the best menu and clicks. In the quest to narrow the menus down to a few likely candidates, a complicated site requires new users to view each menu.

Imagine if a restaurant menu were designed like this:


Many people scan the whole menu to get a sense of the options, then make a choice in context of the whole, for example, ordering an appetizer to go with a certain entrée.


Navigation items give context to each other
A navigation category is defined not only by what it contains, but also by what it doesn’t. Users are often looking for a subject that may be poorly defined on the site, often referred to as “___ kind of stuff”. They will compare menus against each other to find the most likely area. Knowing all the options enables users to make the most informed choice.

Sites with unclear or overlapping categories require the user to compare and evaluate (e.g., Is my cell phone plan a “product” or a “service”?). Individual dropdown menus are not easy to compare. Users will move their mouse from one item to another, searching each menu for an item they recognize. Additionally, this action requires precise mouse control.

[image]
In this Travelocity.com example, a plane ticket can be found under “Flights”, “Vacations”, and “Last Minute Deals”.

[image]
In this chase.com example, would IRA retirement planning be found under “Individuals” or “Advice & Planning”? (Answer: Both, suggesting the architect knew it to be unclear.)



Seeing all the options
As we know from usability studies, users often do not think about navigation hierarchically, but often scan the page looking for a particular word. In studies of breadcrumb navigation, for example, the breadcrumb links weren't used directly but had the unanticipated benefit of containing the word the user was looking for.

An old solution to this problem was the sitemap. A popular navigation feature, the sitemap allowed users to see all the navigation options.


[image]
Volvo.com sitemap

[image]
Amazon.com has a menu not unlike a sitemap.


In sum, individual dropdown menus are poorly suited for users who are unfamiliar with a site, especially one with unclear navigation categories.

One solution: The “all-menu” nav
The “all-menu” nav displays a wide field, showing all the menu choices, highlighting the column and items the user has moved their mouse over.

[image]
The Navicorp site

[image]
The user has rolled over the navigation bar, displaying the all-menu navigation layer. The “Services” column is highlighted.

[image]
The user has rolled over “Service Industries”, highlighting it.
The "all-menu" nav offers a number of benefits:
It enables the user to quickly scan the options available without moving their mouse. The highlighted column helps focus their attention on what they have selected, reducing the added visual complexity.

The "all-menu" nav is easier to use
The user will find it much easier to move their mouse pointer to another sub-menu item. Menus are not fragile and do not disappear as the user moves across categories. This increases speed and accuracy, benefiting all users. The large backdrop field makes it easier for the user to focus on the navigation above a vibrant and visually complex page. Helping the user avoid distraction during the fragile moment of navigation will assist them in accomplishing their task.

The "all-menu" nav makes it easier to compare navigation categories
Overlapping categories are less of a problem when the user can scan the sub items and compare them. Careful selection of the sub items can clarify what the website means by “products” or “services”.

Best Practices with the "all-menu" nav
The "all-menu" nav is not appropriate under all circumstances and is best used in navigation where:
• one is concerned about ease of findability
• there are indistinct or overlapping categories, (e.g.,"products" and "small business")
• the user is unfamiliar with the site or subject
• the user is in an “exploring” mindset, rather than an “finding” one

It is less useful in situations such as these, where the navigation is too complex:
• more than 7 columns may not fit on a page
• more than 7 rows in several of the menu categories will likely be too many for the user to comprehend (Rarely used items can be hidden in a “show all” link, expanding the menu to show all items.)
• the audience is highly familiar with the site, and in a “finding” mindset rather than an “exploring” one

Conclusion
The limitations of the standard dropdown menu have never been fully addressed. The "all-menu" nav offers a potentially useful design solution to these problems. In general, we should not accept standards blindly, but explore new opportunities to see how we can better help our users. The competing needs of content, promotion and advertising, and navigation will continue to grow. We may yet see navigation layers cover the entire page as users switch between navigating and interacting with the page.

Your Interface is your company

Avenue A | Razorfish whitepaper

Read the more beautiful PDF

Problem
Online interfaces have become the primary way clients transact with financial services firms, yet many of today’s interfaces are poor reflections of these firms.

Solution
Financial services firms should respond through a greater investment in online systems for internal and external users.

Benefit
A user-centered design means fewer help desk calls, happier clients, and more business.

The Financial Services (FS) sector is in a period of rapid evolution: mergers, new offerings,technological change, and increased client expectations mean that firms cannot stand still and thrive. As access to capital markets becomes a commodity, services firms need to differentiate themselves through lower costs or, preferably, the quality of their products and services. They must pay attention to the way in which their clients prefer to interact with them, which is increasingly online --through web sites, portals, and other software.These changes are profoundly affecting retail and institutional lines of business alike.

Tellers and monthly statements notwithstanding,financial services are now largely delivered through online interfaces, as clients have become more comfortable with using the Web for financial transactions. FS companies have essentially become giant software companies: their clients use their online banking interfaces, retirement planners, private wealth management portals,institutional research, prime brokerage applications, custody reporting, trading, and execution systems. In some larger FS companies, the IT staff numbers tens of thousands of employees. Face to-face and phone conversations are too expensive to offer to the broad base of the client value pyramid, and, in any case, client representatives would rather focus on selling than telling a client their balances. These circumstances mean that many clients have little to no contact with an FS advisor. From the clients point of view, their online experience is the company.

New challenges for financial services

Increased competition is leading to commodification

The information gap between clients and FS companies is growing smaller, especially as clients increasingly use multiple companies, engage third party advisers, and become better educated via the internet. With the repeal of the Glass-Steagall Act, FS companies have increased their offerings, leading to unprecedented competition, with more and more ways for clients to invest, manage their holdings, and analyze their portfolios. Information has become easier to access, from Bloomberg terminals, cable news shows, and endless financial web sites.

Fees are under attack on all sides
The new competition has deflated fees across all services. Clients want to know what they are getting for their money and are crossing traditional boundaries between market segments. Even the highest end private wealth management services find that clients use their advice to trade at discount brokers. Now that execution is assumed, advice has become the product. Tighter regulation and litigation also means that greater transparency and disclosure are necessary. These changes require that online interfaces perform new roles and be the main channel of communication.

New technology means more is possible and more expected
The bear market for technology in the early 2000s has been a period of quiet but radical development. Broadband access has become more common as two out of fiv eAmericans now have broadband access at home(Nielsen/NetRatings). New browser technologies provide opportunities for more powerful web interfaces. Application server shave become more stable and powerful. Many of the limitations of older technolog platforms have been overcome, yet the old systems are still in use in many FS IT departments.

These new developments have raised client expectations. Online giants such as Google,Amazon, Ebay, and Yahoo have defined new standards for user experience. In the FS sector, retail brokerage firms have led the way, prompting institutional clients to wonder why their online bank is easier to use than the brokerage applications they use daily.A recent Keane study "FINANCIAL FIRMS PINPOINT ONLINE CUSTOMER EXPERIENCE AS PRIORITY FOR BOOSTING GROWTH" of FS executives found that half of the respondents cited their own technology platform as their largest obstacle, and yet two-thirds rated online services as key to working with clients in the future. New entrants in each area of FS have the potential to leapfrog entrenched competitors by bringing better products to market faster.

Institutional clients wonder why their online bank is easier to use than the brokerage applications they use all day.

You've been saying you are one company, now people actually expect it!
Being one company means more than making sure everyone is using the same shade of blue. It means making your products work in the same way across lines of business; it means integrated reporting and consistent communications. FS firms are notorious for buying and implementing too many platforms. These silo-ed applications show their fault lines quickly under normal use.

People work around bad products, meaning your company may be worked around
All your clients, internal and external, have too much to do. They are in a state ofc ontinuous process and technological change without time to learn or be trained, which leads them to continue in their old processes or create shortcuts that avoid your new systems. This behavior dilutes the value of your initiative, and potentially circumvents the compliance and risk controls your systems have in place.

Your best advocates your client representatives need to be able to understand their tools the first time. Users don't read manuals, so complicated products need to be designed from their point of view, divined from user interviews and confirmed through usability tests. Getting your internal audience to use a new process is harder than simply mandating it. After doing hundreds of user interviews, Avenue A | Razorfish has found that many internal users do not use the full applications or have found their own way tos olve the problem, bypassing a system entirely.

Non-compliance or under-use of internal systems is an endemic and hidden problem in financial services firms.

In one example we observed, agents in a financial planning firm used homemade prospect lists rather than use the company's prospect system because it was cumbersome and slow, rendering an entire new business projection system worthless due to bad data.

When internal users avoid one of your systems, it is embarrassing; when clients do so, they are taking the first step towards switching to a competitor.

What can be done

Each of these challenges points to a future of greater disclosure of information and increased competition in quality of service. FS companies should respond through greater investment in their online systems for clients and internal users. A strategy for investment should include research into how your clients work, detailed audits of your current applications and processes, and a plan for upgrading to the next generation systems. The following are some good practices.

User-centered design
User-centered design (UCD) is an approach to application development that works from the outside in. A UCD project researches internal and external user goals to create an accurate and realistic project definition. Only by satisfying the end user will a project be successful, no matter how advanced the technology or how well it matches how a company wants its clients to work. Creating applications that users want to use means fewer helpdesk calls, happier clients, and more business.

Research, research, research
The obvious foundation for user-centered design is finding out what your users want.Research what clients want and test what you are going to deliver no more projects spawned from hallway conversations. Many FS companies are hesitant to interview their clients, but we have found that most people are happy to give their opinion about their work, especially if they use your product often.

There are three good times for doing research in a UCD project:
Before development starts, interview users. Find out why clients are using your products and why they are not.

During development, test wireframes, prototypes, and beta applications.

After development, survey users and measure usage to identify new improvements.The result is feeling confident that you know what your clients want and that the

Build applications like startups
While your research is beginning, set up a small team to build the application and a small committee with the authority to review and approve quickly. Explore rapid application development techniques to prototype applications and determine what will be required before you build the enterprise application.

Follow user experience guidelines and best practices
Much research has been done on how users respond to interfaces, and a set of best practices has emerged. A good user experience adviser can help a team avoid building confusing and frustrating products. Steve Krug’s book “Don’t Make Me Think” is an excellent entry point.

Look for radical simplicity
Find ways in which you can satisfy most clients by doing less. Apple, Google, and Palm are good examples of companies that focus applications on the essential goals and avoid tangential elements. Ask questions like, “Does this new application really need a contact management tool, or does the rep already have that worked out?”

Look outside FS for inspiration
Financial services interface problems are difficult but are not unique. Exciting work is being done in the consumer retail and media spaces that should be analyzed for benefits. The web has spawned a culture of sharing interesting tools and techniques; encourage your developers to learn and share internally.

Take advantage of new interface tools
AJAX and Macromedia Flex are two new technologies that deserve special attention. AJAX is a technique that allows your developers to create application-like web pages, for example having a trade form identify mistakes and suggest corrections without loading a new web page. Good examples of this are found at http://maps.google.com and http://www.flickr.com. Macromedia Flex enables developers to build rich interfaces with animation and graphing on the fly.

Link internal divisions
Focusing on user goals means putting aside internal chains of command, which can be the hardest part of a user-centered project. Users can have multiple relationships with your company, but it should never be apparent to them that they are being handed off from one division to another. Too often, divisions create applications solely for themselves. Instead, companies should foster a culture of “internal API’s” (Application Programming Interfaces –ways of making your software work together) – and publish ways divisions can access each other’s data and software.

Many organizations have technology departments attached to each line of business, which encourages an uneven user experience and often unknowingly duplicates work. Companies can bypass this barrier by encouraging a culture of “internal open source.” Developers respond well to soft incentives, such as fame for publishing good work. Facilitate this behavior with an online code repository and message boards. Create an internal style guide to give direction for visual design and interface issues, and let your users suggest changes to it. This “live” documentation encourages your developers to continuously raise standards and enforce consistency.

Conclusion
Financial services companies are faced with a growing number of challenges that require better services and competitive offerings. A user-centered design approach can help focus development on the right answer by asking the right questions before, during, and after a product is launched.

Better practices for rich internet applications in financial services

A presentation at the 2006 Boston Usability Professionals Association Mini-Conference

see the PDF (1 meg)

Presentation on Research and Workflow Techniques

Research and Workflow Techniques: Designing complex applications with digital and manual components
Stephen Turbek and Mary-Lynne Williams

Presented to the Intranet Benchmarking Forum, 21 March 2006

This presentation summarizes techniques for designing complex applications, though as always with presentations, much more was said than appears on the slides.

PDF version
Powerpoint version

The Lazy IA's Guide to Making Sitemaps

by stephen turbek


Published 29 Jan 2006 at boxesandarrows.com and Edited by Liz Danzico

This article further develops the excellent Automating Diagrams with Visio by Michael Angeles.

Sitemaps are common deliverables, desired by clients who want a visual representation of a site. Since they are rarely used to make decisions, information architects may not consider them the valuable tools they are. The effort required to make and maintain them requires time that might be better used elsewhere. In fact, I would suggest that making sure the little boxes line up is a waste of an IA’s mental abilities.

Especially when your sitemap looks like this.

So what is an IA to do? Turn to Excel, of course. Storing sitemap data in a structured data format such as Microsoft Excel makes the data easy to edit, easy to share with the team, and easy to elaborate on (e.g., adding example notes and URLs that may not be appropriate for the map itself). Unfortunately, this approach requires maintaining a spreadsheet in addition to maintaining the visual sitemap.

Or does it?

This article includes step-by-step instructions on how to make sitemaps with:
1. Excel and Visio 2000 or Visio 2003 (Windows only)
2. Word and Inspiration (Mac OS and Windows)

Use these lazy techniques and spend your time on better and more interesting problems than lining up little boxes!

Techniques

I’ve chosen these three options because they use standard applications that store the sitemap data in a format that can be edited by non-IAs. Each option demonstrates how you can store the data in the first format (Excel or Word) and import it into the second program (Visio or Inspiration) to—Voila!—create the sitemap.

You can use this zip file to access all the templates referenced in this article. I suggest doing the exercise once with the sample file to get the hang of it, then editing that file to your needs. The Excel spreadsheet has been written to do some semi-fancy calculations to let you store your data on the import sheet in a nice format and to output Visio-readable data on the output sheet.

Technique 1: Excel and Visio 2000 / 2003

This approach uses the import data feature of Visio 2000 (Note that this feature has been removed in Visio 2003) and (mis)uses the “Organization Chart Wizard” from Visio 2003. You store and manage the sitemap data (the list of links in a structured organization) in Microsoft Excel, save it as a text file, and import it into Visio for quick visualization.

Step 1: Enter your sitemap data in the “Input” sheet in the file “template_for_visio_2000_and_2003.xls.”

For Visio 2003, proceed to the variation below

For Visio 2003, proceed to the variation below.

Step 2: Go to the “Output for Visio 2000” sheet (and pay it no mind).

Save as Type “Text (tab delimited).”

You will see two alerts. Click OK and Yes.

Close the file. You may get the alerts again, hit “OK” and “Yes.” Closing the file is actually important!

Step 3: Open Visio 2000. Click “Open.” Choose Files of Type “Text (.txt, .csv).” Choose the file you just saved.

Step 4: When the dialog box pops up, set Field separator to [Tab] Text Delimiter to “Comment Character to ;. Click “OK.”

Step 5: A sitemap! Edit your sitemap to suit your fancy.

Variation for Visio 2003

Step 2: Click on the Sheet tab “Output Visio 2003” (and pay it no mind). Save the Excel file and close it.

Open Visio 2003. Select the “Organization Chart Wizard.”

Step 3: Select “Information that is stored in a file or database.” Click “Next.”

Step 4: Select “A text, Org Plus (*.txt), or Microsoft Excel file. Click “Next.”

Step 5: Find the demo file included with this presentation “example_visio_2003.XLS.” Click “Next.”

Step 6: Leave these defaults. Click “Next.”

Step 7: Remove “Title” as a displayed field. Click “Next.”

Step 8: Ignore the Custom Property fields (though you might be able to think of some use for the other fields in some interesting way). Click “Next.”

Step 9: You can make sitemaps that span multiple pages. Choose “specify.” Click “Next.”

Step 10: This allows you to define the top Sitemap box on the page. If you follow the Excel template, you can leave this alone. Click “Finish.”

Step 11: A sitemap!

Step 12 Right click on the sitemap to edit properities.

“Arrange subordinates” changes the sitemap layout.

“Change Position” changes the look of the boxes

Technique 2: Microsoft Word and Inspiration

This (mis)uses the flowcharting tool Inspiration. To do so, you format the sitemap in Microsoft Word outline format, save it as a RTF document, import it into Inspiration, and modify the diagram to look like a sitemap. The outline format can also be created directly in Inspiration, but storing the data in Word allows you to better collaborate with coworkers and clients.

Step 1: Outline your sitemap using Microsoft Word’s Outline format. Save it as a RTF file. (Step 1 is optional: you can make the outline in Inspiration, but some users may wish a more accessible format, like Microsoft Word.)

Step 2: Open Inspiration. Create a new file. Open the RTF file.

Step 3: Inspiration converts the RTF file to its own format. You may have to do some minor editing to remove blank rows, as shown above. (See image 26)

Step 4: Click the ”diagram” button at the upper left. What a mess! But click the “arrange “ button…

Step 5: Select diagram type “Top down Tree” and Lower level stacking option “Right.”

Better arranged, but visually lacking.

Step 6: Select all then click the rectangle in the menu bar. Now you can do things like take off the drop shadow, change the fill color to white, change the line color, etc.

A sitemap!

Working hard, hardly working
Sitemaps can be useful tools and are a whole lot easier when you separate the data from the visualization. After you have done these steps a few times, you will be able to update a sitemap in under a minute.

All these techniques can be expanded and improved upon. Let me know what you have done and what works for you. Have fun, but don’t work too hard!

Downloads
This article references the following downloads:

Templates referenced in article (Visio, Inspiration, Excel)

For more information
This article includes step-by-step instructions on how to make sitemaps with:

Excel and Visio 2000 or Visio 2003 (Windows only)

Word and Inspiration (Mac OS and Windows)