She concluded her post with this comment:

I’ve grown tired of people taking common sense, labeling it and then trying to christen it as a new process.

What jumped out at me was her implication that, just because it’s something she’s been doing, it must be common sense. I’ve heard this sort of thinking a lot. I guess it depends on the definition of common sense that you’re using.

There are two definitions I can see here:

1. Common sense is what I know to be true and how I judge the world.
2. Common sense is what is most commonly believed to be true and how most people judge the world.

These two definitions can only be simultaneously true if I believe the same things as the majority of people out there. Otherwise, they are in conflict.

Now, I’m at an interesting vantage point. As a researcher, I study what people believe. One area I study is what designers believe, particularly about creating great designs.

What I’ve learned in my research is that there are lots of different beliefs out there. Finding a majority belief is rare. And often, when we do, it’s not something that makes for the best designs.

Many folks are looking at Lean UX right now and saying what Lorena is saying: “It’s something I’ve been doing for years. What’s the big deal? Why do we have to give it a special name?”

But it’s not something the majority of teams I study are doing. Most are doing something more waterfall-ish, even when working in an Agile or Agile-ish environment. To them, this thinking is new. It’s novel. And it’s certainly not, from their perspective, common sense.

There’s an old saying: “There is nothing more uncommon than common sense.”

I’m wondering if we play the “it’s just common sense” a little too quickly and if that hurts our work.

But something is still missing. Though we are making progress and laying groundwork in large organizations, many UX teams still struggle with getting the necessary time and resources to do their jobs as effectively as possible. To continue growing our profession in both influence and in number of good designers, we need to find a sense of leadership.

In today’s UIEtips, we’re reprinting a fabulous UX Magazine article by one of our favorite people, Kim Goodwin. The difference between management and leadership is a great one. Kim believes that UX leadership should contain things such as mentoring and providing vision. Leadership itself is a skill that should be grown along with UX expertise.

Read the article, On UX Leadership.

In addition to her full-day workshop at User Interface 16, Kim will be giving a 90-minute talk, Experience Leadership. Kim will explore how we develop a broad view of what a UX leader is and how we develop both practice leadership and change leadership skills. Join us for UI16, November 7-9 in Boston. You won’t want to miss it!

Everyday, more companies are recognizing the value of design. They are realizing they need to have strong design to compete in the marketplace. They see their competitors, even the small ones that don’t offer as full a feature set, are eating away marketshare because they have better designed products.

No place manifests this more than Silicon Valley. Designers, especially good ones, can call their shots there. Companies are in a bidding war for talent.

That means, if you’re a good designer, you have to ask yourself: are you in the right place, right now?

Milton Glaser gave a speech a few years back. He talked about two types of relationships: those that energize and those that exhaust. Milton said he learned, the hard way, that he needed to regularly prune away those relationships that exhaust, focusing on the ones that energize. That was his advice to happiness.

If you’re a good designer, are you in a place where your work energizes you? Or does the organization you work for exhaust you, because it hasn’t realized how important design is to its own success?

Now, it’s not that every day will be free of frustration. But if you’re regularly energized, it’s much easier to face the tough challenges. When you’re exhausted by your work every day, the challenges often feel insurmountable.

When a company doesn’t get the importance of design, it’s rough being a designer there. You constantly have to explain what you do. You have to fight for the simplest things, like the time and resources to do research (and often fail). You see, everyday, how your work could be so much better if you had the right tools, the right support, and enough time to make it work.

It’s scary to think about change. But right now, the timing is right for designers. If the job you’re in isn’t the right one, you owe it to yourself to look at what your options could be.

If you decide you should explore the world of opportunities, think about what you’d want in your next job. A company that values design will push off a ship date because the product’s not well enough designed. Ask if the company has ever done that — that demonstrates whether they have their priorities aligned with yours. Delaying a launch is a hard call. Having done it means they are serious.

Look for other evidence they understand design. Do they take the time to do research? Is everyone in the team involved? Do they iterate frequently? Are they learning good things from each iteration?

These are the signs that a company wants to learn what the best designs are. That yearning to learn makes the workplace really exciting for designers who are innately curious and autodidactic.

It’s a good time to be a designer. Every day should energize you. Are you doing everything you can to make sure that happens? After all, you owe it to yourself.

Story mapping is a way of organizing Agile user stories that communicate user experience. It allows us to build the collection of stories that become the backlog. Agile expert Jeff Patton will show you how story mapping gives you a tool: a tool to both quickly think through and simply describe the user experience. This strong technique helps you put the big picture of UX and the little pictures of Agile in one place, engaging the developers and stakeholders you’re working with.

Users will always have an experience with your product. Story mapping will pull your UX focus into your organization’s process and ensure that experience is a great one.

You’ll learn:

How to build a story map—something you already use—from scratch

You’ll learn to keep the focus on what people are doing, while decomposing into the things your organization designs, and how development happens.

• Bring user experience to the project early and often, while still letting the Agile folks move forward in their process of breaking everything down into little pieces
• Explore ways of describing user experience with Agile stories, and get involved with the “what to build” part

How to overcome the Agile dogma that often starts projects off on the wrong foot

You’ve heard stories and are suspicious, or maybe even had an experience of your own.

• Make sense and avoid trouble in your projects when talking about the user experience, something seemingly antithetical to the agile process
• Story mapping gives you an intermediate structure to represent both the big business “whys” and the specific development “whats” of what the user is trying to do

Why the story mapping vocabulary can alleviate the lack of common understanding that comes with tying Agile & UX together

Between project management, developers, and the UX contingent, you can get everyone on the same page with the terms you introduce and define.

• Use language that still helps you plan and track progress, but doesn’t lose the user experience
• Succeed in working with others on your team who may not be UX-literate, using story mapping as a conversation piece and a collaborative element

You can put this process in place for projects you’re working on right now

Regardless of how far along your team is on a project, it’s never too late to put this technique in play.

• Take control of current projects. Use story mapping to ensure the user experience is an integral part of the product you deliver.
• Reap the rewards of story mapping when you’re stuck, or unsure of next steps, even several iterations into a project

A team deep in the Agile process need things at a certain time, in a certain way. That’s foreign to the traditional UX effort. Story mapping is a way to merge these two worlds. Jeff will dig into why the two approaches are different, and what user experience professionals will do in this Agile environment.

Start story mapping in your agile environment and you’ll be tightly integrated as active team members in the whole development process, and not added as an afterthought. Others will see you as a critical contributor to the process of what to build, and in framing and delivering your product. Join us on September 1.

Get Jeff’s Agile Primer:

Register before August 25 and get complimentary access to Jeff’s 2009 virtual seminar: An Agile UX Primer. Agile refers to a class of processes, and Jeff’s the guy we turn to for this aspect of the design and development world. It’s not a prerequisite, but it’ll add to your takeaways from Jeff’s seminar on Sept. 1.

“Hi. I’m a designer at [a big deal company] and I’m considering leaving. The problem I have is my employer has made it very clear I can’t use anything I’ve done here in my portfolio. What should I do?”

The work product lockdown is something many designers face, as they grow their careers and try out new opportunities. It’s natural that prospective future employers will want to see what you’ve done. It’s hard to show them when your designs, sketches, and deliverables are locked up behind a corporate non-disclosure agreement.

