While the successful team needs all of these disciplines, there are more of them than most teams have members. This creates a challenge as teams need to spread the experience, knowledge, and skills across multiple team members, turning them from specialists into generalists.

In today’s UIEtips article, I share some of our recent findings in how teams make the call: when should they hire a specialist and when will a generalist work better? Whether you’re a team manager or someone looking to direct their career choices, I think our findings will interest you.

Read the article - Ideal UX Team Makeup: Specialists, Generalists, or Compartmentalists.

What does your organization do to embrace its failures? We’d love to hear from you. Share your thoughts below.

You have the Visual Design skills to do a good job, but what tools or tricks can you add to your toolbox? Does you team have a complete understanding that Visual design can dramatically improve the experience with your products, and when they’re stuck, how do you help them? How do you deal with line spacing and text size in body text, notes, flowcharts and diagrams that will be good for your users regardless of age? What questions and comments do you have about Visual Design, we’d love to hear your thoughts and experiences.

UIE will put these and other questions to one of the best experts in visualizing information we know, Patrick Hofmann, and we’re excited that he’s agreed to do our next UIE Virtual Seminar - Essentials of Effective Visual Design

In this entertaining 90-minute presentation, Patrick will help you make your products easier to use by applying surprising, memorable design techniques. Patrick, an expert in visual instruction and wordless communication, has worked with usability professionals like you to improve the design of digital, online, and hard copy information.

If you’re interested in attending, you’ll want to register soon, it’s filling up fast. As an added incentive to attend, use the Promotion Code MYARCHIVE to receive free lifetime access to the recorded event. You or anyone in your organization can watch it whenever you want, as often as you want!

Register today at http://www.uie.com/events/virtual_seminars/Visual_PH/

What visual design concepts do you hope to hear explored? What questions are you looking to have answered? What ideas do you have to share? Please tell us your thoughts.

Interestingly, the theme of how to learn from failure was pervasive throughout the conference. Dana Chisnell talked about how to extract takeaways from usability tests. Jeff Patton discussed techniques for learning during the iterations of an Agile development process. Peter Merholz presented his challenges for organizations. And I discussed how teams need to celebrate failures, so teams have a chance to savor the rich insights that come from them.

It turns out that it’s no accident people are talking about failure these days. Over the last few years, our research has shown that the organizations that embrace the mistakes they make are more likely to show growth and improvement in their designs. That’s the great paradox: failure is strategically important to success.

In this week’s UIEtips, I describe how one nameless client got themselves into big trouble, how Amazon.com minimizes the risk from major design changes, and eight common mistakes preventing organizations from getting the most from their failures. I think you’ll enjoy it.

Read the article - Failure Is Not an Option — It’s a Requirement.

What does your organization do to embrace its failures? We’d love to hear from you. Share your thoughts below.

That’s why Dana Chisnell’s session on quick-and-dirty usability testing resonated with so many of the attendees. They realized they could get a research effort off the ground without having to beg for a huge investment. In many cases, they could do it quickly and inexpensively, under the radar, yielding enough valuable information to make substantial improvements to their design.

In this week’s UIEtips, Dana shares how teams are using quick-and-dirty techniques and getting tremendous insights. I’m betting, after you read her article, you’ll see how you don’t need to follow “the book” to learn things that will improve your designs.

Read the article - Quick & Dirty Usability Testing: Step Away from the Book

Have you tried any quick-and-dirty user research techniques? How did they work for you? We’d love to hear about your experiences below.

What should the user do with this little tidbit of information?

An “Invalid State Error” sounds like someone entered the wrong US state abbreviation, but the system a minute ago confirmed the reservation. Someone who doesn’t understand how a digital state machine (like a web server) works probably won’t recognize that error message.

The conditions for the problem are also not very informative, since they are all wrong. In this instance, the user had been interacting with the system without any breaks that took more than a minute, there were no multiple browser windows open, the back button hadn’t been used, and there was no use of bookmarked pages. Not one of these conditions is actually true.

And what does “Please start over.” mean? Is the reservation lost? (Turns out: no.) Were the seat assignment changes lost? (Turns out: no.)

