Guiding Principles for Providing “Remember Me” Personalization

Written by: Meg Peters

As we set out to enhance personalization on Marriott.com, we realized we needed guidelines to inform our thinking and shape our decisions, particularly decisions related to customer privacy. Our earlier user research revealed the need for greater personalization and helped us understand customer attitudes towards privacy. From there, we sought to build customer trust and loyalty by addressing concerns about privacy and security in every aspect of the user experience. In creating the Guiding Principles outlined here, we conducted a thorough analysis of eight major websites and then merged the findings with what we already knew. These principles apply specifically to "remember me" personalization.

Our earlier user research revealed the need for greater personalization and helped us understand customer attitudes towards privacy.What is “remember me” personalization?

In its simplest form, “remember me” personalization is the capability of some websites to “remember,” or pre-fill, your username when you return to the site so you don’t have to enter it every time. Usually there is a checkbox where you sign in that says something like “Remember me” or “Save my password.” Some sites, such as Amazon, provide “remember me” personalization automatically. In fact, Amazon serves as an example of incredibly sophisticated and robust “remember me” personalization because the site seems to remember everything about you, such as what you bought, what you viewed, and what you left in your shopping cart.

How do sites “remember”? Cookies.

A cookie is a small text file sent by a website to be stored on a computer so the site can identify a user when she returns. Cookies can be used for personalization, processing transactions, and tracking a user’s activity on a website. Many sites use them to target advertisements for users who may be interested in specific products and to vary the advertisements shown to one user so she will not see the same one repeatedly.

Checking the “remember me” option on a website might expose personal information if the computer you’re using is “public.” If someone else uses the same computer and browser to visit a site you opted to have “remember” you, that person may gain access to your personal information. People also avoid cookies because they dislike knowing a website is always “watching” them, keeping track of everything they do.

Why we wanted to enhance personalization on Marriott.com.

Our user research has consistently shown that customers don’t sign in on Marriott.com unless they must do so to perform a specific task, such as booking a hotel reservation or checking their account balance. This finding prompted us to consider offering greater personalization for customers (who choose to be remembered by the site) when they do not sign in. Because we’d need to use cookies to offer this type of personalization, we recognized it was critical to conduct research first. As part of that research, we developed a set of Guiding Principles to steer us as we redesigned the “remember me” personalization on Marriott.com. The Guiding Principles were intended to help us address customers’ needs with regard to privacy and personalization, enabling us to provide them with a better experience on the site.

We took a three-pronged approach: examining our past user research, our customers, and our competition.

Previous studies gave us insight into the way customers view their account information: specifically, what personal information they consider private, semi-private, or non-private. We met with our in-house privacy expert and with a leading technology and market research company to understand what business issues might arise as a result of “remember me” personalization. They were unaware of companies facing legal problems resulting from privacy issues related to personalization; however, both experts acknowledged that some businesses have encountered challenges from a public relations perspective.

Finally, we studied how direct competitors, secondary competitors, and major sites outside our industry are using “remember me” personalization by performing a detailed competitive analysis. We discovered that choosing to be “remembered” means different things on different sites. At one end of the spectrum, it’s like an automatic sign in, enabling full access to account/personal information. The other end involves little more than a username pre-fill, allowing for quicker sign in.

What we learned—it’s a jungle out there.We developed the Guiding Principles: general guidelines for creating “remember me” personalization that’s effective both from the customer and business perspective.

We discovered that there are virtually no established standards or guidelines for “remember me” personalization. Several organizations, including the World Wide Web Consortium (W3C), the International Organization for Standardization (ISO), the Personalization Consortium, and the Center for Democracy and Technology (CDT) have led initiatives aimed at protecting consumers’ privacy and at requiring websites to ensure that personal information is kept secure. Most notably, the W3C’s Platform for Privacy Preferences Project (P3P) offers users more control over how their personal information is used by:

  • Defining standards for simplifying the structure, content, and language of website privacy policies to help users understand what personal information a site collects and how it will be used.
  • Allowing users to select privacy preferences within a P3P-enabled browser and notifying them when they are visiting a P3P-enabled website if the site’s privacy practices conflict with their preferences.

Without standards for the design of “remember me” personalization and with significant variations from site to site, the scene resembles “The Wild West.” This is an interesting time in the evolution of the Internet; we can learn from trailblazers like Amazon that are setting the standard for “remember me” personalization despite the fact that people have become cautious about sites that use cookies.

What was the outcome of our research? We developed the Guiding Principles: general guidelines for creating “remember me” personalization that’s effective both from the customer and business perspective. Some of the principles were gleaned from what appear to be emerging best practices; others resulted from bad experiences, i.e., how not to implement “remember me” functionality.

The controversy and concern surrounding the use of cookies offers us, as usability professionals, the opportunity to talk—and to set standards so the “remember me” personalization we design enhances a user’s experience and builds trust and loyalty instead of creating frustration, disappointment, and mistrust. Establishing some solid guideposts will help us design with integrity.

These Guiding Principles should help your team stay focused on what really matters. They may evolve over time, but for now, they provide a framework for consistency.

The Guiding Principles
1. Communicate openly and clearly about security and privacy.

Address customers’ concerns, and do it in context—for example, when they are signing in or being asked for information.