In future posts, I’m planning on talking about what people can show in their portfolio if they don’t have work products available (or even if they do), and what the best hiring managers look for when reviewing a portfolio.

However, today I want to talk about this from a different angle: Making it part of the hiring agreement.

I think every designer (especially every experienced, senior designer) considering a job at a new organization should ask explicitly about the hiring organization’s policy on including the work in future portfolios. Their answer should be on the table and negotiated, just like salary and benefits.

When should you ask?

In any hiring process, there’s two stages: The first stage is when you, as the candidate, get the hiring manager and company to fall in love with you. It’s all about showing what you can do and how you’ll help them achieve their goals for the position. You’re goal in this stage is to get the company to think you’re the most awesome person ever for their position and they should jump through every hoop to get you on board.

The second stage is when the company gets you to fall in love with them. Their goal in this stage is to prove to you that they are the best place ever.

It’s in the second stage that we can talk about the portfolio, between when they fall in love with you and when you are deciding the job is the right next step. It’s quite within the rules to say, “What’s your policy on employees including screen shots, sketches, and other work deliverables in their portfolio?”

The hiring manager may not know. It may be something they’ll have to ask HR or even the legal office about. At small companies, they have never even considered the question because you’re the first to ask.

However, it’s a really fair question. And, frankly, any answer is a fair answer.

They might say they want to protect their designs from getting in the hands of the competitors. Therefore their policy is to refuse permission to publish work (especially unreleased design work).

Public companies, who have trouble when future plans are leaked, thereby creating a possibility of “insider information” getting out, are very likely to refuse this without including a Safe Harbor statement. (A safe harbor statement basically says that investors shouldn’t use the information as any indication that the company intends to do anything with it.)

Or they might say they have no problem with you putting the documents into your portfolio, but they’d prefer that you don’t put it in a publicly accessible place, like a web site that anyone can get to. They might like you to only show it to people on an as needed basis, asking those individuals to not share it beyond their own team.

Ideally, they come back and say it’s perfectly fine. There’s not reason you can’t take your work with you as you grown your career. (After all, they benefited from your previous employer’s generosity in this matter. Pay it forward.)

Any of these answers are ok. The point isn’t that you badger them into heading in a direction that they aren’t comfortable with. The point is they tell you, up front, before you take the job.

Once you know, you can decide if this is a deal breaker or not. The fact that you asked tells the hiring manager that it’s an important detail to you. That you’re thinking about your long-term career.

(Of course, one argument is that it sends a message that you’re thinking about leaving the company even before you got the job. Personally, I think that’s ok. In this day and age, we don’t expect life time employees. Any company in denial of that fact may not be the kind of place we want to work. It’s good for an employer to realize that each employee has a choice to stay or go.)

As a discipline, our goal is to bring awareness to the hiring companies. To let them know that this issue is an important one for many professionals.

We’ll know we’ve succeeded when hiring companies start putting their openness to including work products in portfolios into their recruiting ads. When they cite unlocked work products as a benefit of choosing them to work there, we’ve arrived.

Then, someday, this will disappear as an issue, as it becomes part of the standard way we all do business.

The Most Valuable UX Person In The World

She builds her wireframes with real wire from ancient hand-smelted Ukranian steel.
Her worst personas could kick the ass of your best personas.
His pattern library is now in the Library of Congress.
When she explains good design visuals, the only thing Edward Tufte can add is “What she said.”
He’s organized his wine cellar in order of awesome.
Wikileaks is ready to release her sketchbooks just because they’re cool.
He only sketches on the front of the napkin.
He built the world’s biggest web site, using only his left hand.
Last season’s American Idol featured her concept maps.
His research finds customers desire to research his behavior.
He is the only person Don Norman agrees with.
She makes her own icons out of straw.
Software bugs specifically ask for her to fix them.
He defined the damn thing, then moved on.
Her study participants screen themselves. Out.
Her interactions are the basis for everyone else’s designs.
Scalpers sell tickets to his project kickoff meetings.
He is already coding in HTML6. And has been for a decade.

They are the most valuable UX person in the world.
“Design well, my friend.”

What would you add to this list? Leave your own ideas of the Most Valuable UX Person In The World in the comments. I’ll be sprinkling your best suggestions through out my presentation, giving you full credit.

Oh, by the way, the early bird price for the Summit ends this Friday, February 18. Sign up here. I’d love to see you there.

Julie Zhuo

The designers at Facebook try hard to make Facebook users happy. It’s a hard-to-please audience, and there’s 350 million of them. As Facebook’s Product Design Manager, Julie is at the front of the storm, designing for the site that’s grown from 8 million college students to its current worldwide audience.

She’ll be sharing some of her team’s successful and not-so-successful design experiences, so we can all learn from their experience. The interesting part is that many of the problems they face are just like the ones we face, and their solutions are quite creative. You’ll hear Julie’s experiences at our San Diego stop on the tour.

Christian Crumlish

Many web applications, whether on intranets or public facing, involve making connections with other people. From the address book and contact list, to messaging and content sharing, we see more web apps helping people communicate and collaborate.

We can’t think of a better person, to introduce social features into your web-based applications, than Christian. Working with his co-author, Erin Malone, they have compiled an amazing library of patterns in their new book, Designing Social Interfaces. We’re excited to have him as one of our masters on this tour and can’t wait to hear what wisdom he’ll be sharing with us. We’re fortunate that Christian will be at each stop of the tour.

Stay tuned. We should have more additions to the program tomorrow. And we’re adding more to the site every day, as we get ready for the launch in a few days! Watch along at uietour.com.

Activity Option #1: Making a PB&J Sandwich
Minimum Time: 20 minutes
Goal: To enforce the importance of clear user assistance

This is a classic. (I first saw it demonstrated in 1972 by my sixth grade English teacher and I think it’s the only thing about her class I retained.) You ask each attendee to write down instructions for assembling a peanut butter & jelly sandwich. Then, taking the raw materials (bread, peanut butter, jelly, a knife) and a randomly chosen set of instructions, you proceed to follow the directions LITERALLY.

For example, if the author never mentions removing the bread from the package, you proceed with to assemble it with the bread still in the bag. “Put the jelly on the bread” is funny in that context. The more literal you interpret the instructions, the funnier it gets. Make the point that this is what real people do when they don’t realize it.

Activity Option #2: Testing Lego Construction
Minimum Time: 40 minutes
Goal: To enforce the benefits of usability testing

We use this for training people on simple observation and moderator skills. We purchase inexpensive Lego sets (well, as inexpensive as it gets, like this one) and have small teams conduct a sample usability test, with one person assembling the kit and two others acting as observers (or one as moderator, if we’ve done the training).

If you can’t get the budget for Lego sets, it also works with origami sets (and there’s a ton of origami instructions on the web).

Activity Option #3: What’s Changed?
Minimum Time: 10 minutes
Goal: To help participants see the impact of the work you’ve done

This is a good way for people to see how you’ve had an impact on their work. Show before and after screen shots of designs you’ve worked on, without explaining the differences. (Ideally, you can display them simultaneously on two screens or have high-res printouts they can compare side-by-side.)