There is no button to start over. Our user wondered if they needed to make a second reservation (that would’ve been a disaster). Fortunately, they were a savvy enough traveler to check out the “Existing Reservations” link hidden deep in AA.com’s menus and found the reservation was there, intact, and all set.

This user didn’t leave the site with a lot of confidence in American Airlines or the site.

How many messages like this does your site have embedded deep in their code? What happens when a user hits one? What kind of experience do they have?

This year, we thought we give our attendees a special UI13 advice podcast. The show covers getting to the conference, a brief overview of the conference agenda, and lots of tips for getting around the Boston metro.

If you’ve never been to the Boston-Cambridge area, it’s a wonderful place to visit. Plenty of history, sites to see and fun to be had. If you’re like me and light on traveling experience, I asked Jared for a bit of basic traveling advice. If you’re a road warrior like Jared, we have advice on getting around for you, as well. Plus, you’ll know where to eat drink and make merry.

If you’re a regular listener to our podcasts, you’ll notice we didn’t put this in our regular feed. We didn’t want non-attendees to become confused, perhaps think we’ve become a travel company or something.

Below you can listen to the podcast in the player (press the grey play button), or download and take it with you.

The UI13 Attendees Podcast — Direct Link to MP3 File

What I think makes these questions magical is their diagnostic quality. From their answer, the team often know what they have to do next. So, the questions not only help us tell whether we’ll succeed or not, they help us understand where we can improve.

What are these magical questions? They deal with three important factors: vision, feedback, and culture. For a more detailed description, you’ll need to read today’s UIEtips article. There you can discover first hand whether their magic can work for you.

Read the article - The 3 Q’s for Great Experience Design

How is your team dealing with the vision, feedback, and culture factors? We’d love to hear!

Robert Nyman does just that with the Nokia and SonyEricsson UK sites and finds some surprising results. It’s quite a good write up.

Very much worth a read followed by the obvious next step: checking your own site out the same way.

[Hat tip to NortyPig]

Because titles often don’t communicate what’s in the article, the implementation gives users a chance to see more by providing a summary as a tooltip-style pop-up.

However, it seems someone has been slacking off, because in today’s list, articles come up with the text “(no summary)”.

Three things about this jump out at me:

1. I don’t typically think of the Wall Street Journal as an organization that slacks off, so the missing summaries feel wrong to me. (Maybe this is all part of Murdock’s plan—first, eliminate the summaries, then eliminate the meaningful content? Worked for the Post. Bring on the Page 6 girl!)
2. On the development side, someone wrote a piece of code that says, in essence, “if there is no summary in the content management system, substitute the phrase ‘(no summary)’ in the tooltip.” That took more effort than just leaving it blank.
3. Similarly, on the development side, it looks like nobody put in an error message when the article is published that said, “You haven’t included a summary and that’s going to make us look silly. Want to rethink that?”

Of course, it’s unlikely that the person pressing the publish button ever goes and sees what pops up in that tooltip. (Ironically, if they’d actually published it as a synopsis that appears with the title, instead of putting it in a mouseover action, they’d see the problem right away and fix it.)

This is one of those little things that reduces the overall quality of the experience. And it’s also a great example of what happens when you spread the design contribution across different roles: developer, visual designer, and editor in this case. All three have to execute perfectly to succeed, with no checks & balances to ensure that’s actually happening.

Seems like we need to learn something from this…

Where would you send a client looking for an article on designing for different browsers and conducting browser-compatibility testing?

One of the downsides of being a researcher and never actually doing the hard work is that you don’t know the answers to the important questions. However, I know people who do. Here are the responses I got back:

Andrew Smith (@somenice):

@jmspool I would recommend http://www.quirksmode.org/dom/compatibility.html and http://browsershots.org/

@rustyspiedel

@jmspool http://www.netmechanic.com/products/Browser-Tutorial.shtml and http://www.justskins.com/design/browser-compatibility/137

Peter-Paul Koch (@ppk):

@jmspool: My quirksmode.org is one of the best resources, even though it doesn’t contain an article about the basics, just lots of facts.
This article looks promising, too: http://anthonyshort.com.au/blog/comments/how-to-get-cross-browser-compatibility-everytime/. Is only about CSS, though.