Customers want to know:

  • How the site uses cookies, web pixels, and related technologies, explained in a way they understand.
  • Why the site wants or requires personal information.
  • What personal information is collected.
  • What cookies are set and what these cookies are called.
  • What is in each cookie.
  • How personal information will be used by the site and third parties, and who these third parties are.
  • How users can access their personal information.
  • Options for controlling how personal information is used.
  • How personal information will be protected.

2. Explain the value of personalization to customers.

Customers should always get something from personalization, and the benefits should be proportional to the amount of personal information they provide. Make it clear what they will get in exchange for their personal information.

3. Build customer trust.

There are many ways to do this:

  • Protect the customer’s information: display information that is personal but not unique to a customer. For example, membership level within a hotel or airline loyalty program is shared by many customers; whereas Social Security number and member number are unique to one particular customer.
  • Warn customers about using “remember me” functionality on public computers.
  • Be consistent when presenting and asking for customers’ information.
  • Make it easy for customers to provide feedback.
  • Respond to customer concerns/feedback.
  • Scale personalization gracefully: the more loyal the customer, the more she already trusts the site, and likely, the more often she uses (and wants) personalization.

4. Give customers flexibility and control.

Allow them to opt out of being remembered at any time. Make it clear how to do that and make it simple:

  • Provide well-marked paths and landmarks.
  • Offer reliable visual cues for context.
  • Keep them informed so they do not enter into an experience unwittingly.
  • Make actions reversible so they do not make irrecoverable changes.
  • Always allow a way out, but make it easier to stay in.

5. Make customer participation in personalization seamless, but obvious.

Give customers options for personalizing content and gather information iteratively at appropriate times, offering feedback and “gentle reminders” prompting them to update personal information. Make it easy for them to provide information, but make sure that will be a conscious decision by the customer.

6. Provide personalization whenever possible, as long as it is relevant.

Use personalization to enhance the customer’s relationship with the site, and keep it in the context of what the customer is doing while on the site. Ensure that “remember me” personalization supports the mission and purpose of the website.

7. Test “remember me” functionality to ensure it works and is usable.

Make sure the functionality works the way it’s supposed to.

  • Provide clear visual and verbal cues that reveal the customer’s status: remembered, signed in, or not recognized.
  • Make sure visual and verbal cues match the site’s performance, i.e., no “sign out” link for “cookied” customers because they are not signed in.
  • Differentiate the “remember me” feature from sign in.

8. Make sure that “remember me” personalization provides good ROI before implementing.

Check with customers to ensure that personalization you provide has value, and to determine ways to improve it. Review site statistics related to use of personalization, such as the number of users who check “remember me.” When planning enhancements to personalization, set metrics and then track results.

9. Before providing personalization, consult with the legal department.

Know the company’s policies regarding personal information and be aware of any past situations involving the company or the company’s industry that may have caused legal problems. Watch for emerging guidelines and best practices related to personalization.

_

The author would like to thank Beth Toland for coming up with the idea of creating Guiding Principles, as well as for her insight, inspiration, support, and careful scrutiny of this article. Thanks also go to Rich Shaub, Michael Rabjohns, Jill MacNeice, Mariana Cavalcanti, and Barney Kirby for their support and highly valued input.

Succeeding at IA in the enterprise

Written by: James Robertson

As information architects, the core of our profession rests on the analysis of information, the identification of structure, the creation of taxonomies and site maps, and the development of wireframes and user interfaces. These skills are well-honed, and we play a significant role in the design and creation of many systems, from websites to web 2.0. The real challenge is making things happen and getting users to adopt the new solutions

Working within the enterprise, we are confronted with new challenges. There is a lack of clarity around needs and goals, organisational issues are paramount, and the real challenge is making things happen and getting users to adopt the new solutions.

This is the focus of what is often called “enterprise IA”, the application of information architecture in complex business environments. To be successful in these situations, we need skills and strategies that focus much more on people than on information.

This article explores some of the approaches needed to ensure that we are successful at implementing IA within organisations, with the goal being to encourage further discussion in the community about these issues.

Business strategy At the end of the day, enterprise IA projects need to be able to demonstrate that they have made a real and measurable difference to the core activities of the organisation.

More than any other skill set, enterprise information architects need to have a strong understanding of business strategy and planning. With so many possible issues to solve, the greatest success is achieved when activities are designed to support organisational strategy and to deliver tangible business benefits.

In practice, this includes:

  • Building a strong understanding of overall corporate strategy and directions.
  • Using this knowledge to select projects that will support organisational goals.
  • Designing projects to deliver tangible and visible benefits within the organisation.
  • Developing project plans that will deliver “quick wins” while building momentum for longer-term activities.
  • Conducting good project management, including working within project constraints and maximising the use of project resources.

At the end of the day, enterprise IA projects need to be able to demonstrate that they have made a real and measurable difference to the core activities of the organisation.

Top down and bottom up

Successful enterprise projects follow both a “top down” and “bottom up” approach that combines overall business strategy with an in-depth understanding of staff needs and issues.

This is illustrated in the following diagram:

Enterprise flow diagram

