One of the dirty little secrets about being an information architect is that most of
It all started so well
- Increase card-sending statistics,
- Reorganize the collection (taxonomy/controlled vocabulary),
- Improve navigation and searching,
- Suggest key places for ads and promotions (need to “monetize”),
- Find an approach for organizing the music greeting collection,
- Improve the checkout process.
The team consisted of four Argonauts: a Lead Information Architect (myself), an Assisting Information Architect (Michele de la Iglesia), a Project Manager (Shawn Stemen), and a Usability Specialist (Keith Instone) who worked part time on the project to advise us.
We began our work by conducting a strategy and recommendations phase, knowing that Egreetings was hoping for major look-and-feel redesign with the target of a fall 2000 relaunch. An information architect’s approach should always involve an investigation of the content, the organizational context and the users. Often the user research part of the methodology gets less emphasis than it deserves because of time and budget constraints. However, this project contained user testing and research during each phase.
Furthermore, we encouraged them to create controlled vocabularies for these facets so the cards could be consistently indexed. We also delivered wireframes at this point, including one for the new main page of the site to show how to integrate our taxonomy suggestions into the site.
In addition, we drafted lists of controlled terms for the other facets. Then we tested these with users and made changes accordingly. After we delivered the new taxonomy to Egreetings, we worked with their team to provide guidance on how to apply the terms consistently as they reclassified the entire collection of cards. By the middle of summer, the client was busy handling all of the details and issues that go with a major redesign.
The problem of search
At that point we began our work on the search interface, which was planned as a future enhancement to be added after the fall relaunch. From our first meetings with Egreetings, there was controversy about how to best implement search. From the experience of the Egreetings team and our own observations during testing, we knew that users were strongly drawn to browsing rather than searching when selecting cards. This has a lot to do with the mental model formed by shopping for traditional paper cards. However, after talking to several rounds of users, I felt that I had a good idea of what they would want in a search interface. While the majority seemed to enjoy the shopping and browsing process, there was a great opportunity to shorten this process for people in a hurry. Many users came to the site with a particular occasion, recipient or emotion for a card in mind. Some also looked for particular types of subject matter or images.
For a time, the site included a search interface which was intended to allow users to select different card criteria from categories like “collection” and “publisher.” There was a lot of overlap between these categories, and users frequently got zero results when they selected more than a few choices. We didn’t shed many tears when technical changes to the content management system made this search interface disappear by surprise. This allowed us to start from scratch.
Most search interfaces offer an open text box for a user to type in a query. In this case, we felt that the ubiquitous search box could be optional. Egreetings was cautious about getting involved with a search engine vendor because of the costs involved. From a practical perspective, any free-text search on a collection of a few thousand objects (rather than hundreds of thousands of objects) would need to be fairly sophisticated in order to avoid offering users null results. We felt we could provide a great deal of utility to users by exposing the choices and controlled vocabularies for selections that would be guaranteed to deliver results. The content management database Egreetings had built could be adapted for fielded searching.
Lastly, I had some definite opinions and ideas about how search should work:
- I felt that search should leverage the work we had done to define the facets and metadata for the cards.
- I was inspired by sites like Epicurious and Virtual Vineyards. These sites combine searching and browsing via databases of content objects and products that are well classified with rich metadata.
- The new search interface should NOT disappoint users with an empty results page. On an ecommerce and advertising site like Egreetings, it is important to suggest something to the user even if it doesn’t meet all of the criteria.
With these parameters in mind, I set out to create draft wireframes of a design. My philosophy was that by using a step-by-step wizard interface, we would create an interface that would be a shopping assistant to the user, which would allow them to narrow their choices down using faceted criteria. Each page of the wizard would concentrate on a separate facet. This would give users a reasonable number of cards to browse while making it less likely that they would be returned null results.
When we next met with Egreetings they liked many of my ideas, especially the
The test
The test took place over the course of three days with 12 users. We used a market research firm in Southfield, Michigan to recruit a variety of representative users. We were lucky enough to be able to perform the tests in this firm’s well-appointed facilities, complete with a two-way mirror for observation and videotaping equipment so that Egreetings could also review the tests.
While planning this round of user testing, I got really excited about the idea of prototyping and how to get the most out this kind of test during the design process. A colleague and close friend, Dennis Schleicher, had just returned from the UPA 2000 conference with some great ideas on prototyping. I found that different professionals had diverging opinions on how to create effective prototypes. I learned a great deal by considering the arguments for both low- and high-fidelity prototypes, and came to some of my own conclusions about how to conduct this particular test. (See What IAs Should Know About Prototypes for User Testing for some of my ideas and research on prototyping.) After some pondering, we decided to proceed with testing the search inputs with a low- to medium-fidelity prototype created with Visio printouts that we cut up into pieces users could interact with. This made sense because it meant that we didn’t need much help from the Egreetings technical and creative teams to create high-fidelity interactive prototypes. At the time, they were much too busy with the relaunch to worry about that. However, they did help us by providing some high-fidelity screen comps to use in our test sessions to get reactions from users (we showed one of each style of search interface and another of the main page access points for navigating to the search page). In order to make the test feel as automated as possible, we asked the users to imagine interacting with a computer to perform tasks with both interfaces.
We prepared about eight tasks, such as, “You regularly share jokes with your favorite brother and his birthday is next week. Find a card for him.” We made sure to compose these so that they included multiple facets and there was more than one possible answer. During testing, we varied the order in which we gave the users the tasks and we also alternated the prototype presented first between users to eliminate any first-last bias. For each task, we asked the user to interact with the interface on the tabletop and to pretend that they were using the computer. We had laminated the Visio printouts so that the users could write on them with a thin whiteboard marker. One of us took notes while the other facilitated and simulated the feedback given by the computer. For example, in the wizard interface we wrote down the number of matching cards on a slip of paper as the user made each choice.
Since it would have been very difficult to show users actual results, we stopped each task when users told us they were ready to hit the “search” button. The best way to get feedback from the users under these circumstances was to determine how confident they felt about the search. So, after each task, we asked a series of questions:
- How confident are you that the Card Finder would find cards that match the task?
1 – Not confident at all
2 – Not very confident
3 – Somewhat confident
4 – Confident
5 – Very confident - How many cards do you think the Card Finder might find?
- Do you have any comments on this version of the Card Finder?
We also devoted the second half of each test session to a separate activity devoted to the design of the results page. We asked them to select from cutouts of elements that could appear on a results screen and build their ideal search page.
Facing the music
Nobody likes being wrong. I pride myself in my efforts not to bias tests by leading with my own opinions. I must have done a good job. I was able to hide my pain over the three days of the test as the majority of users chose the one-page search interface over my wizard approach. Our testing and analysis revealed the following:
- Users preferred to see multiple criteria on a single page.
- They had difficulty noticing “show more” functionality, which expanded their options. Some preferred to see complete lists of options by default.
- Users offered opinions on the ordering and priority of criteria. “Reason to send” and “tone” were both high priorities. “Recipient” was more important than we anticipated.
The decision was clear —I may have lost, but the users won. In the aftermath of the test and the subsequent report we delivered to the client, I needed to create an interface based on the one-page paradigm. So I updated my design for the test according to the feedback from the users. In particular, I reorganized the way the facets were presented so that “Reason to send” was the most prominent and the other facets were given equal secondary emphasis. I relied heavily on the idea that users would see a relatively short page at first that could expand as needed. We also recommended that search provide “smart” results. Because the one-page search interface presented a high risk of offering null results, we specified that the search engine would need to present best-bets if not all criteria matched.
All for naught?
Once I got over my angst about losing the battle over the search interface, I felt really great about the conclusion of the project. I had swallowed my pride and designed a direction for the interface based on what the users wanted. Moreover, I felt good because our months of working with Egreetings finished with a very successful relaunch which happened on time. Even better, the initial statistics after the launch showed a positive impact from the new card categories and navigation that we’d recommended. Transactions (cards sent) and the number of visits went up immediately —a rare achievement in any redesign because it usually takes users some time to adjust when a site undergoes major changes. Egreetings had implemented roughly half of our recommendations and the others were put onto their priority list for future updates. We even received thanks from the CEO and VP.
This was certainly disturbing news for me. I felt sorry that the Egreetings team would no longer be together. I also worried that the site on which I’d spent such a considerable amount of time and effort would be wiped out. That has not
![]() |
Chris Farnum is an information architect with over four years’ experience, and is currently with Compuware Corporation. Three of those years were spent at Argus Associates working with Lou Rosenfeld and Peter Morville, the authors of Information Architecture for the World Wide Web. |
![]() |