Amy Stewart (@astewart):

@jmspool check out Browsershots: http://browsershots.org/ and Position is Everything http://www.positioniseverything.net/

Thanks everyone!

If you looked closely, the caps instruct you to log into MyCokeRewards.com and enter the number printed on the inside of the cap. Doing so will accrue points that you can exchange for wonderful goodies.

Going to the site yields this screen:

Unless you’re on a mobile device, like an iPhone:

Now, what are the odds that people drinking coke would be closer to their phone than their PC? Probably pretty good.

A great example of how the designers haven’t taken the user’s context into account.

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.

It’s not clear when “quick and dirty” became a dirty phrase in the usability world. There are those that believe that testing must be scientific, and that takes time and money — luxuries not often available to many development projects.

Usability testing expert Dana Chisnell knows what it means to work by-the-book – she co-wrote “the book” (The Handbook of Usability Testing, 2nd ed.) with Jeff Rubin. In this seminar, Dana will break down the process of collecting user research data, exploring the must-haves, the nice-to-haves, and the certainly-can-do-withouts. You’ll learn how you can answer your essential design questions using methods that would make MacGyver proud.

This presentation is perfect if you have yet to conduct your first usability test. If you’re experienced with testing, Dana will show you some new ways to inject user research into those tight-on-resources projects that keep cropping up.

Register today at http://www.uie.com/events/virtual_seminars/wild/

What questions do you have about Usability Testing in the Wild? What tools or tricks have you used to maximize the resources available, and still deliver quality results? We’d love to hear your thoughts and experiences.

Think of it like a room’s air conditioning. We only notice it when it’s too hot, too cold, making too much noise, or the unit is dripping on us. Yet, if the air conditioning is perfect, nobody say anything and we focus, instead, on the task at hand.

Few people come to a web page to admire its visual design. However, poor visual design is really noticeable and takes the user away from their task. While we often think of visual design in terms of page aesthetics, the real crime comes when it’s the visual structure that gets in the way.

The problem with invisibility is that it’s hard to appreciate. Therefore, it takes skill and practice to “see” what’s actually going on.

In today’s UIEtips, we’ve asked Luke Wroblewski to give us some of that practice. He’s done a sweet job of picking some great examples that highlight the role of visual design behind otherwise invisible first impressions. I learned a lot reading through his article and I bet you will too.

Read the article - Communicate Quick: First Impressions Through Visual Web Design

Have you changed your site’s design to give a better first impression? What did you do? What challenges did you face? We’d love to hear your experiences.

But yesterday was anything but a normal day:

(The green box represents Barrick Gold, which saw a 4.5% increase in its value yesterday. The next biggest winner I could find was Campbell’s Soup at 0.32%. Gold? Soup lines? Hmmm.)

Update: A new day brings a new market bounce:

(A green day should not be confused with Green Day.)

“Find information about the costs for summer camps in Vermont”

the list member asked if there was a problem with using a scenario like this one:

“You’ve got a nine-year-old boy and an eleven-year-old girl. Pretend you need to find a sleep-away camp for both of them and explore what your options are.”

Asking participants to pretend is always a red flag to me. It typically signals that the overall test plan or the recruitment process isn’t doing what it should.

Years ago (before we started number our web versions with things like 2.0), a client asked us to help them with their tests. The agency they’d hired had been recruiting Wall St. execs and asking them to “pretend you’re interested in Leonardo DiCaprio and find out something you don’t know about him.” Of course, these folks weren’t interested in Leo and didn’t work very hard to discover something to satisfy the test moderator.

This prompted us to study the use of scenarios like this in testing. We found that when a participant is pretending, it’s common for their behavior to be very different than when they are actually doing the task for real.

One of the places we kept noticing this was when we watched people shop online. Asking a shopper to pretend to purchase (“Could you find a pair of shoes you might like to buy and put it in your cart?”) produced extremely different behaviors than when we recruited people who needed the product and gave them the cash to make a real purchase. In the former case, they went through motions and skipped steps that we didn’t see when they were considering and purchasing the product for their own true use.