For an information architecture project, this means:

  • Working with senior management to obtain strategic input, including overall business goals and objectives.
  • Conducting in-depth research with key staff groups to identify major staff issues and needs.
  • Using the strategic view as a “lens” to select key activities that both support business goals and meets the needs of staff.
  • Developing a set of tactical (short-term) strategic (longer-term) activities to deliver improvements to information management within the organisation.

While this is not the only way that an enterprise IA project can be managed, it demonstrates different approaches that must be explored by information architects when addressing complex business problems.

Understanding staff

User research techniques such as interviews, focus groups, contextual inquiry, and workplace observation are well understood and widely practiced by most IAs. While these techniques are important in general IA projects, they are critical for enterprise IA activities.

For a typical website project, the starting point is to define goals, objectives, and broad functionality. Research is then done to determine the best way to design and deliver the solution, with user-centered methodologies driving interface design and site structure.

Within the enterprise, the order is reversed. The starting point, as outlined earlier, is to conduct research with staff. The purpose is to identify the needs and issues of staff, which then helps define the goals and scope of the project.

This research is much more open-ended than typical user-centered design. Staff aren’t asked questions about the intranet, portal or document management system. Instead, the aim is to build an in-depth understanding of how staff work, and the environment in which they operate. In practice, we’re looking for issues and needs that we don’t even know to ask about. (The “unknown unknowns”, to quote a now-infamous speech in the US political arena.)

This approach is much closer to ethnography than user-centered design, and we can learn much from this discipline when working within the enterprise. By building up this depth of knowledge, we can target the most important needs, confident that the solutions delivered will be useful (and used) in practice.

Organisational change

Enterprise IA projects are only successful when delivered solutions are actually used by staff. While this is more certain when solutions are based on an in-depth knowledge of staff needs, a comprehensive change management plan will still be required.

Organisational change becomes a key element of enterprise IA projects. Information architects working within complex business environments need to have a strong understanding of organisational culture and how to work effectively within it.

For example, the greatest enemy of our projects is not active resistance, but apathy. While information problems within the organisation are generally widely known, they are not seen as sufficiently urgent or important to be addressed as a matter of priority.

Enterprise IA projects must start by creating a sense of urgency within the organisation. A strong message and vision must be created for the projects, and communicated widely to build support at all levels of the organisation.

Technology

Enterprise information architects must be prepared to work across technology boundaries. This is about delivering a single user experience that provides a seamless work environment regardless of what technology is used behind the scenes.

This means that enterprise IA projects must at least have an understanding of:

  • intranets
  • content management systems
  • document and records management systems
  • collaboration tools
  • applications and databases

This is not to say that enterprise architects need to be technologists or developers. In most cases, enterprise projects will be supported by IT teams and departments that provide specialist skills in these areas.

Enterprise IAs must, however, understand enough of these technologies to create solutions, taxonomies, and designs that help to bring these systems closer together, towards the goal of a single user experience.

Working with others

There are many disciplines that are working to solve enterprise issues, including:

  • knowledge management
  • content management
  • information management
  • document and records management

There is no one group that “owns” the problem, or has all the skills, tools and resources to solve it. While each group has its own models and metaphors, each successfully addresses at least part of the overall problem.

This is where we need to build our skills in working with others, what Lou Rosenfeld calls our “horse trading” skills. This is not just about working in multi-disciplinary teams, it is about working with key individuals from other teams, business units or even divisions, all reporting through different chains of command.

(This is where establishing a “community of practice” focusing on enterprise issues can be very helpful. This approach is actually drawn from the knowledge management domain, further demonstrating the need for collaboration between disciplines.)

Successful enterprise IAs are those with people skills, perhaps ahead of their specialist skills in card sorting, taxonomies, wireframes, and paper prototypes.

A call to arms

The need to deliver better solutions within organisations is great. When driven solely by technology, enterprise projects almost invariably deliver unusable interfaces and poorly structured information that generates considerable resistance to change.

While information architects are not the only group working within the enterprise space, there is the opportunity to demonstrate leadership in delivering effective projects and solutions.

If this is to occur, then the information architecture community needs to build its knowledge in the areas of business strategy and organisational change. We also need the people skills to work well with many other groups within the enterprise, each of whom contributes some part of the overall solution.

This is not to say that all information architects need these skills. Designing interfaces and structuring information is a worthy challenge, and it remains as the core of information architecture.

Space must be found, however, to discuss and explore the unique challenges encountered within the enterprise. We must recognise that a strategic view is equally important as professional design expertise and enterprise information architects must be supported in their quest for best-practice approaches and techniques.

So much more can be written about enterprise information architecture, and this article merely scratches the surface. It is hoped, however, that it will contribute to the discussions in this space, and to help raise the visibility of issues already being wrestled with by information architects in many organisations.

Final words In an ideal world, information architects will be part of a broader team …. we must understand organisational issues, but are not responsible for resolving them.

All of this is not to say that information architects need to become specialists in business strategy and organisational change. We will certainly not be hired to develop business strategy for organisations (and nor should we be!).

In an ideal world, information architects will be part of a broader team within an organisation that includes change managers, professional communicators and other specialists. As part of this team, we must understand organisational issues, but are not responsible for resolving them.

In practice, however, information architects often work alone or in small teams. Even large corporations often leave IA projects with only modest support and resources, perhaps due to a lack of understanding of the full challenges involved in delivering enterprise solutions.