Have the audience suggest differences. Then, ask them to provide reasons why you might’ve made them. You can compare their rationale to yours. It’s a good opportunity to explain the research you’ve done and how it has influenced your approach to design.

Activity Option #4: The Focus Quiz
Minimum Time: 15 minutes
Goal: To demonstrate how focus can change during observation

We use this to train teams on how to observe during field studies. (I wrote about it back in 2006.) You give each person a different criteria to observe in the room (such as “all the round items”) and ask them to write them down.

Then, you have the people with the same criteria to name objects they observed without naming the criteria. Everyone else tries to guess the criteria. It’s a demonstration of how you notice some things only when you’re trying.

Activity Option #5: Guess the Reason
Minimum Time: 15 minutes
Goal: To show the differences between observations and inferences

We use this to train teams on the difference between an observation and an inference. You display a screen shot and cite a specific observation from testing or analytics, such as “6 out of 8 participants we observed didn’t scroll beyond the first screen.”

Then you ask the audience to suggest reasons why this might’ve happened. What was it that made the users behave that way? We use the different answers to show that different inferences could result in different changes to the design. We then talk about how we’d construct research to identify which inference is the one we should design for.

Activity Option #6: Human Bar Charts
Minimum Time: 15 minutes
Goal: To demonstrate the range of individual differences and to collect data on audience diversity

This is a new exercise we just started doing. It has the benefit of demonstrating how people are different, while giving us some data on our audience. We pass out a survey with scales, such as “On a scale of 1 to 5, rate how important these features are to your work” (and then we list 5-10 features that the audience would use).

Jeff Patton told me he’s done this with two dimensions simultaneously. He created two 1-to-10 axis on the floor, then had attendees in his workshop stand at the intersection of “How well their organization implemented Agile techniques” and “How well their organization implemented UCD techniques”. It gave him a great snapshot of how many folks were well versed in both issues. (During the exercise, he used the mic to have some of the “outliers” explain what their organizations were or weren’t doing.)

Activity Option #7: KJ Analysis
Minimum Time: 40 minutes
Goal: To identify top issues surrounding a focus question

If you’ve got 40 minutes and a good wall for post-its, you can do a KJ analysis. Posing a focus question (such as “What’s the most important change you’d like to see in our product?”), you have groups of 8-10 folks walk through the brainstorming and organizing steps, concluding with ratings.

The largest audience I’ve done this with is about 340 people (34 teams of 10 in a very large ballroom). Every team worked on the same focus (“What can we do to improve our field?”) question and practically every team came up with the same top 3 answers. It was amazing how much consensus there was, even though everyone worked in separate teams.

I’d be interested in any exercises you’ve come up with. Finding new ways to talk about what we do in interesting and engaging ways makes me very happy.

I’ve posted the slides above and have synched it up with audio from the conference. (Unfortunately, there was a mic-input problem during the recording and they ended up using the built-in mics instead of the sounds system. So, the recording is noisy and unintelligible in places. Sorry about that.)

Here’s the description of the talk:

Journey to the Center of Design

User-centered design was born in the 1980s, amidst a world filled with frustration with blinking VCR clocks and computer command lines. Up until this time, developers focused on making the devices work, giving little heed to how they’d be used. Terms like “user friendly” and “easy to use,” buzzwords for the UCD movement, soon became as common as “new and improved” on laundry soap.

We guarantee a journey that shouldn’t be missed.

| View | Upload your own

You can download the slides (without audio). On the Slideshare site, you can view this presentation full screen to see the details.

What do you think of this presentation?

Cities, Dates, and Program Details

April 3 in Boston, May 16 in Chicago: Steve Krug’s workshop, Don’t Make Me Think: Discount Usability Testing

April 4 in Boston, May 15 in Chicago: Lou Rosenfeld’s workshop, Site Search Analytics for a Better User Experience

Special Discount for Our Readers

If you enter discount code UIEPAL, you will receive $100 off each workshop. If you sign up before the early bird deadline using promotion code UIEPAL, you will pay a discounted rate of $695 for one workshop and $1195 for both workshops — a savings of $100 off each day.

Sign up today for these fantastic workshops.

Join me and other web designers, usability professionals, information architects, interaction designers, content managers, and other user experience professionals as we meet, greet, and connect up with other folks who face the same challenges we have.

I’ve chosen the Waterfront Restaurant on Embarcadero at Broadway. It’s got great views of the bay and is near the Embarcadero BART/Muni station and on the famed F-Line. If the weather is nice, we’ll be out in the outside seating area, otherwise we’ll take over the bar.

San Francisco Social Hour – Monday, 8/6 – 5:30-7:00 pm
Waterfront Restaurant
Pier 7 at Embarcadero/Broadway
San Francisco, CA 9411
Phone: 415-391-2696
Map here

No RSVP necessary.

Hope to see you there!

Last week’s winner was Cat – Congratulations! We’ve sent you an email with the details.

For the rest of you, I’ve got great news. We have a new podcast survey available to participate in this week, and we’re offering another $25 iTunes or Amazon Gift Certificate to a lucky participant.

If you took last week’s survey, you’re welcomed to take this week’s survey as well. However, we would ask that you simply answer the survey in regard to a different podcast.

We appreciate your feedback!

Here are the details:

What: The July Meeting of ACM Puget Sound SigChi
Date: This Tuesday, July 10th
Location: The Boardroom in the One Union Square Building, Seattle

No registration is required for this free meeting of interested professionals. Please feel free to forward this message.

Networking starts at 6 pm, with the presentation at 7 pm. Job announcements will follow.

Description
Experience design is no longer a nice-to-have luxury of a few organizations with tons of money and exceptional visionary management. It’s become commonplace for organizations that build products and web sites. Experience Design is a centerpiece of boardroom discussions and quickly becoming a key performance indicator for many businesses.

However, you can’t just hire a couple of “experience designers” and tell them, “Go do that voodoo that you do so well.” Today’s business environment forces us to build multi-disciplinary teams, compiling a diverse group of skills and experiences to handle the many facets of the technical, business, and user requirements.

In his usual entertaining and insightful manner, Jared will talk about what it takes to build a design team that meets today’s needs.

He’ll demonstrate how successful Experience Design:

+ Must integrate the needs of the users with the requirements of the business
+ Is learned, but not available through introspection
+ Must be invisible to succeed
+ Is cultural
+ Is multi-disciplinary
+ Thrives best in an “educate and administrate” environment

You’ll see examples of designs from Apple’s iPod, Netflix, the Mayo Clinic, and Southwest Airlines, to name a few.

Location and Directions to the One Union Square Board Room. The meeting will be held in the Board Room of the One Union Square building in Seattle, (600 University St, Seattle, WA 98101-1176).

I-5 SOUTHBOUND

* Take the Union Street exit
* Turn Left on the Seventh Avenue Drive-thru (first light just after the Union Street exit)
* The Seventh Avenue Drive-thru travels under Two Union Square. The Garage entry is mid-block on the right. There is a fee for parking in the garage.

I-5 NORTHBOUND