And here’s the kicker: Had the team changed the site’s design based on the data from the pretend purchasers, they would’ve created a design that would’ve prevented sales from the real shoppers. The behaviors were that different. In other words, listening to people pretending could’ve made the site worse and reduced sales substantially. It could’ve been a huge mistake for the team.

The list member mentioned that her clients were pushing this idea, say that they’d “had success with this technique in the past.” If the client thinks “success” means “we watched people and saw things we didn’t think of before”, that might be a good thing. After all, when clients see the design through the user’s eyes, it helps them inform the decisions they’ll make going forward. However, it could also be a bad thing if it leads them in a direction that could make the site worse for people in the real situations.

To help our clients with this, we developed a technique we call interview-based tasks. Instead of asking the participant to pretend, we recruit participants that would likely interact with the design and we interview them to create their tasks in real time.

Instead of asking the participant to pretend “You just got married in the spring and you’re already thinking about a baby,” you would recruit participants that just got married and are considering a new family. (Any good recruiter can find someone like this pretty quickly. If you don’t know any good recruiters, contact me. I do.)

Then you interview each participant about their situation. During the discussion, you and the participant would collaborate to make a task for the test that would be the same scenario as what you had planned, only it will be for real within the context of their life.

[You can find out about interview-based tasks in this article and in this podcast]

Asking participants to pretend could work just fine, as long as they behave the same when pretending as when they are really in those situations. But it could turn out to be a very bad thing. And you won’t know until you compare against real behaviors.

• Because of the economic downturn (due to the rising fuel costs and mortgage market crisis), some companies are laying off and some are disappearing outright.
• Because executives understand the competitive value of creating great experiences, user experience professionals are in great demand.

This convergence means you should have your resume and references up to date. Even if you’re likely only to change jobs within your current organization, having these prepared can make the difference between having a choice and missing an opportunity.

As a hiring manager, I often find people don’t really know how to prepare their references well. This podcast, from the fine folks at Manager Tools, does a great job of explaining how to recruit, prepare, and share your references. It should be a must for anyone who thinks they’d like to grow into a new job, either in the near or far future.

The podcast blurb:

This cast tells you how to handle requests for your references when engaged in a job search.

Even though “References Available Upon Request” is no longer a good idea, reference CHECKING is on the rise and will only increase in the coming years. It seems like since resumes don’t include the age-old line — the why of which we’ll share — somehow far too many job seekers are caught off-guard by reference requests. Ahh, Horstman’s Christmas Rule!

We’ll tell you how to manage and share your references in this cast. And hey, if you’re maintaining your network, this one is EASY!

Sharing Your References at Manager-Tools.com

So, it shouldn’t be news or a surprise to anyone in the world of web site usability that having clear links that describe what the user will find after clicking is a priority in the design process.

Fortunately, making things usable isn’t a priority for the folks at the Journal of Usability Studies, who just released their latest issue. It’s great that they now have online versions of the articles, instead of having to read the PDFs.

However, we think they could do better on the table of contents for the article:

They could say a little more about what the article says in each section, don’t you think? I wonder what would happen if they did a little testing?

All one has to do is look to Apple to see how this works. When iTunes 6.0 came out in January of 2006, they introduced a feature called the mini-store, which, for all practical purposes, bombed.

This past month, in iTunes 8, they reintroduced the same business model, this time with a different interaction design called the Genius. It looks like this new design of the old mini-store is going to be a big contributor to Apple’s next year of revenues. (How much? Well, they are now selling more than 1 billion songs each year. The Genius functionality could easily add another 20%-30% on top of that.)

Some model, different design, huge increase in revenues.

When the business model doesn’t match the user experience or (as was “discussed” in the IxDA.org insane-people’s-death-match thread) when nobody seems to understand what the business model is, the designer can’t know if they are helping or hurting the company by creating a better experience for the user.

Creating a great experience can be an expensive investment. Unless the designer can clearly show the value of that investment, they’ll be constantly fighting the forces of reducing costs to increase profitability. It’s always cheaper to produce crap, so if you don’t understand how quality factors into long term profitability, crap is what will win.