In these cases, information architects are then faced with two choices: become more proficient in the areas outlined in this article, or narrow the scope (and expectations) of the project.

In either case, enterprise information architects will always benefit by having at least a core knowledge of organisational issues and approaches.

Further reading

The fields of business strategy and organisational change are well-developed and supported by many highly effective resources. In particular, the following books have strongly influenced the author when addressing enterprise challenges:

  • Leading Change (John P. Kotter; ISBN 0875847471) – this provides a very practical methodology for creating and driving change within an organisation. Required reading for every information architect.
  • The Heart of Change (John P. Kotter, Dan S. Cohen; ISBN 1578512549) – a companion volume that explores the role of storytelling in organisational change, providing many powerful examples of real situations.
  • Good to Great (Jim Collins; ISBN 0066620996) – explores why some organisations make the jump from “good” to “great”, based on extensive empirical research. Provides many insights that are valuable in enterprise IA projects.

Beyond this, there are many articles, journals, and training opportunities that can be used to build expertise in the fields of business strategy and organisational change. Once core IA skills have been developed, enterprise information architects should switch their focus to exploring these areas.

About the author
Portrait of James Robertson

James Robertson is apparently the “intranet guy”, or so he was told at the IA Summit in Vancouver . He runs Step Two Designs , a consultancy based in Sydney , Australia , and has written over one hundred articles on intranets and content management, which can be found on his site. He also has a blog, the writing of which gives him something to do each morning while his brain warms up.

Collaboration Sessions: How to Lead Multidisciplinary Teams, Generate Buy-In, and Create Unified Design Views in Compressed Timeframes

Written by: Sasha Verhage
“…The benefits of this tool include increased participation, increased understanding of the value of each discipline, and consequently increased buy-in from the team.”

I have participated in, led, and suffered major website redesign efforts. Whether at process-heavy consultancies, notable product companies, or design studios, all teams experience the same points of pain: late feedback, lack of common design vision, and complaints that individuals or teams didn’t have enough input.

No matter what your design process is during the early phases, most interaction designers and IAs complain that requirements aren’t clear or specific enough. Product managers are anxious to get started and have high hopes–expecting product innovation, timely delivery, and no negative impact on the site. Engineers are frustrated because they are not solicited for input. Finally, to complicate matters, the approval process becomes mired in team dynamics and politics.

The traditional software development “waterfall” process was first described in 1970 in a paper by Winston Royce. He postulated that as the project moved from requirements gathering to implementation, specialized disciplines would create specific deliverables and then pass them off to the next discipline. For example, interface designers would hand off low fidelity schematics to visual designers, who would design the look and feel before delivering to web developers.

fig1.gif
Figure 1. A frequent and frustrating consequence of the waterfall process is late feedback.

Over the years, I have developed a framework that I call “Collaboration Sessions.” Collaboration Sessions encourage multidisciplinary collaboration while creating a unified design vision–all within a compressed time frame. The benefits of this tool include increased participation, increased understanding of the value of each discipline, and consequently increased buy-in from the team.

collab.gif

What are Collaboration Sessions?

Collaboration Sessions are highly interactive meetings (or more accurately, work sessions) with representation from each discipline. These meetings address everything from strategic planning to the design of site sections and page details. For example, a team working on the Travel section of our site used this technique to brainstorm a new line of business and then used it to help design page details. This method is most helpful for redesigns, new features, and controversial or strategic sections of a site (e.g. the home page). Typically, an interaction designer or product manager leads the meeting at the beginning of the Design phase.

fig2.gif
Figure 2: Collaboration Sessions are excellent tools, especially during the design phase of a project.

A project manager is designated as the central point person, responsible for inviting the required and optional representatives from Sales, Marketing, Product Management, Interaction Design, Visual Design, Web Development, and Engineering (or whatever your particular departments/functions are). The meeting request should include an agenda and describe the purpose of the meeting. The request might also encourage the team to send in ideas and innovations or ask them to present their new ideas to the group at the beginning of the meeting. If it makes sense, prior to the Collaboration Session, the interaction designer conducts due diligence and a heuristic evaluation of the current site. For a new feature, the designers might look at competitors or research best practices.

Collaboration Sessions are most effective when attendees understand the project goals, the design problem to be solved, the roles and responsibilities of individual team members, and the business context. The facilitator starts the meeting by explaining the purpose of the meeting, the type of contributions encouraged, the ground rules for the session, and the desired outcome. The facilitator also assigns roles: time keepers, notetakers, final arbiters, and scope police (who call attention to scope creep). It might be helpful to assign these roles before the meeting. The product manager (or participant with the most domain knowledge) should provide the team with the historical, business, and competitive context. Scope boundaries can also be identified. For example, when a page will be completely redesigned and rearchitected, the product manager will state the purpose of the pages and the current design challenges.

With a blank wireframe template pasted on the wall, the facilitator turns the team’s attention to page level design. The focus is high level, not pixel level. Figure 3 is an example of “Search Results” with an accompanying “Notes” page. Advertising requirements are identified in pink. The primary focus of the page is the search result set, noted in purple. The secondary call to action, identified in blue, is “Modify Search.” The Post-It notes provide general placement for the page components but do not dictate design. However, some design decisions may be requirements; for example, the Sales department may specify that all ad units have to be above the fold.