* Take the Seneca Street exit
* Turn right at the first light onto Sixth Avenue
* Take a soft right at University Street (Be careful to stay left of the concrete divider separating University Street from the freeway onramp. Turning hard right will put you onto the Freeway)
* University Street curves left and becomes the Seventh Avenue
Drive-thru behind Union Square. Look for the sign indicating the parking garage entrance on your left. There is a fee for parking in
the garage.

In the Parking Garage

* Park near the West garage elevators. Take the West elevators to the Fireplace Lobby. At the Fireplace Lobby, walk toward One Union Square to your right. As you exit the Fireplace Lobby you will see escalators on your left. The Union Square Boardroom is located directly behind the escalators.

If you’re interested in this sorta stuff and you live in the greater Seattle area, I highly recommend you get on the Puget Sound SIGCHI announcement list. You can sign up by sending an email to pssigchi-announce-on@quibble.com

Here’s Kyle’s announcement:

Come out and join other UX professionals in the Seacoast NH, Southern NH, and Southern ME regions for drinks and networking!

This will be an excellent opportunity to meet fellow usability professionals, information architects, interaction designers, and other professionals that fall under the User Experience umbrella to share experiences and learn about job openings in the area.

This is the first of many networking events we expect to have in this area. Our goal is to foster the growth of the local UX community and, if there is enough interest, to eventually start a new UPA chapter.

Please pass this announcement on to anyone you think will be interested.

When: Tuesday, June 19th
6:30 PM – 8:30 PM

Where:
AK’s Bar & Bistro (2nd floor)
111 State Street
Portsmouth, NH 03801

Street Map here.

Parking Map here. (street parking is also available)

RSVP:
You must RSVP to attend, as we need a head count for the venue. Send RSVPs to Kyle Pero. You will receive an email confirmation once your name has been added to the list of attendees.

+ + +

Stay informed about NH UX meetings and events by joining the NH-UX Yahoo group.

I’ll see you there.

Technical writing was born of the post-war fifties, amidst a heavy push in technological industrialization. Factories were mass producing goods at a tremendous rate, for consumer, industrial, commercial, and military use. These goods were taking advantage of the new sciences, which brought forth new capabilities and features.

In these early days, human factors and ergonomics were not for consideration in the product development process. Making the product work at all was difficult enough. The product developers expected, having made the investment in the technology, the user would take time to learn to use the device properly, starting with reading the manual.

Thus, the profession of technical writing came into its own, as a way to shift the responsibility of usability from the development process to a post-development documentation effort. Any complexity was “written up in the manual” for all to read.

Translating complexity into a manual was a difficult skill, but one suited for english majors, playwrights, and poets. Since it was a difficult skill, salaries were higher than other jobs for liberal arts graduates, so it attracted some very talented folks.

In the sixties and seventies, we saw a huge explosion of technology, much of it exceptionally complex. This made documentation creation even more important. Tight development schedules and the need for clear documentation put demands on the profession in new ways. The skills for producing clear documentation quickly became highly valued.

In the eighties, we saw the advent of personal computers. Ironically, as the size of the technology decreased, the size of the documentation was growing. (The documentation Digital Equipment Corporation’s MicroVAX, for example, weighed three times the hardware it described and required an entire palette for delivery.)

The late eighties brought several trends to technical writing:

• Minimalism suggested a task-oriented approach to describing only what the user absolutely needs, allowing the interface to be as self-descriptive as possible.
• On-line help required braking narrative description into self-sustaining chunks, which the user could read in any order (or not at all).
• User-centered design brought a new awareness to the design process, simplifying the knowledge necessary to operate the devices.

At this point, I began to see the writers really starting to struggle to find their place in the organization. As the development de-emphasized large manual, the talented writers quickly shifted their emphasis into usability and interaction design.

The web, which would seem a natural place for the writer with its heavy emphasis on good copy, wasn’t an easy transition for most technical writers. It quickly became a haven for copy writers, a different skill, focusing on more persuasive than descriptive writing.

Even worse news, today’s design environment emphasizes multi-discipline generalists, instead of especially-skilled specialists. Writing is no longer a separate function of the design team. Instead, it’s now integrated into the design process with other functions. Everyone on the skill needs good writing skills, along with the other skills necessary to produce quality designs.

The writers left in the field today are feeling pushed out of their jobs. Salaries have dropped considerably. Demand is significantly down. Young writers are not entering the profession at the rate they used to, leaving an aging technical communication community.

It’s no surprise that the two most popular topics at the annual conference are user experience and interaction design. Both are growing areas, while the art of writing manuals is going the way of blacksmiths and radio operators.

Technical writing won’t be gone until the last writer dies, but it will be curious to see what happens with the field as we move into a world where intuitive design implies a manual-less existence.

Join me and other web designers, usability professionals, information architects, interaction designers, content managers, and other user experience professionals as we meet, greet, and connect up with other folks who face the same challenges we have.

Minneapolis/St. Paul Area Social Hour – Monday, 5/14 – 5:30-7:00 pm
Zelo
831 Nicollet Mall,
Minneapolis, MN 55402
Phone: 612-333-7000
Map to Zelo

No RSVP necessary.

Hope to see you there.

The Intranet Innovation Awards are global awards that celebrate new ideas and innovative approaches to the design and delivery of intranets. The goal is to find these ideas (whether large or small), and to share them with the wider community.

** Uniquely, these awards recognise individual intranet improvements, and not intranets as a whole. **

Intranets must innovate in order to prosper; they must constantly grow and evolve to better meet the needs of the organisations they serve. While there can be no single ‘best intranet’, there are innovative ideas and approaches that warrant recognition.

The Intranet Innovation Awards have therefore been established to celebrate the great work done by intranet teams across the globe, to give them the recognition they deserve.

Gold Awards are given across four different categories, each focusing on a specific aspect of intranets. Platinum Award winners are then chosen to recognise the most extraordinary entries for the year.

These awards are about improving all intranets, by increasing the pace of innovation across the whole of the intranet community. Every idea, no matter how small, adds to our understanding of what it means to have a successful intranet.

The Intranet Innovation Awards have been created by Step Two Designs, a recognised thought-leader in intranet strategy and design. These are also truly global awards, supported by a network of intranet-savvy organisations from the US to the UK, Europe and beyond.

Full details on the awards (including the entry form) are available at Step Two’s Intranet Innovation Awards site. Due date for submissions is May 15.

Present for the call were Jared Spool, DeWayne Purdy, Lyle Kantrovich, Kyle Pero, and Nate Bolt. You can meet the crew here.

You can fin the first episode and more about what’s in this episode here.

Here’s a feed that iTunes likes.

We’d love to hear what you think. Leave your comments on this page or you can write us at SpoolCast@uie.com.

Present for the call were Jared Spool, DeWayne Purdy, Lyle Kantrovich, Kyle Pero, and Nate Bolt. You can meet the crew here.

You can fin the first episode and more about what’s in this episode here.

Here’s a feed that iTunes likes.

We’d love to hear what you think. Leave your comments on this page or you can write us at SpoolCast@uie.com.

Present for the call were Jared Spool, DeWayne Purdy, Lyle Kantrovich, Kyle Pero, and Nate Bolt. You can meet the crew here.

In this episode, the SpoolCast crew convened to discuss:

• the impact of the pending Target Suit
• mixing automated and in-person testing techniques
• multi-variate testing
• designing tasks for testing
• moderated vs. unmoderated testing methods
• using Flash and AJAX on home pages
• the importance of validating inferences
• the interface paradigm of the Nintendo Wii
• the impact of new devices, such as the TiVo, Wii, and Guitar Hero on future interface design

We’ve divided the recording into three parts to make it easier to digest…
Part 2 is available here.
Part 3 is available here.

(Here’s a feed that iTunes likes.)

Sorry it’s taken so long to get this one out. It’s been crazy ’round here!

Production assistance on this SpoolCast from Brian Christiansen.

We’d love to hear what you think. Leave your comments on this page or you can write us at SpoolCast@uie.com.

Brian did a nice job of writing up his impression here.

If you’ve never had a chance to catch Ed’s show, it’s well worth it.

Join us and other web designers, usability professionals, information architects, interaction designers, content managers, and other user experience professionals as we meet, greet, and connect up with other folks who face the same challenges we have.

San Francisco Bay Area Social Hour – Monday, 2/26 – 5:30-7:00 pm
Compadres Mexican Bar & Grill
3877 El Camino Real (Between Page Mill Road and W Charleston Road)
Palo Alto, CA 94306
Phone: (650) 858-1141
Map

No RSVP necessary.

Hope to see you there.

“Lots of people were talking about how wonderful usability studies were” Rolf points out. “I tended to agree with them because I had seen myself the enormous political impact a usability study can have. But then I was curious and said, ‘Are they reproducible?’”

He shared his thoughts on a usability list serv, got four volunteers, then launched CUE-1. This study looked at a Windows application, having the participants test it in any way they saw fit to try and identify usability problems.

The results were presented at UPA 1998. Though “everyone in the crowd thought it was interesting,” there was also some resistance, something that Rolf would become used to over the years. He notes, “People said, ‘This just can’t be true. The results just can’t be this diverse.”

…

Undoubtedly, the most important finding of the CUE studies has been the diversity of the results. In explanation, Rolf points to the simple number of usability problems in the average system: “If you have 500 problems to choose from on a non-trivial website, and the usability test basically finds 40 problems more or less at random, then it’s no longer a surprise when you get these different problems.”

What’s the solution? Interestingly, Rolf doesn’t see it as increasing the number of users, or other methodological changes. “The solution is a much more radical one,” he states firmly. “It’s prevention. Many of the usability problems we have seen should have not occurred on the website in the first place.”

Read the article.

The problem I’ve seen in testing with very long forms (particularly when people need to enter information carefully, as with financial data) is that they are difficult for people to check over before submitting. Errors can be hard to find because it requires scrolling up and down the page to locate them. And, if something technically goes wrong, people potentially have a huge amount of re-entry to do.

We have found that users perform a long data entry task more quickly and with fewer errors when it’s broken into shorter steps rather than presented as a long, scrolling page. And with Ajax, you can design the flow so that it occurs smoothly within a single page (rather than requiring a “jumpy” page load for each step).

Yes. Yes. Agree completely.

(If you’d like to get all of the Brain Sparks Audio Library in iTunes, just paste this link into the Subscribe to Podcast feature.)

This is the inaugural episode of a new show we’re temporarily calling The Josh and Jared Show. Every few weeks, my colleague Joshua Porter and I will get together and discuss the interesting happenings in the world of experience design.

This episode focused on the role of information architecture and some of the changes the discipline is undergoing. Among the things Josh and I discussed in this episode are:

• Josh’s post: Why do People Tag?
• Gene Smith’s Tagging Cheat Sheet
• Differences in tagging on Del.icio.us and Flickr
• How important is the categorization of items on Amazon?
• The weak way Best Buy for Business does categories
• Josh’s war on information architecture
• When is completeness necessary for an information taxonomy?
• Will there be an evolutionary change in how law firms organize electronic information?
• Would you call the people working on Netflix’s movie recommendation system Information Architects?
• The difference between Specialists and Generalists

We want this show to be interactive. Send us your thoughts and questions. You can post them as a comment to this blog, send them in email, or use the feedback feature of uie.com. If you’re really adventurous, send us a short (30 seconds or less) audio comment as an MP3 file and we’ll include it in a future episode.

One way you can help us is to suggest new names for the show. While Josh & I are both fond of our names, we think the show could be named something more creative. What do you think?

• THE USABILITY ENGINEERING LIFECYCLE
  Instructor: Dr. Deborah Mayhew
• BACK TO THE FUTURE: UNDERSTANDING XHTML AND CSS
  Instructor: Chris Hass
• USER EXPERIENCE VISION AND STRATEGY
  Instructors: Sarah Bloomer and Lori Landesman
• WRITE LIKE A CHAMPION
  Instructor: John Maguire
• THE ENLIGHTENED APPROACH TO CREATING USABLE SYSTEMS
  Instructor: Matt Belge
• ONLINE HEALTH COMMUNITIES
  Instructor: Lisa Neal

I know these folks (Deborah and Sarah are previous UI Conference speakers and Lori worked at UIE before ending up at IBM) and they are all sharp folks. This is a great way to learn some critical stuff at a great price.

More details here. (Tell them I sent ya.)

Joel doesn’t think too highly of the process, saying

Software organizations tend to reward programmers who (a) write lots of code and (b) fix lots of bugs. The best way to get ahead in an organization like this is to check in lots of buggy code and fix it all, rather than taking the extra time to get it right in the first place. When you try to fix this problem by penalizing programmers for creating bugs, you create a perverse incentive for them to hide their bugs or not tell the testers about new code they wrote in hopes that fewer bugs will be found. You can’t win.

Joel’s point, a good one, is when you measure the productivity of individuals, you have to be careful of gaming. He implies that you can’t build a measurement system for programmers that can’t be gamed.

That may be true, however, I’m not sure gaming is always a bad thing.

Part of the problem with the measures Joel spoke of was they ignored any valuation on quality. They focused on function points and lines of code, two easy-to-measure quantities. Code quality is not so easy to quantify, so we tend to not try to measure them. (After all, who wants to get into arguments on whether something is quality or not.)

Someone really smart (not me and I don’t remember who) once said, “Once you remove ‘quality’ as a requirement, everything gets a lot easier to build.” Well, once you remove ‘quality’ as a measure of success, then the measures become a lot easier, but they don’t necessarily measure what you’re looking for.

In Ziya’s post, he posited the same problem would occur when designers try to measure their own productivity. After all, what do we measure our design team on?

Maybe I’m an optimist, but I believe it’s possible we can arrive at productivity measures that work (meaning, when gamed, they produce the results we were hoping for) for design teams. These measures would quantify the results the team produced and compare them to the effort it took to produce it.

From there, we could determine what practices and skills are most efficient at gaining the best results. We can also use these measures to help us make budgets and predict timelines.

Right now, we probably don’t know enough to put these measures together. But, just because we can’t effectively measure it right now doesn’t mean it’s impossible. History has shown many examples of things which took a long time to learn how to measure, but someone eventually does.

How would you measure the productivity of your designers?

His premise is an interesting one:

It’s hard to describe what design is because it crosses so many boundaries: fashion, architecture, interaction, and mechanical, to name a few.