Designers that can’t talk to value in the business model also can’t explain why they themselves should be on the payroll.

This is why understanding the business model is essential to good interaction design.

[Thanks to Robert Hoekman for encouraging me to make this into a blog post.]

I haven’t had a chance to watch voters use either site, so I chose four scenarios that I thought would be common tasks for a voter visiting each site. I rated each site on a scale of one (very frustrating) to five (easy and delightful) scale. (Because I was interested in the design of the site, I didn’t take any points off about the candidate’s positions or message.)

Current News task: What has the candidate said or done about the debates and dealing with the economy in the last 24 hours?

For this task, I looked for any details about what I’ve been hearing in the news. Will the candidate show up for the debates? What is the candidate proposing to solve the economic strife we’re dealing with?

BarackObama.com: 4
There’s an article on the home page that leads to the information. It has a ton of information on both issues in a 16 minute video, but it’s not transcribed, so you have to watch the entire thing.

JohnMcCain.com: 5
There’s an article on the home page that leads to his statements. The site provides a detailed transcript of his statement (which is a good thing, because the audio for the statement is not very coherent).

Specific Issue task: What is the candidate’s position on stem cell research?

For this task, I tried to locate what each candidate feels about stem cell research.

BarackObama.com: 2
The categories in the Issues menu make no mention of this issue. Not found in Ethics, Family, Technology. There is no search function on the site. The Issues page doesn’t mention it. External search found it under Women’s issues.

JohnMcCain.com: 3
The categories in the Issues menu make no mention of this issue. I found it in theHuman Dignity and The Sanctity of Life category. (Sometimes listed as “Values”.) The Search function returns a large number of links, 2 of the first three have no mention of stem cell research. You have to go the seventh result to get to the Human Dignity page (labeled “Values”), but the blurb talks about McCain’s POW experience.

General Issue Task: What differentiates the candidate from his opponent?

I tried to see if there’s any easy way to tell what makes this candidate different. Guess what? There isn’t.

BarackObama.com: 2
They have a 33-page report available for download. The report’s pages don’t print on standard printer without chopping of edge text. Elements of the report are dispersed around the web site, but there’s no summary of positions without bouncing through pages.

JohnMcCain.com: 3
I couldn’t find any summary of entire position. Multiple levels of detail (good!) spread across many pages (not good!) with no way to see the entire story.

Make Donation Task: How do I contribute to the campaign?

BarackObama.com: 4
Easy to find the donation page. URL is for the same site. Instructions at the bottom on how to mail in a check (instead of paying by mail). Error messages tell you where problems are. First time small donors still need to put in employer info (not clear). Very little small print. Page design is simple.

JohnMcCain.com: 3
Easy to find the donation page, but it opens in a different window and the URL is for site not associated with the campaign (will people be concerned about phishing?). No instructions for mailing in a donation. Error messages don’t say where entry issues are. It’s clear you always need to put in employer info. Tons of small print. Page design is more convoluted and feels like an eBay order form.

Winner: JohnMcCain.com

If you want to average the scores, BarackObama.com came in with a solid 3. JohnMcCain came in with a 3.5. Both sites have a ways to go to get perfect 5s, or even a solid 4.

The big problem, I think, is the sites don’t do great at letting the meat of what the candidate stands for come to the surface. If someone wants to do some solid research on what these guys are really about, it’s hard to get that from either site.

They may be running for President, but content is king!

Yet, how often do we hear, “Could you give me some feedback on this design I’ve been working on?” It’s likely to be the most requested activity, yet we do little to get better at it. Good critique skills are to be revered, but many of us haven’t learned what it takes, putting our projects at risk and driving walls between team members.

That’s why we’ve decided to take on this very important but rarely discussed topic. In today’s UIEtips article, I look at what makes a well-done critique. Turns out, as we’ve been studying the practices of design teams, that there are specific elements always present in a well-performed critique. Today’s article describes what we’ve seen in our travels.

Read the article - What Goes into a Well-Done Critique?