fig3.jpgfig4.gif

Figure 3: Next to each page or site section, the Notetaker documents issues, to do’s, questions, assumptions, and major decisions.

As issues and questions arise, they are captured in real time by the notetaker on a “Notes” page taped next to the page being designed. At the end of the meeting, the To Do items are assigned to specific people. After the Collaboration Session, the interaction designer distributes the Notes. The team can then use the session output to start working on a more detailed design, creating wireframes that use the accompanying Notes documentation. When answers are found, the Notes page is updated; Notes pages should be living documents, shared by team members.

Before the Meeting
  • Identify key constituents from Sales, Marketing, Product Management, Interaction Design,Visual Design, Web Development, and Engineering (you can easily map these functional areas to your company’s organization)
  • Send out agenda to participants (assigning any prep work)
  • Facilitator conducts due diligence
  • Prep the room with supporting material (e.g. screen shots, marketing research, supplies)
Collaboration Session Agenda
  • Purpose of meeting (facilitator)
  • Ground rules and roles/responsibilities (facilitator)
  • Scope boundaries (what’s in/out of bounds) (product manager)
  • Walk through pages (facilitator)
  • State purpose of each page (product manager)
  • Discuss current design problems or challenges
  • Brainstorm page solutions. Use Post-It notes to document primary and secondary calls to action and other page elements. (facilitator)
  • Capture issues, to do’s (with owners), assumptions, major decisions, and design rationales on “Notes" page (notetaker)
  • Document any major product innovations (notetaker)

What Collaboration Sessions are Not

The process should not be “design by committee” but rather design for common understanding. When the designers provide solutions during the meeting, these are meant to foster discussion, not offer a final solution The focus should not be on granular elements like interface widgets or pixels. If you are debating whether something should be a drop-down or not, then you are wasting people’s time. Remember, if you have representation from each discipline, these are costly meetings. The facilitator should not try to provide real-time solutions or answers. Collaboration Sessions identify the requirements (i.e. what needs to change, the current design’s problem areas, current traffic pattern, what competitors are doing). The designers should take this information and ultimately present solutions to the problems. The session output serves as the foundation for design rationales.

Benefits
Collaboration Sessions enable teams to compress the development cycle by accomplishing the following:

  • Establish a common design vision. Encourage early collaboration.
  • Generate ideas and innovations for release and/or inform product roadmap.
  • Identify questions, issues, and to do’s.
  • Encourage full team contributions and subsequently ensure team buy-in.
  • Document assumptions, design rationales, and changes.
  • Enable parallel development (i.e. mobilize each discipline).
  • Improve scoping, estimating, and planning (e.g. number of impacted pages, new pages).
  • Inform process flows and page level design.
  • Can improve credibility (by identifying design problems and having designer recommend solutions). Can change perception of user experience design from “pair of hands" to more "strategic partner."
  • Define the design problem within its historical context.
  • Establish regular check-in meetings.
  • Allow User Experience team to present recommendations, design solutions, and design rationale as a unified voice.
  • Identify opportunities and innovations at a strategic level.

Best Practices
After running Collaboration Sessions over the past couple of years, here are some best practices I recommend:

  • Prep the meeting room the day before.
  • Encourage one representative from each appropriate discipline to attend. Cross-functional representation deepens the understanding of the problems, encourages more holistic solutions, and fosters collaboration across the team.
  • Start each meeting by allowing the business owner or the person with the most experience to provide context on the competitive landscape, current design, or any useful and relevant information. Also, identify roles: timekeepers, final arbiters, scope police, product manager as hub, design manager as process filter.
  • Make adaptations or customize the format of Collaboration Session process after each session if needed. Encourage the team to be flexible, nimble, and adaptive.
  • Summarize, capture, and distribute the notes from each Collaboration Session within 24 hours.
  • Involve key stakeholders before the session, and have them buy in to the participants, agenda, and meeting objectives. If relevant, send out any homework, such as links to competitors, before the meeting.
  • Send out “Issues and To Do’s” immediately after meeting.
  • For major innovations, package ideas and “sell up” to key decision makers afterwards.

Testimonials

After the first one:

“I just wanted to say I thought the first collaboration session went really well overall. Lots of focused participation from different disciplines. Discussing and agreeing on goals and priorities at a page/template level is really going to help communication throughout the design process. It’s often a big leap from presenting documents to one another to solving problems together and getting design work done in real time.”

Contract content strategist with 8 years experience.

After project was done:

“Super proud [of the redesign]. Collaboration sessions were pain in the ass to attend, but extremely valuable to the process” “Very proud and pleased with the end result.”

Product Manager.

“Best process at Yahoo I’ve seen, in 5 years. Smoothest redesign to date I’ve worked on.”

Senior Engineer.

Invitation from another team

“Our goal of this meeting is to have you lead us through a Collaboration Session…. I remember how helpful this process was in designing pages for our previous product….I think our team could really benefit from applying this tool.”

Senior Product Manager

Sasha Verhage is a Senior Design Manager at Yahoo with over 10 years experience in software, internet and professional services industries. He is passionate about leading fast paced and high performing teams to successful outcomes. In his not so spare time, he makes award winning wine under the Eno label.