But it’s easy to talk about what all those different types of design have in common. One thing is sketching. While a clothing designer is trained very differently from an architect or an industrial designer, they all learn to use sketches as basic starting point.

Buxton asserted sketching was a fundamental activity to ideation. It is a quick way to play with an idea. And it communicates the proper stage of the idea to the viewers. Early, rough sketches just scream, “This is an idea! I’m not done!”

Buxton talked about a study of sketching for traditional design disciplines that showed all had common attributes:

• They are quick to make and timely to talk about the idea
• They are inexpensive and easy to dispose of (making designers less “wedded” to a particular idea because of investment)
• They are plentiful (designers should bring many different ideas-as-sketches to the table, not just one)
• They have a clear vocabulary (such as drawing through the endpoints to show the “unfinishedness” of the idea)
• They use no higher resolution than necessary (so they don’t waste designer’s time and effort in preparation)
• Their resolution does not suggest they are further along than they really are (to avoid giving the impression of being more done than reality)
• They suggest and explore instead of confirming (to support ideation, instead of forcing decisions)

Buxton then suggested “Since Experience Design is a type of Design, it too must have sketching. However, traditional sketching doesn’t work well to represent interactions, so what would sketching for interactions look like?”

Ideation vs. Evaluation

Buxton suggested ideation is a different process than evaluation. In ideation, the goal is to come up with many different ideas, using each idea to suggest others. In evaluation, the goal is to narrow down the choices of ideas, honing in on the best idea. He suggested today’s usability process is evaluation, while ui design is ideation, an idea I agree with.

He made it clear that both ideation and evaluation were necessary.

“It’s like saying there are both girls and boys. One isn’t necessarily better than the other, but both are required and it’s important to know the distinction.”

Ideation has to come first. You generate ideas, which you will subsequently evaluate. So, Buxton suggested that sketching has to come before prototyping.

Sketching vs. Prototyping

The attributes of each are different:

The idea is you create many sketches at first, then narrow them down, until you’re ready to build your prototype to evaluate with. Because sketches are more lightweight and cheaper than prototypes, they are easy to play with and throw away. When you’ve explored the idea space sufficiently, then you eliminate ideas to a basic few, which you then prototype out with the rigor necessary to evaluate.

“It’s about making many good mistakes. I want to have brilliant mistakes.”

This was just a subset of the great ideas in the 90-minute presentation, but I thought the idea of sketching was a brilliant take on the ideation process I hadn’t heard before. (At least, not quite this way.) If you get a chance to hear Bill speak on this subject, I highly recommend it.

Update: Nick shared this link where you can watch a recording of Bill’s presentation.

It’s hard to imagine this could be a bad thing. After all, having people talk about these issues brings awareness. And with awareness, the odds are better we’ll end up with more usable products, web sites, and services, right?

Maybe.

Or maybe not.

I have several issues with World Usability Day. I don’t think I’m alone, but it’s been hard to find anyone else talking about these things. I know that suggesting there’s a downside will probably be considered an act of treason by many of my colleagues, but I think it’s important to get this discussion in the open. Maybe I’m wrong, but if I’m not, the implications are important.

Elizabeth Rosenswieg, Director of World Usability Day, wrote in the August Journal of Usability Studies:

Every citizen on our planet deserves the right to usable products and services. It is time we reframe our work and look at a bigger global picture.

The time is right, the interest is here. ‘User friendly’ is a common and understandable term; people understand that the world should work well. Now, we have to encourage them to take the message to the streets and say, “We will not stand for it anymore, we want our world to be usable.”

No more excuses, no more managers complaining about budgets and schedules. No more marketing people selling functionality and power that is more than we need. No more consumers buying things we cannot or do not need to use.

I’m not sure, in today’s world, usability is the top priority for everybody. Sure, it’s important, but this plea to “take the message to the streets” feels like it could come across as self serving.

But, my big concern is the way we’re going about this. “Usability” doesn’t improve the world. In fact, it doesn’t change a thing.

Today’s usability practice is about measurement and evaluation. Can we determine how usable something is? Can we determine where frustration comes from? Can we determine when we’ve delighted a user (and how to do that again)? These are important things to know, but knowing them, by themselves, doesn’t change designs for the better.

It’s the practice of design where the change comes from. But World Usability Day doesn’t really talk about designing. (In the World Usability Day charter, which they encourage you to sign, the word design only shows up once as a verb. It shows up twice as a noun: poor design and bad design. Apparently, there’s no other type of design.)

Most usability practitioners are not designers. They are an important part of the design process, but they are not the sole contributor. So, this effort of making products more usable needs to include the designers. If we’re going to continue with the holiday idea, maybe we need to rename it “World Design Day” or “World Good Design Day” (no need to celebrate bad design, I guess).

That we apparently call for managers to stop “complaining about budgets and schedules” also leads me to think we’re not very realistic about how business is conducted. Are we actually implying businesses should insist on building usable products, even if it means they go bankrupt?

Pretending we know about business when we really don’t won’t win us any favors with the business community. And, I don’t know how we get funding for our work without their help. Maybe a different tact is in order?

If the likes of Apple, Google, Starbucks, SouthWest Airlines, and Netflix have proven anything, it’s when you make your customers happy, you get profitable business returns. Maybe the day should be “World Good Business Day”, promoting that making customers happy (by providing, among other things, usable products and services) is good for business.

Which brings me to may last point: it’s not clear that usability practice always makes good business sense. There’s no evidence, to date, that strictly following the doctrine of User-Centered Design always produces better market results. (In fact, there’s plenty of evidence to suggest it doesn’t!) There’s a lot that’s not understood about designing quality products, which is why even great design companies like Apple still have duds. We need to do more research into what really makes a difference and what is just the stone in the soup.

A lot of people are gathering in a lot of places today to talk about usability. That’s great.

Yet, if we pretend, on November 14th, nothing in the world is more important that “Usability” and we say and do things to alienate the people we actually need to improve products, we’re going to do more harm than good to our mission. A day to bash designers about “poor design,” without talking about the socio-politico-economic environment that created these designs in the first place, doesn’t help us in the long run.

Let’s put things in perspective and be a little humble about our place in the world. Let’s keep doing good work, involving everyone who can help in the problems we’re trying to solve, and be honest about what we know and what we don’t know. And let’s do that 365 days a year, not just on November 14th.

Happy World Usability Day.

Present for the call were Jared Spool, DeWayne Purdy, Lyle Kantrovich, Rashmi Sinha, Nate Bolt, and Josh Porter. You can meet the crew here.

You can find the first episode and more about what’s in this episode here.

Here’s an RSS feed that iTunes likes.

We’d love to hear what you think of this episode. Leave your comments here or send us an email at SpoolCast@uie.com.

Present for the call were Jared Spool, DeWayne Purdy, Lyle Kantrovich, Rashmi Sinha, Nate Bolt, and Josh Porter. You can meet the crew here.

You can find the first episode and more about what’s in this episode here.

Here’s the final part of this episode. (Here’s an RSS feed that iTunes likes.)

We’d love to hear what you think of this episode. Leave your comments here or send us an email at SpoolCast@uie.com.