We’re taking what we’ve learned and putting a demonstration together. On Wednesday, September 24, 2008 we’ll hold our first UIE Virtual Seminar dedicated to improving critiquing skills. Seminar attendees will compare their critiques of four selected sites against my own critique, just to see how we all do at this and what we can learn from. Register for this UIE Virtual Seminar before space runs out!

What elements do you think make a great critique? How has your team incorporated them into regular practice? We’d love to hear your stories and thoughts. Leave a comment below.

[If you haven't signed up for the UIE Virtual Seminar on September 24, there's still room. Sign up today.]

In the preview, I share the four sites we’ll look at in the seminar. Watch the seminar and pick the sites you want to critique. (You’ll want to plan to spend between 15 to 30 minutes exploring each site, then another 15 minutes writing up your thoughts on them. So, if you only have 45 minutes, just pick one site. If you can spare more time, choose accordingly.)

The four sites we’ll look at are:

• NASA
• Management Sciences for Health
• The Hospital & Healthsystem Association of Pennsylvania
• Home Shopping Network

In the preview, I explain what we’ll be critiquing on each site. Doing your own critique is optional, but it’s the best way to get the most out of the seminar. If you’re watching the seminar with your colleagues, there are two approaches: you could each critique a different site, so that you get coverage. Or you can each critique the same site and compare amongst yourselves.

See you at the seminar next week. It’s going to be fun!

Not sure what sessions to attend at the User Interface 13 Conference this October? Or looking for more information on what each session covers and who the speakers are? Then we have the podcast for you. We’re so excited about the content and expert speakers at this year’s UI13, we decided to create a podcast to help make sense of everything.

I sat down with Brian Christiansen and we discussed, in detail, each speaker’s topic, and who the session is targeted for. Our goal with this podcast was to help our registered attendees decide which sessions they’d like to attend, and to give even more information to those who might still be on the fence on attending. (Of course, if you’re not able to attend, you’re still welcome to listen in and hear about the speakers and topics.)

In additon to the content and speaker information, we discussed the myriad of fun things to do in the Boston area when you’re not in session. Want tips on where to dine, see a museum, a band or take a tour? We’ve got your tips right here!

We’d love to know if this podcast was useful in selecting your sessions at UI13 or learning more about the conference. Please share your thoughts with us below.

(Don’t forget, you can find out much more about the conference at the User Interface 13 conference site.)

Little design details are the same. If they are implemented well, the users won’t pay them any heed. If they are implemented poorly — causing delays and confusion — then the users will complain.

The big difference is that when there’s a problem with the little details, most users don’t know how to express what’s happening. It’s unlikely they’ll ask for piece of code or even for the interaction to match some clever web 2.0 site, even though that’s the right solution. They’ll just know something is not quite right and it will reduce the quality of their experience.

One of those little details is when to refresh the page. Years ago, there was no design choice here. The user pressed a button and the page redrew itself. Today’s technology, however, can change that, with Ajax and javascript giving us the power to modify a portion of the page, keeping the rest of the user’s frame intact.

In this week’s article of UIEtips, I talk about how to decide when page refresh is the right thing to do. How do you know when you should put in the extra effort and cost to eliminate it, and when should you put your resources into something else?

Read the article - To Refresh, or Not to Refresh

Eliminating page refresh is often done with Ajax and Javascript –two subjects that our UI13 expert, Jeremy Keith, knows all about. And knowing when it can enhance the design is an interaction design
decision — Interaction Design is what another UI13 expert, Kim Goodwin, is especially good at. Visit the UI13 conference site to learn about their full-day, in-depth seminars.

Have you come up with a strategy to eliminate page refreshes in your design? Did you decide that page refreshes were the better way to go for your users? We’d love to hear your experiences below.

Knowing how to sell usability testing will substantially help it get approved and supported by an organization. Most development teams we work with understand the benefits of usability testing, yet still struggle to communicate the value to stakeholders.

In this week’s article of UIEtips, we’re featuring a popular article that Christine Perfetti wrote last year, which discusses some of the best techniques for getting stakeholders onboard for testing. I think you’ll really enjoy it.

Read the article - Five Techniques for Getting Buy-In for Usability Testing