Lost in Translation: IA Challenges in Distributing Digital Audio

Written by: Dan Brown
“The main challenge facing network audio devices is how to provide remote access to the music library… this looks like a job for an information architect!”

With each new advancement in digital media come new ways to consume and distribute it, and new and different challenges for information architecture. For example, several new devices on the market are designed to distribute digital audio from a computer to audio systems in other rooms of the house. These devices connect to your home network through a standard Ethernet cable or wi-fi, routing music from your computer to your stereo using standard audio connections.

The main challenge facing these devices is how to provide remote access to the music library. While sitting at a computer, you have the benefit of using a keyboard, mouse and screen to interact with software like iTunes or WinAmp. Since network audio devices need to sit on the shelf with your stereo, they do not have a full display, and the only means of interaction is a remote control. In other words, this looks like a job for an information architect!

This new paradigm for accessing music libraries presents at least two information architecture challenges:

  1. How do users find a song in their music library?
  2. How do users know what’s playing and what’s coming up?

The challenges are made even more difficult by several factors:

  1. Limited display size
  2. Limited availability of metadata
  3. User’s expectations—people are used to browsing through a CD library

This article looks at how three devices on the market today address these IA challenges. Two of these devices, RokuLabs’ Soundbridge and Slim Devices Squeezebox have a screen on the shelf unit. The display on each of these devices is limited to two lines of text, and the remote controls are configured for navigation. On the other hand, Sonos’ device uses a different approach, putting the display in the remote control. Because of this, Sonos’ remote looks like a large iPod with a color display while the device that networks the music has no display at all.

Design Philosophies

Sean Adams created the first generation Squeezebox in 2001 by hacking together some hardware and software. From that first foray into distributed digital music grew a large community grounded in the open source culture. Slim Devices made their server software open source, and there are now more than 50 developers working on it worldwide. This approach has led to constant gradual improvement.

Slim Devices' Squeezebox
Dean Blackketter, Slim Devices’ CTO, says that although the community is the key to adding new features, he monitors all changes to the software before they are officially released. This allows Slim Devices to ensure that any changes to the interface stick with their style guide. Blackketter appreciates the open source approach because it allows people to work on the interface quirks that bother them the most; he told a story about someone who found the timing of the scroll a little off, and wrote a new scrolling algorithm. Blackketter frequently uses the “friends and family” approach to test the usability of these upgrades.

Slim Devices uses no formal user-centered design methodology and maintains no tools beyond a style guide. Blackketter says that the company has internalized the personas of their customers. The management team came to an implicit agreement over the life of the device that their target audience consists of highly technical people—users who like playing with the device—and their spouses—people who just want to listen to music.

Like Slim Devices, RokuLabs’ design philosophy does not depend on formal user testing. Many of the team members at RokuLabs came from ReplayTV, the main competitor to TiVo, and the designers at RokuLabs depend on their previous experience in networked media devices to provide insight into usage. Mike Cobb, RokuLab’s senior engineer, says their experience with ReplayTV provided many lessons for the user experience of the Soundbridge.

The user experience of iTunes also drove the design philosophy for Soundbridge, since the unit was meant to be an extension of that software; RokuLabs sought to make the interactions similar to those of iTunes or the iPod. One key difference is the interaction model of the remote control: while Squeezebox uses the “right arrow” button to make a selection, Soundbridge users must push a “select” button. RokuLabs’ design rejects the use of navigation as selection. In this way, it resembles the iPod, which uses a one-dimensional navigation device (the wheel) and forces users to physically make a selection (by pushing the center button).

RokuLabs also had the benefit of not being the first to market. They played with early versions of the Squeezebox and decided what they liked and didn’t like. One thing they noticed was that the experience seemed geared to tech-savvy users, and RokuLabs wanted a more mass market device.

The newest entrant is Sonos, whose unit shipped in January 2005. I spoke to Mieko Kusano, the director of product management who says that although the idea for Sonos came from its founder, they spent a lot of time defining their target market, which led to creating personas. Sonos also employed a simple ground rule: their designers were not allowed to talk about what “I” want. Instead, all design decisions had to be made within the context of the personas. Kusano says the personas were useful for making the process more concrete, and they gave the company a common platform. She advocates doing as many user studies as you can. “Every time we had something new to show,” said Kusano, “we brought users in.”

Initial user research drove a couple of key design decisions, including putting the display on the remote and focusing on distributing music to many rooms in the house. Having decided to make the screen on the remote in early user studies, they developed a method for prototyping new remote controls by using a PDA. They could program the PDA to display different screens and then test them with their users.

The second decision—focusing on multiroom audio distribution—motivated the design of the remote control itself. Sonos’ remote boasts the fewest buttons. Many functions use “soft keys”—buttons that change their function depending on state—but escalates key functions to physical buttons. Besides volume and playback and navigation, there are only two other buttons: Music and Zones. The music button brings users to the menu where they can select music and the zones button brings users to the menu to select what room to program. All other controls (for example, shuffle, repeat, music queuing, etc.) are presented in the screen.