Present for the call were Jared Spool, DeWayne Purdy, Lyle Kantrovich, Rashmi Sinha, Nate Bolt, and Josh Porter. You can meet the crew here.

More about what’s in this episode here.

The third part is available here. (Here’s an RSS feed that iTunes likes.)

We’d love to hear what you think of this episode. Leave your comments here or send us an email at SpoolCast@uie.com.

Present for the call were Jared Spool, DeWayne Purdy, Lyle Kantrovich, Rashmi Sinha, Nate Bolt, and Josh Porter. You can meet the crew here.

In this episode, the SpoolCast crew convened to discuss:

• Individual and group card sorting techniques
• Incorporating group elements into individual usability testing
• Collaborative recruitment and social collaborative tools
• Accommodating testing on a social scale
• The state of UX organizations across the country
• Whether World Usability Day is helpful or harmful to the community in the long run

We’ve divided the recording into four parts to make it easier to digest.
Part 2, Part 3, and Part 4 are now available.
(Here’s a feed that iTunes likes.)

Production assistance on this SpoolCast from Brian Christiansen.

We’d love to hear what you think. Leave your comments below or you can write us at SpoolCast@uie.com.

Deep AJAX

A two-day deep dive into developing real world applications using AJAX

Details at www.gbcacm.org

About the Seminar:

AJAX — more an approach than a technology — is one of the hottest topics for Internet developers. AJAX builds rich interactive applications using standard browser technology, enabling delivery of sophisticated user experiences without the problems of distributing and updating client software.

This seminar is designed for Web developers on a deadline and in trouble — or anticipating being in trouble! — who are developing interactive Web applications that stretch the bounds of the possible.

We are taking some of the leading developers of AJAX Websites and tools — people who have “been there and done that” (and lived to tell about it…) — and giving them the time to delve into the details of what it takes to make the AJAX buzzword into real applications

If you are looking for high level overviews, marketing presentations and academic theory, this isn’t the course for you. On the other hand, if you are “up to your eyeballs in alligators” and want to learn from people who have already drained this swamp, then we’ll see you in October!

Speakers:

• Alex Russell – Project Lead for Dojo Toolkit, President Dojo Foundation
• Adrian Holvaty – Lead Developer, Django Web Framework
• Simon Willison - Yahoo! User Interface technology development team

Presented by Greater Boston Chapter of the ACM
Professional Development Seminars
www.gbcacm.org

His color commentary of the animated charts is the best. I wish I had tools to do this!

The video is about 20 minutes long, but you won’t regret watching it.

If you find yourself near Hangzhou in early November, you should definitely check this out.

User Friendly 2006

If you’re going to be in the Sydney area at the end of September, you definitely should check this conference out.

I couldn’t figure out why she was coming, as my I thought my session was for people who were new to information architecture. I thought she just was being polite.

Imagine my surprise when she sent me these kind words this week:

“I don’t know if you remember, but when I ran into you in the lift going down to your workshop at the IA Summit, you said ‘why are you going to this’ and I said ‘because I don’t know everything’. Truly, I learned more useful, practical stuff in that day than anything in the last couple of years. You should see my link-heavy homepages. So, thanks. Even experienced IA chicks can learn stuff!”

Wow! Thanks, Donna!

I’m giving the same presentation at the upcoming Webvisions 2006 conference in Portland, OR later this month. You can read about it here.

The OzIA 2006 Summit and Retreat sounds like a very cool conference. Thomas Vander Wal, Donna Maurer, Dan Saffer, and James Robertson are all cool dudes (and dudette) and on the program. And they’ve created one of the best conference banners I’ve ever seen.

I wish I could go, but the timing is all wrong to venture to the inverse hemisphere. However, if you’re in that quarter of the planet, you should definitely make a plan to be there. That’s my recommendation.

Check out OzIA 2006 here.

On Saturday, I gave a standing-room only presentation called We Are Not Alone: IA’s Role in Optimal Design Teams. People spent the rest of the weekend thanking me, so I guess it was a success. Here’s the session description:

In most organizations, design is not a solo activity. Different individuals, each with their own set of skills, come together to create an ideal user experience. Yet, we know very little about how to form these groups, and, more specifically, how to best do our jobs within them.

By studying several dozen design teams, the UIE research team has spent the last few years looking at how different compositions lead to the most effective results. How do you build a team to produce the best possible designs?

In this presentation, Jared will discuss the three models of design team organization: Consulting, Review &Approve, and Educate &Administrate. He’ll talk about the different approaches that teams take, where they succeed, and where they run into trouble. He’ll also discuss the differences UIE has found between the approach of a centralized user experience team and distributed approaches that put skilled individuals within each of the development teams. He’ll talk about the issues of scaling design to meet the needs of the enterprise once its value becomes realized and the pitfalls of specialization.

LukeW wrote about it here.

A PDF of my presentation slides are here.

The folks at AOL interviewed me about it here. (Or go to the iTunes Music Store and search for “AOL Mountain View”)

See what CNet’s News.com wrote about the program.

Damn, I’m a proud dad.

There are times when its appropriate ask the user for the information again, even though the ‘site’ or ‘system’ may have it. An example would be in cases of database/information maintenance. When done correctly, asking a user to put in information the ‘system’ or ‘site’ has already is a great way to maintain and update user records.

I have to heartily disagree. In the best scenario, you get exactly the same information back that you already had.

In any other scenario, you get different information. But, different ≠ updated. If the new information contains a typo, you could be replacing good information with bad.

There has to be better ways to update information than repeatedly asking users to type the same information.

It’s a members-only event, but the dues are exceptionally reasonable, being that 11 months out of the year they have top-notch speakers (and me the 12th month). It’s only $30 for professionals and $15 for students.

I hope to see you there.

Though we’ve only been at it since July, we feel that blogging has been a very positive experience. So I want to put it out there and see if you have had similar experiences or not. Are you blogging, or thinking about it? If so, do you think that it has been worth it? What has happened as a result?

If you have recently added blogging to your repertoire, we would love to hear about it!

First thank you for your newsletter which I really appreciate, but why do you persist on using tinyURLs? That can’t be user-friendly.

Yes, they might be shorter, but they really don’t make sense. It’s like buying a pig in a poke.

TinyURLs are a service provided by the great folks at Gilby Productions. When you give the TinyURL system a long URL, it comes back with an abbreviated one, like this: http://tinyurl.com/cxsml