If usability testing is a concern for you, I highly encourage you to attend Christine’s full-day seminar, Product Usability: Survival Techniques, at the User Interface 13 Conference this October. In this seminar, you’ll learn valuable tools for incorporating usability testing in your development process.

Are you challenged with selling usability testing within your organization? Is your team struggling to get support and buy-in?  How have you gotten your organization onboard? Join the discussion below.

Have you ever thought about how many buttons should be on a mouse?

Bill Verplank has. Bill was part of the Xerox PARC team who was responsible for taking the mouse and many other computing paradigms from theory to indispensable.

I had a chance to speak with Bill about his time at PARC and all of his other influential work for this week’s podcast. If you’re interested in where many of today’s computing metaphors come from, or in design and computing history in general, this is the show for you.

Today’s usability, interaction design, and experience design disciplines have their roots in human factors engineering, which many, including Bill, trace back to the 1950s, when the U.S. government was investing heavily in cockpit design of jet fighters. It was upon that foundation, Bill studied design and engineering at Stanford and did his PhD. work at MIT in man-machine systems.

From there, he spent considerable time with Xerox PARC, working on some of the first office systems, including the Xerox Star, which was a major influence for both the Macintosh user interface and Microsoft Windows. Bill continues to trace his history through some of the most influential design agencies of our time, like IDEO, and winds up with a question of design education: what happens when engineers and artists meet and try to create something usable for humans? Bill is seeing important schools, like the Rhode Island School of Design and Carnegie Mellon University, experimenting with programs that put engineers and artists together. We also debated the impact and interpretation of experience design and its impact on various industries.

Our conversation ended with a preview of Bill’s Spotlight Plenary presentation at our UI Conference this fall. Bill is known for his mesmerizing talks where he sketches his points along with the talk. (At the conference, we’ll have a camera set up so you can watch him sketch as he talks!)

[If you'd like to see Bill Verplank's Design Metaphors Spotlight Plenary keynote in person, please join us at the User Interface Conference, this October in Cambridge, Massachusetts.]

Once they made it to the page with their content, they still struggled. The navigation links and categories were so unclearly written that users weren’t at all sure where to click. They had to work very hard just to figure out what content was available to them on the site.

The content was disorganized, confusing, and lethargic. Fortunately, we knew exactly who to turn to discuss and solve these types of problems. In this week’s feature article, we’re publishing an interview with Donna (Maurer) Spencer, a world renowned information architect.

In this week’s UIEtips article Donna and I discuss how the best information architects successfully tackle specific content challenges. Donna shares the essential skills separating the best information architects from the rest of the pack.

Read the article - Four Essential Skills for Information Architects: An Interview with Donna (Maurer) Spencer

We are so excited by Donna’s work that we’ve invited her to present a full-day seminar, Information Architecture Essentials: Best Practices for Organizing Your Site’s Content, at the User Interface
13 Conference in October. It’s a great place to learn what it takes to become a great information architect.

How have you tackled your site content challenges? In your experience, what skills do the best information architects possess? Share your thoughts and experiences below.

Brian Christiansen and I recorded a special episode comprised entirely of questions from our customers. On August 14, we held the UIE Virtual Seminar - Galleries: The Hardest Working Pages on Your Site. During the seminar, we received far more questions than time would allow answering. As is tradition, we put together this follow-up podcast to answer even more of your excellent questions.

In this episode, we discussed:

• A review of Gallery pages and their connection to Scent
• How Gallery Pages are special, and a comparison to a Department page
• The role of Galleries in Intranet environments
• We dive into the use of “learn more” links with a little more depth
• Our observations about how users really “browse” the web
• Advice on coping with large numbers of links on Gallery pages, and what links belong there
• A preview of September’s Virtual Seminar on Critiquing

If you missed our live seminar, a recording of Galleries: The Hardest Working Pages on Your Site is available for viewing.

Still have questions or comments about gallery pages? Ask them in the comments below!

(Producer’s note: My apologies to the Discount Tire folks for calling you “Direct Tire” once in the episode. I got it right the second time, though!)

