Skip to page content or skip to Accesskey List.
Search evolt.org
evolt.org login: or register

Work

Main Page Content

Keeping the Igloos Off the Beaches

Rated 3.97 (Ratings: 12) (Add your rating)

Log in to add a comment
(4 comments so far)

Want more?

 
Picture of lauriek

laurie kalmanson

Member info | Full bio

User since: January 09, 2001

Last login: January 09, 2001

Articles written: 1

IA White Paper

Laurie Kalmanson

Version 1.5 1.27.00

1.0 Introduction: Keeping the Igloos Off the Beaches
1.1 Home Sweet Home
2.0 The Centrality of the User Experience
2.1 Click — or Go
2.2 Creative / Functional Elements
2.3 Strategic Elements
2.4 Marketing Elements
2.5 The Centrality of The User Experience: A Diagram
3.0 The Information Framework
3.1 Interpreters and Guides

1.0 Introduction: Keeping the Igloos Off the Beaches

1.1 Home Sweet Home

Home is a recurring metaphor online — from the house icons with pointy roofs on early home pages, to the numberless tech teams who have said to countless project managers that they can build any kind of house required, but they need a floor plan first.

The image below of an igloo on a beach is the Information Architects' particular extension of the "home" metaphor.

Image 1: The Igloo on the Beach
The Igloo on the Beach

Everyone who sees this image laughs. It doesn't take people long to articulate why:

While Igloos are beautiful examples of form following function, and they brilliantly marshal available resources to create warm, dry, comfortable dwellings that use appropriate, environmentally friendly, low-impact technology — in Alaska — an igloo on the beach is nobody's idea of home sweet home.

As information architects, our goal is to keep the igloos off the beaches, by working on project teams to build the most appropriate site for a given task, balancing business goals against the needs and desires of users.

Of course, an igloo on a beach could be an interesting piece of conceptual art, and if that's a project's business goal, we're here to support it.

2.0 The Centrality of the User Experience

2.1 Click — or Go

Everything that happens online ultimately comes down to the moment when a user is looking at a screen and deciding whether to click or go.

And every piece of offline marketing that drives a user to a site, from a publicity event to a Super Bowl TV ad still comes down to a person, a keyboard, a screen and a mouse. Click — or go?

These variables shape the user experience, online and offline:

2.2 Creative / Functional Elements

Branding Elements / Site Architecture Elements

  • Logo | Navigation | Tagline | Functionality
  • Design / Look and feel | User Paths | Editorial voice | Personalization

Technology

  • Appropriate for the demographic
  • Appropriate for the site's goals

2.3 Strategic Elements

Business Goals

  • Define success in advance
  • Balance against user desires

2.4 Marketing Elements

Online Marketing Offline Media

  • Email | Print | Broadcast
  • Promotions
  • Banners PR / Publicity
  • Ninja | Special Events

2.5 The Centrality of The User Experience: A Diagram

This diagram presents the user experience as an event that is initiated by online and offline marketing elements, and is shaped online by creative and functional elements.

From the user's perspective, the central element that everything revolves around is this single question:

How do I work this?

Diagram 1: How Do I Work This
User Experience Diagram

Marketing components drive the user to the site, branding components inform the experience, and site architecture components guide the experience.

3.0 The Information Framework

3.1 Interpreters and Guides

Acting as interpreters of a project's business goals and as guides for the user, the information architecture group works with answers to strategic questions that are structured around this framework:

  1. Who are the users — webby kids, newbie adults, quick-search information seekers, luxury shoppers, commodity buyers , members of special interest communities — who? Just as the branding elements will vary by a site's demographics and by its business goals, so will the functional elements.

    The more sharply defined the audience, the better the functionality can be matched appropriately to the users.

  2. What is the single most important thing a user is asked to do on a given page?

    What is the business goal for each action a user is asked to take?

    What happens when the user takes action?

    And then? And then? And then?

    Developing answers to the "what" questions defines the twists and turns of the paths a user can take through a site. The sharper the questions, the clearer the answers, and the better the match between a site's goals and its functionality.

  3. When do you want a user to visit a site — one time only, or often? Just as high service retail venues positively reinforce the behavior of frequent shoppers by greeting them personally and presenting them with fresh displays of new merchandise, so web visitors coming back to a site should experience friendly welcome back messages and new content. When visitor frequency requirements are built into a site's business goals, the necessary functionality can organically become part of the site's structure.

  4. Where is the user coming from? Are they banner-driven users who have little pre-existing knowledge of the site? Are they intranet-driven users, who are familiar with the site's mission in advance? Welcoming users to a site in a manner appropriate to their experience is useful for everything from calming fears about e-commerce security, to clarifying a brand-new business model.

  5. Why are the users coming to the page — to satisfy what desires for information, entertainment, community or commerce? Why do you want them to come there — to offer them information, products, or just plain fun?

  6. How is the user experiencing the site — with multiple, bleeding edge plug-ins required and installed, through AOL, on a fast or a slow connection?