We use tinyURLs because the larger URLs often are too long for a single line, requiring many of our readers to go through gymnastics when clicking on the links. When the URL is naturally short ( such as http://www.uieroadshow.com), we skip the tinyURL.

We’ve talked about building our own version of TinyURL (after all, it’s just a simple matter of PHP programming) that could use more mnemonic abbreviations, but so far the priority hasn’t popped to the top of our to-do list.

Of course, if we could count on everyone having the same email reader, then we’d have much better luck matching our newsletter to their needs.

We’ve long been fans of the work of NCM, most recently impressed with their nicely executed design for National Geographic’s Wildcam Africa, where you can spend hours watching African wildlife gather through a web cam at Pete’s Pond, a watering hole in the Mashatu Game Reserve in Botswana.

Unlike many design firms, NCM is extremely user centered in their approach, always focusing on delivering the right experience for the users while meeting the business needs of their clients. They are proof that you can building an agency that can produce snappy creative without compromising the user experience quality. We’ve learned a lot from their approach.

University web sites are a huge challenge and, of all the people we know, we don’t think Virginia Tech could’ve made a better choice.

Congrats and good luck on the project…

“K size” has become a topic of contention in my organization; some people feel strongly that a few KBs one way or the other can drastically affect how quickly a page loads. While I agree page weight may have some effect on this, there are obviously a number of factors that contribute to the download speed of one site in comparison to others.

That being said, does anyone have experience with (or a good resource for) these kind of issues (optimization of download speed, page weight recommendations, etc.)? I’ve been involved in a baffling number of discussions about whether modifying an arbitrary “K size” limit will affect performance (and/or quality), and I’d love to bring closure to the entire debate with some actual facts.

The Philly folks have made me an honorary member, so I throw in my 2 bits every so often. In this case, this is what I wrote:

We discovered years ago that there is no correlation between actual download speed and the perceived download speed. You can read about our findings here.

Recent studies of ours have re-enforced that this is still true. Perceived download speed is far more related to task completion than to actual speed. If users are complaining about download times, you’re much better off focusing on improving task completion than doing anything about page weight.

There are other good business reasons for reducing page weight (such as bandwidth and server costs), but we’ve found it has little effect on user behavior.

You can see what the Philly group is up to here.

Update: My dear friend, former co-worker, and world-renowned author, Carolyn Snyder, is speaking at Monday night’s PhiCHI meeting (11/14). If you’re in the Philly area, you’d be foolish to let this opportunity go by. Carolyn’s a great speaker and the topic is a must-see.

If you’re involved in user experience work, what tools, if they vanished tomorrow, would you sorely miss? Do you use Visio? Morae? Word?

Take a moment. Ponder the tools you use. Pop us a comment below. We’d love to know.

While Dan Rosenberg, SVP of User Experience for SAP, said he had felt the theme for the conference had been “Twenty-year-old practices, when executed properly, still work,” (we did hear a lot of stories from presenters that recently discovering how important prototyping, usability testing, and guidelines are,) I felt that the big theme really was “User Experience is growing up really, really fast.”

I didn’t attend the 2003 conference, but many have told me about their experiences there. They were unanimously excited, repeating that they felt the conference was seminal in their careers as user experience and interaction designers. This was one of the main reasons I wanted to come to this year’s event.

In talking to folks, I think the 2003 event was at a critical period in user experience design. The field was just burgeoning. There were dozens (hundreds?) of UX and Interaction designers, but they were all working as solo artists in environments that didn’t understand their work.

The 2003 conference brought these folks together for the first time, allowing them to see that others, just like them, existed and faced similar challenges to what they themselves faced. The format of that event supported this time: short show-and-tell-style showcases of the work many different folks were doing — an introduction into the breadth and depth of the field. That format worked very successfully to bring this community together and make it into something.

Fast forward two years: DUX 2005 decides to use the same format (5-minute show-and-tell-style mini case studies) because it worked so well last time. Except, in my opinion, it didn’t work so well.

As Bill Irwin brilliantly pointed out in his keynote, when the context changes, the artifact needs to change with it. We’re no longer in a context where this is a new field.

Sure, it’s young. But SAP, one of the largest, most conservative software companies on the planet, has a Senior Vice President of User Experience. Fully one fifth of the 425 attendees to this year’s DUX were from established industries, such as banking and insurance.

UX isn’t a fringe element anymore — it’s now a critical part of many organizations’ strategies to success. This was a point that I think was wholly missed by the conference organizers as there wasn’t one attempt to demonstrate how important user experience has become to these mainstream organizations.

Amidst the many too-short case studies, there were some real gems:

• Jennifer Fraser from Corel talked about a innovation management system that I think is really quite groundbreaking.
• Suzanne Pelican from Intuit talked about how rapid prototyping, while not new, brought innovative, successful products to market in an organization that had stagnated a little too much.
• Tracy Cohen from Avenue A/Razorfish showed how they are using collaborative tools to enhance their inter-team communication.

These presentations (and their subsequent papers) were really valuable. There were some other interesting items of note:

• Abla Hamilton from Bank of America shared how the complexities of the business world — in her case, mergers of large banks — can make the placement of a button extremely complex. We don’t really have tools or methods to help folks design amidst massive amounts of business complexity.
• Mike Kuniavsky, author of Observing the User Experience: A Practitioner’s Guide to User Research, shared how simple tools like a blog, can potentially enhance the adoption of guidelines. (Though I was wondering why he didn’t go the extra step to turn them into design patterns.)
• Jan Chipchase from Nokia gave a very entertaining discussion on Nokia’s design process for innovating new ways to use Bluetooth.

There were a few things that were notable by their absence:

• AJAX
• Web 2.0
• Multi-channel experiences
• Strategic success of UX

The UX field has moved beyond the What is UX? and Who are UX practitioners? questions. From my discussions with many of the conference attendees, they really wanted to know more about How is UX done successfully?, something the conference wholly missed in their program.

The fact that 425 people registered, thus selling out the conference a month before it’s opening session, tells us that this is a very high demand area, or in the common Silicon-Valley-VC parlance, a very under-served market. It will be interesting to see how this market changes before the next DUX conference in 2007.

If you know of a lab, facilitator, and/or recruitment service that can help them, please leave a comment.

If you recruit an inappropriate participant, there is very little you can do with task design, session facilitating, or data analysis that will turn the results into something useful. Yet, if you get an ideal participant, you can compensate for practically any amount of poor task design, facilitation, or analysis and still see valuable findings that will improve your design.

OK-Cancel: Putting Perfect Participants in Every Session

If you’re not going, stay tuned as we’ll have the paper available on the site shortly.

He shared some examples of right-side navigation — Macromedia and Sun — and of left-side navigation — Adobe, Microsoft, and IBM.

In his post, David stated that “industry standards” seem to prefer left-side nav, but his “inner child” likes right-side nav better. He wanted to know what the list membership liked better. Much discussion ensued.

Here is my response, for what it’s worth…

In my opinion, you shouldn’t care what I (or potentially most others on this list) like for navigation. I don’t even think you should care what your users like.

You should only care about which one best accomplishes the objectives of your users and the objectives of your organization.

That being said, having tested a ton of users on bundles of sites, we’ve learned over the years that navigation placement doesn’t matter one whit. Put the navigation practically anywhere on the page and users will find it when they need it.

And, as I discussed here, we’re recommending that our clients spend very little resources on the design of global navigation. It’s rarely used productively (almost always because the site is too frustrating in other ways) and ignored on well working sites.

Local navigation works only when the local links are actually things users will want to go to next. (Either because your previous navigation screwed up and they ended up on the wrong page in the first place or because it’s a logical follow-on to where they are now.) Understanding why users need local navigation and ensuring the link names are communicating the real value of navigating will have more impact on the success of your design than the position or style of the links. We recommend clients focus their resources on ensuring the links give off good scent more than on styling.

Our friends, Kevin Cheng and Tom Chi, the brains behind the great comic strip, OK/Cancel, are auctioning a pencil sketch of their two main characters. The money goes to the Red Cross.

I think it would great on my office wall.