The same is true of the article topic in this week’s issue of UIEtips, Design cop-out #2: Breadcrumbs. Like site maps, breadcrumbs are hard to do well. And they are also a treatment of the symptom, with the real problem that the user is on the wrong page to begin with. Work to ensure the only place users end up is on the right page, and you’ll no longer need to provide breadcrumbs to rescue them.

Read the article - Design Cop-out #2: Breadcrumbs

Information architecture — organizing the site’s content to make things easy to find — is just one of the full-day, in-depth seminar topics we’ll be covering at the User Interface 13 Conference, October 13-16, in Cambridge, MA. If you want to learn state-of-the-art techniques from the world’s most renowned experts in design and usability, this is the place you need to be.

What are your thoughts about breadcrumbs, site maps, and other design cop outs? How have you tackled the key challenges in your site’s information architecture? We’d love to hear your thoughts.
Leave us a comment below.

Testing Your Critiquing Skills: Site Navigation
Date: Wednesday, September 24th, 2008
Time: 1pm ET / Noon CT / 11am MT / 10am PT

When looking over someone else’s design, how do you ensure you’re delivering valuable insights that bring new perspectives to the table?

The best critique not only delivers value to the original designer, but to everyone involved, because it raises the discourse to the underlying fundamentals and goals, not just the specifics of color and font size. Learning to critique well is like many other skills: the more you practice, the better you get.

You’ll know you’ve delivered a great critique when:

* The designer is receptive and engaged in the discussion, instead of being defensive and argumentative
* The designer becomes introspective and talks about how they want to revisit some of the underlying precepts of the design
* Other team members use the critique to look at other on-going work

You can read the full seminar details here.

What is the difference between good and great interaction designers?

That is the subject matter for this week’s show, which features a compelling conversation with Kim Goodwin. Kim is the VP of Design and General Manager at Cooper, one of the world’s premier design consultancies, in San Francisco. She suggests that three traits of great designers include design judgment, communication skills, and the ability to observe people’s behavior and then design something that can give them a good experience.

Design judgment is the ability to know if your solution is good or not. Great designers have the ability to look at their own work with a critical eye, and implement outside suggestions that make their solutions better. Effective critique is essential.

• The teams at Cooper follow the fifteen minute rule—if you’re experiencing difficulty with a design for fifteen minutes, get another brain in on the solution.
• Critique early, critique often. Critiques test your solutions and challenge your assumptions.
• Being solo is tough. Don’t have the advantage of a design team? Kim suggests reading is huge supplier of continuous inspiration and education. Analyze well-designed products. Keep sharp by going out and meeting other designers.
• Good judgment comes from experience and experience comes from bad judgment. Failure is part of the system. Failure is an experience imperative to growth.

Communication skills are incredibly important. Active listening skills are important for extracting the most information out of a conversation. Active listening takes practice.

• Listen thoughtfully and dig for the needs behind the words.
• Approach any situation with the axiom “I don’t know what I don’t know.”
• Don’t lock yourself into a solution until you’ve really soaked in the full scope of the problem. When ideas inevitably pop-up, sketch them out quickly, so you can capture the ideas and then clear them away so they don’t distract you from absorbing the total problem.

Be open to the world. Kim’s advice is to make no assumptions, go see the problems.

• Accept that you may not know the problem as well as you think you do.
• There are people that may already have the context and solutions. Explore them.
• Simply be curious about your environment. Designers have boundless curiosity.

Kim has even more thoughts in the podcast about concise communication, time management and collaboration skills, you’ll want to give it a listen.

You can hear Kim Goodwin present her workshop, The Essentials of Interaction Design at the User Interface 13 Conference in Cambridge, MA — October 13-16, 2008. She’ll cover fundamental skills like sketching, workflow, storyboarding; and explore innovative techniques to keep the ideas flowing and designers fresh.

How are you staying sharp and curious as a designer? Share your questions and experiences in the comments.

The problem comes when the patches become, in our minds, mainstream functionality. We call these design cop-outs — when designers patch the symptoms instead of addressing the core problems.

Design cop-outs come in many different flavors. For example, you might let users choose options instead of designing it for them. Sure, some personalization is probably OK, but why should the user decide between a “minimized database” or “maximized for search”? How would the user know any better than the design team what is