As Sonos neared their launch date, they did frequent in-home testing, taking beta units to customers’ houses and observing them. They watched users as they went through the out-of-box-experience, the set-up, and use of the unit. Sonos’ approach represents a departure from the other two philosophies, and I was eager to see how the structure of information would differ among them.

Browsing Music

Before digging into the navigation scheme, I want to set out the underlying conceptual structure for each system, which is the same across all three and resembles that of the iPod. (Squeezebox was around before iPod, and was the first unit to employ this structure.) Songs live in a music library. They are “moved” to a queue of songs to play. Users may move songs one at a time or implicitly by selecting a “natural grouping” of songs—an album or an artist, for example. Conceptually, a music player’s key interaction is moving songs from library to queue. At any given time, users need to know what song is currently playing and what songs will be coming up. They also need to navigate the library to facilitate moving songs to and from their queue.

I don’t know if this is the best structure, but it appears to be employed across the board. Even though the underlying structure is consistent, it’s possible for each system to present a different mechanism for navigating the library and moving songs from library to queue. Possible, but unfortunately not true: despite having differing design philosophies, all three devices use nearly identical information architectures, all of which resemble the iPod’s structure. The root menu of each system varies slightly, but one option takes users to a familiar menu:

  • Browse Albums
  • Browse Artists
  • Browse Composers
  • Browse Genres
  • Browse Songs

In Sonos’ system, this menu is called “Music Library”; SoundBridge calls it “Browse.” Selecting any of the options from this menu will take users to an alphabetical list of albums, artists, etc. Each entry represents a group of songs. Users can move the entire group to the play-queue, or can “open” the group to look at individual songs.

Looking at all the songs in a group, users can select a track and play it, add it to the queue or get more information about it. Specifics vary depending on the system. Soundbridge takes you to a list of options, the first of which is “play songs starting with this one,” allowing users to select the group of songs by selecting one song inside the group.

When compared directly, the core information architectures of each are virtually indistinguishable. Each album, genre, artist, and composer is a separate category and each track fits into one of each. There are relationships between the categories:

  • Genre → Artist → Album
  • Bluegrass → Del McCoury Band → It’s Just the Night

The problem is that music is much more complicated than this architecture, even if it does account for some of the nuances of music libraries. For example, an artist or album can belong to multiple genres:

  • Folk → Eva Cassidy → Songbird
  • Popular → Eva Cassidy → Songbird

Another problem with the architecture is that artists’ names may be rendered differently, depending on what they’re working on:

  • Bela Fleck & the Flecktones → UFO TOFU
  • Bela Fleck and Edgar Meyer → Music for Two
  • Edgar Meyer/Bela Fleck/Mike Marshall → Uncommon Ritual

Each of these instances of Bela Fleck is rendered differently in the architecture, because the architecture is conceived as a straight hierarchy.

“All the problems with navigation can be traced back to a single central issue: lack of data. Creating more complex structures depends on having more comprehensive information about the music.”

All the problems with navigation can be traced back to a single central issue: lack of data. Creating more complex structures depends on having more comprehensive information about the music. Because the artist is rendered as a simple text field, the systems can not match up “Bela Fleck & the Flecktones” with “Edgar Meyer/Bela Fleck/Mike Marshall.” Using the systems’ browse features alone I would not be able to find every track in my library on which Bela Fleck performs. The systems’ search features afford some improvement, but they still depend on having good metadata.

Searching Music

The appalling state of music metadata is no secret. Other authors have already explored the limitations of the available metadata with respect to jazz, a genre that “goes beyond the ‘Great Man’ theory and recognizes the influence of side players…” Whether other genres of music have as rich a metadata landscape as jazz is immaterial. Liner notes from any album in any genre hold more information than currently captured in most digital audio systems. All three manufacturers highlighted in this article believe the lack of good metadata is a crisis facing the entire industry. However, they all feel that once the industry cracks the nut, their devices will be prepared to address it.

Search on the Squeezebox and Soundbridge operate as you would expect them to. Select a search field from a menu, enter keywords video game hall-of-fame style with the arrow keys, and get a list of results. The extra step of selecting a field (eg: Search Artists) seems pointless, but Soundbridge engineer Mike Kobb explains:

[I]f I want to find tracks by “Barenaked Ladies”, it’s only a few key presses to choose “Search Artists,” then enter “ba.” The same 2-letter search would find too many items if it were done as a keyword search. I believe making the initial selection and then entering a smaller term is generally quicker than entering enough letters in a keyword search to get a small result set.

This makes sense from a technical point of view: allow people to limit the scope of their search so they don’t need to enter as many letters with the arrow keys. This approach solves one issue with navigation. So long as “bela” appears in the artist field, I can do a search to find all Bela Fleck’s music in my library. On the other hand, entering “be” to see all Bela Fleck tracks seems like an enormous conceptual leap from browsing a library of CDs. In other words, if the task is “get a list of all Bela Fleck’s tracks,” my inclination is to browse by artist—kind of like what I would do in real life.

The third device, Sonos, does not offer a search mechanism. They intend to offer it in the future, but provide no rationale as to why it wasn’t included in the initial release.

Knowing Where You Are