When the project team communicates clearly across these perspectives, success will be defined in advance, and the site will provide a satisfying user experience that meets or exceeds the client's business goals.

When the process of asking and answering questions is incomplete, both the usefulness of the site to the user and the success for the client will be affected.

If one part of the team thinks that what's being built is a summer seaside cottage, while other team members thinks that the need being addressed is for a cold weather home, the risk of ending up with an igloo on the beach is high.

This document offers a framework for asking and answering questions in the site development process, and for building igloos where the snow is.

Covers a lot; Good introduction; too task-focused

Submitted by cognissa on January 29, 2001 - 16:42.

I like it. I'm not sure about the whitepaper moniker, but nonetheless a good introduction and many talking points (especially if you're introducing user experience to others). I like the Who-What-When-Where-Why-How as a way to talk to people who don't need to hear IA/Usability jargon. I'm also a fan of considering the bigger picture (off & online marketing, word of mouth, media reviews, public relations, buy decisons, fulfillment, support, etc.) as being the *real* user experience...not just the time an individual spends visiting a site. Some minor differences aside, the only big thing I didn't like: the article is too task-focused. Laurie says: "From the user's perspective, the central element that everything revolves around is this single question: How do I work this?" * I disagree. I'd prefer it if this was re-worded as answering the single question: "How do I get what I want?" Can you dig the difference? This emphasizes user goals as the driver for the experience, not functionality (nor navel-gazing site goals). So instead of "the better the match between a site's goals and its functionality" we might have "the better the match between user goals and site functionality to create a positive user experience that supports our business goals" cheers, Jess * for another sample of the task focus I'm talking about see the ' What' section following Who - it's there between points 1 & 2, even though the What header is missing.

login or register to post comments

Very good approach

Submitted by wolf on January 30, 2001 - 03:06.

to make topics understandable for many involved but not knowing much about usability. While reading I thought of many people who I would like to have a look on this article before they continue their work like they did in the past. The intro with Igloos on the beach is genius. I hardly ever heard of a better comparison to make the problem(s) so easy to understand. Very good scientific diagram. Reminds me of McLuhan and all the others whose diagrams I had to learn long time ago at communications study.

login or register to post comments

like it...but can i suggest...

Submitted by dry on June 2, 2001 - 16:09.

laurie...nice work. I found your paper on IA one of the better approaches I've read. Broad but full of good details. Perhaps you should also focussing on 'Business Process' as well as goals. Goals are often far removed from the day-to-day delivery of services. Get into the 'gritty stuff' of how a company works and delivers to it's customers. The other thing I missed is some benchmarking and desk research. look how others provide the same or other service. Look at nav's, naming conventions,....bla, bla.

login or register to post comments

dry is right ... requirements assessment / busines

Submitted by lauriek on June 3, 2001 - 08:16.

dry ... i agree with you that requirements assessment / business processes are absolutely necessary ... depending on the company, the project, the team, i've seen that work get handled as part of the ia process ... the whole notion of finding out during ia discovery that building an igloo is not a good idea if it's gonna be on a beach ... or it gets handled separately by requirements assessment or business processes spec teams ... whoever does it, ya, it's totally necessary ... and thank you for reading my rant! -- laurie

login or register to post comments

The access keys for this page are: ALT (Control on a Mac) plus:

evolt.orgEvolt.org is an all-volunteer resource for web developers made up of a discussion list, a browser archive, and member-submitted articles. This article is the property of its author, please do not redistribute or use elsewhere without checking with the author.