Digital music players give us two virtual spaces: the library and the queue. Knowing your “location” in the library is relatively easy because a mental image of the virtual space is readily available. When navigating the library, users are focusing on the task at hand. The use case for the queue is a different story; users put the queue together and leave it to do its thing. Only occasionally does the queue become the focus of attention after the initial set-up. All three units have a default view called “Now Playing,” in which the display shows information about the track that’s currently coming out of the stereo. Usually, that’s the name of the track and the amount of time left on the song.

On shelf-bound displays, Soundbridge and Squeezebox both give you “one-click” access to the next song. On Soundbridge, simply push the down arrow on the remote and you’ll see what’s next in the queue. Keep pushing the down arrow, and you’ll scroll through the queue. Sonos offers a bit more information, but not much. The “Now Playing” display shows the title of the next song, and getting to the entire queue is just a click away.

When looking at the queue on Sonos the large up-close display offers a broader view, providing more context. Think about using a CD: a complete track listing in the liner notes; you can see the whole thing and get information like song length. Displays of the shelf-bound devices offer only a limited window into the queue. Sonos’ display offers more information because you can see more of the queue. Still, the experience is not quite the same as looking at a set of liner notes because it lacks all the other information.

Is it fair to compare the user experiences of digital and analog worlds? Until music players carve out a new set of user behaviors, their designers don’t have much choice. People are used to interacting with their personal music collections in a certain way, and deviating too far may slow the adoption of new technologies.

Supporting User Behaviors

With only a few nit-picky exceptions the three devices generally do a good job supporting three basic scenarios:

  • I want to play an album and I know which one.
  • I want to play an album by an artist whose name I know.
  • I want to play a specific song and I know its album/artist/genre.

As an end-user, these tasks are pretty easy, once you get the hang of the IA and the interaction model with the remote control. If you want to create a mix on the fly things can get a little clunky as you run through the last task several times over.

Moving back and forth between your music library and the current queue requires gestures that may be difficult for users to get used to. Also, the idea of a queue is unique to this interaction model. If you’re doing the DJ thing and playing random songs for your friends, you may stack up a bunch of CDs to go through, but the queue is in your head and easily modified.

Each of these scenarios depends on user knowledge. If you know the artist or album, you can easily narrow down the library. Things get difficult when you don’t know the name of the song, or when you know the name of the artist, but not which variation of their name is the correct one.

Browsing is another user behavior that’s been neglected. There’s an aspect to browsing a collection of CDs that’s lost when translated to an iTunes-like environment. People don’t keep their entire music library in their head, and the ability to browse is crucial. Because the browse features on these systems are pre-divided into Track, Artist, Album, and Genre, “browsing” is limited to only text-based information.

Browsing a long list of album names is not the same thing as browsing jewel case spines. Color, typography and organization of the jewel cases give more information than just the album name; I may know that the Yonder Mountain String Band song I want is on their latest album which has a brown spine with orange lettering. The black spine with white lettering is their earlier album. I may not know the names of these albums, just the look of their spines. This free-browsing of a physical CD library is a nut not yet cracked by the industry. To be fair, this is a serious challenge: how do you support existing behaviors when users are used to browsing by more than just the names of albums or artists?

On the other hand, a virtual environment enables behaviors unimaginable in the physical world. Wouldn’t it be great if I could play tracks:

  • Based on how much I listen (or don’t listen) to them
  • Based on how often I play them sequentially
  • That my wife has marked as a favorite
  • That my kids did NOT mark as a favorite
  • Featuring certain kinds of instruments or vocalists
  • That have a special place in music history (like the “definitive” newgrass song)
  • That have been tagged by other listeners with particular keywords
  • I usually play on this day of the week or year
  • That feature a specified combination of musicians
“Virtual spaces with robust metadata models enable the kind of serendipitous browsing you’d find on IMDB, or the “social networking” you’d find on Del.icio.us.”

As online services emerge that compile this and other information, network audio players will need to tap into that metadata to enrich the music playing experience. Virtual spaces with robust metadata models enable the kind of serendipitous browsing you’d find on IMDB, or the “social networking” you’d find on Del.icio.us. Music libraries are ripe for this kind of experience, and the proliferation of these players could be the catalyst to bring about the change.

Conclusion

There is something very cool about storing all your music on a single server and being able to play it in any room in the house. Homeowners have an option for whole-house audio that, while still bearing a hefty price tag, doesn’t come close to the cost of “old school” systems. (The cheapest network audio systems are only a few hundred dollars, but you need a unit AND a stereo for each room.) The wireless network is much more appealing than running miles of cable through your walls.

When these manufacturers sought to create a whole-house audio system, they each started with slightly different ideas for the user interface problem. For Slim Devices, the pioneer, it was whether it could be done at all. The others each chose a different aspect: the remote, multiple zones, the display. The purpose of this article is not to recommend one device over another (there are many more than these three). The point is, none of these three devices demonstrate any innovation in the underlying information architecture.

Network audio technology is faced with a chicken-and-egg situation. Innovative IA in audio devices like these will be limited by the available metadata. At the same time, industry fears of piracy will limit the amount of metadata supplied with the music. Until the adoption of audio devices reaches critical mass, the industry won’t face pressure from consumers to expand the quality of data, but audio device adoption may stall without more innovative navigation methods.


Dan Brown is not the Dan Brown who wrote The Da Vinci Code, but wishes he were.