Experience Planner

The Challenge

One of my clients is starting work on a global redesign of their registration form, across every site they own. It’s a big deal, and it has the possibility of being very contentious. Multiple areas of the company have a vested interest in the questions, so we need to have a strong justification for every change we recommend.

The client is mostly concerned about getting the right mix of questions that let us gather good, useful information about our visitors without causing drop-off. But this is also a good opportunity to build in some usability best practices that have been missing.

Since our client is awesome, they agreed to run a test. We’re going to design 3 versions of the form, probably representing small/medium/long, and see which one hits a sweet spot in terms of gathering information without causing drop-off. We’ll run all 3 forms at the same time, randomly serving 1 of the 3 to each visitor who registers.

The Solution

Thankfully, Luke Wroblewski just published a book on web form design called… Web Form Design. I picked up a copy and read it during a few short plane flights this week.

In the interest of full disclosure, I should say that I saw Luke speak at this year’s IA Summit and even joined his lunch table discussion group, and I think pretty much everything he says is spot on. So I was predisposed to like the book. But it still exceeded my expectations.

For me, the book follows a perfect outline — exactly the format I want every professional book to follow. It deconstructs the issue of web form design into 14 discrete issues (e.g. “Help Text” “Inline Validation” and “Gradual Engagement”), and focuses one chapter on each issue. Then, within each chapter, he breaks out the various problems and solutions that he has observed within that issue.

The end result is extremely readable, and the content is very strong. Luke makes recommendations based on hard data, common-sense observations, and his own UX expertise. Also, the book comes with a digital version that links to a Flickr library of all the images he used. So it’s easy to take his work and repurpose it for your own presentations.

While researching, I also came across a couple of interesting articles on Smashing Magazine. They did their own research into the most common ways web forms are done. You can read Part 1 and Part 2 here. For me, it’s only somewhat interesting, since it’s reporting more raw data and less actual UX expertise.

Conclusion

I’ll update later with results from the form design project. Stay tuned.

In the mean time, let me recommend a site I just found called Wordle. You can enter in any text you want, or paste in a URL, and it will create an attractive word cloud based on the words in your text! You can even customize the appearance of the cloud. It’s kind of fun, but it’s also useful if you want to quickly pull out the words most commonly used in a source file.

I pasted in the text from Web Form Design and here’s what I got:

Q: What is a “widget”?

A: To understand widgets, we first need to consider the history of the word.

Originally, the word “widget” was used in business classes to describe a non-specific product. For example, business students might play a simulation game in which they were put into teams that sold “widgets”. It was their job to figure out how to differentiate their widget and market it to consumers.

More recently, the word “widget” has been adopted to describe any small application or tool, ranging from a blog badge to a Facebook application. This usage was originated by executives who were shown various small applications and tools and didn’t know how to describe them. So they used a nonsense word.*

The bottom line is that the term widget has been used to describe so many diverse things that it’s not really a useful word any more. If someone starts talking about widgets, or asks you to design one, the first thing you need to do is work with them to figure out what they really want.

*This is not actually true. To the best of my knowledge, the word “widget” was coined by the people who developed Konfabulator (now called Yahoo! Widgets), which was was one of original platforms for hosting small applications on a PC desktop. But I do think the term “widget” has been co-opted by executives and stretched to the point of uselessness.

Q: How do I help someone figure out what kind of widget they want?

A: There are three important attributes to every widget. If you define those three things, then you’ll be well on you’re way.

1. Purpose
2. Audience
3. Platform/Technology

Let’s look at each of those attributes in detail.

Purpose
It’s sometimes hard to know whether you should begin planning a widget by thinking about your audience or by thinking about the purpose of the widget (i.e. the business objective of the widget). My feeling in this case is that you need to decide on the type of activity you want to encourage in users before you go too far down the path of figuring out what your users want. But purpose and audience really go hand in hand, so you need to keep both in mind as you work.

Based on my own observation of widgets, I am proposing 4 high level purposes that a widget may have.

1. Perform a task
2. Provide information
3. Gather information
4. Connect people socially

Note: I will add a page of example widgets that demonstrate each of these purposes in the near future.

Actually, a widget might fulfill several of these purposes at the same time. The key is to ask questions that help determine which ones are relevant.

Example Questions

• Can you do something useful for your audience, like perform some calculations or sound an alarm at an appropriate time?
  Then maybe your widget is meant to perform a task.
• Do you have content that you want to push out at relevant times?
  Consider a widget that provides information.
• Do your users want to provide feedback or give you information?
  Maybe you want to design a widget that gathers information.
• Would your users find it valuable to be connected with other users? Do they have something to say to each other, or do they want to compare themselves against each other?
  Consider a widget to connect them socially.

Audience
Some widgets have only one audience and others have multiple audiences. It’s your job to figure out who the audiences are.

Possible Audiences

• The user who installed the widget
  In most cases, the widget is going to be used by the person who installs it. For example, if I add a widget to my iGoogle page, it’s because I want to see it every time I go to my home page. The widget should be designed solely to meet my needs.
• The friends of the user who installed the widget
  Many bloggers add widgets to the sidebar of their blogs. For example, on this blog I might add a widget that searches the email archives at IxDA. As the blog writer, I already know about IxDA, and I already know how to go there and search the email archives. I would only add it to my blog as a service to my readers. They are the real audience.
• Both the user and her friends
  A lot of Facebook application fit in this category. They provide some value to the user, but they also provide value to the user’s friends who visit her profile page. For example, a Facebook application might be useful to me because it helps me keep track my favorite recipes. But it’s also useful to my friends because they can see the kinds of recipes I like, and recommend more they think I would also like.

Once you have identified your audience(s), then you can start designing an appropriate UI. If your audience includes both the user and that user’s friends, then you want to enable both audiences to do the things they want to do, without making the interface confusing for either audience.

Platform/Technology
Platform is the third and final attribute for a reason. It should flow naturally from the first two attributes.

For example, let’s say you chose to design the following kind of widget…
Purpose: Perform a function
Audience: Only the user who installs the widget

In that case, you probably want to choose a platform like iGoogle or the PC desktop.

However, if the chose to design a widget more like this…
Purpose: Connect people socially
Audience: The user and her friends

In that case, your widget probably belongs on a platform like Facebook.

Since there are so many platforms, and their pros and cons aren’t well known, I’ll provide a brief overview of the most popular options here.

• Yahoo Widgets
  This is a framework that users download and install on their PC. The framework is for both Mac and PC, which is good, but it does require a separate installation process. So I tend to think this platform is only for people who really want widgets — not for average users.
• Google Gadgets
  Google Gadgets are a lot like Yahoo Widgets, except they can work in more places. A Google Gadget can be placed on a user’s iGoogle page, it can be installed as a PC desktop widget using Google Desktop (which is just as distracting as installing Yahoo Widgets). And I understand a Google Gadget can even be installed on any regular web page.
• Facebook
  Facebook is probably the most popular social network for widgets (Facebook calls them “applications”). Since so many people are already using Facebook, it’s almost ideal for any widget that needs to be social. The downside is that Facebook has been overrun by applications, so the managers are taking steps to minimize the role the applications play. Also, Facebook applications are often written in a proprietary language, making them more difficult to port to other platforms.
• OpenSocial
  Just about every social network that isn’t Facebook uses a Google technology called OpenSocial to power its applications. That includes MySpace, LinkedIn, Ning, and dozens of others. Although I haven’t seen many OpenSocial applications yet, it’s a good bet that they’ll become more popular in the future.
• Blog badges
  Most blogs give their owners a place to add “badges”, usually along the left or right hand side of the page. These badges are typically just a snippet of HTML and an image, offering minimal interactivity.
• PC Desktop
  Some PC widgets are actually just specialized applications. A common example is WeatherBug for the PC. It gets installed like any other PC application; it just has a small window and it hides in the Start bar when not in use. Alternately, you could develop a cross-platform desktop widget by compiling a Flash application, or transforming your Flash program into an Adobe AIR application, or by writing your application in any other platform-agnostic language.
• Mac OS X Dashboard
  The Mac operating system comes with a tool called Dashboard that overlays a set of widgets whenever the user presses a special key. Dashboard widgets are generally very popular with Mac users, but it does require you to build a widget just for the Mac platform.
• Vista Sidebar
  In Windows Vista, a tool called Sidebar provides a “dock” for widgets on the side of the screen. It’s actually very similar to Yahoo! Widgets, except it’s built into the operating system. However, Vista Sidebar has the same drawback as Dashboard: it only works for a single operating system.
• iPhone
  The Apple iPhone now allows developers to write 3rd party applications for the phone. Because the screen is small, these applications look like widgets, so they’ve been wrapped in under that term too.

This is not a complete list of widget platforms, it’s just the most popular options. All the same, it’s more than enough options. The good news is that many of these platforms use the same basic technologies (HTML, CSS, Javascript, Flash, etc.), so it’s usually not that hard to rebuild a widget so it works on multiple platforms. Once you’ve picked a platform (or a few platforms) that make sense for your purpose and audience, you need to talk with your developers to figure out which ones you can reasonably support within your budget and schedule.

So what do you think of this framework? So far it has made sense for my projects, but I’d love to hear some other opinions. How are you thinking about the widgets you’re designing?

Recently, the IxDA list has been discussing a couple of commercials that Ford is running. One of them is readily available on their website:

Go to the Ford “Drive One” website. Scroll down to the bottom, it’s the last video on the page.

The other video doesn’t seem to be online, but I happened to record it along with Lost last week. So I’ve uploaded it for anyone who hasn’t already seen the commercial.

Ford Focus UI Designer

Has anyone actually used one of these new systems? I’m curious to hear some real world feedback on how good or bad it actually is. At a glance, parts of it look kind of chunky and even a little ugly. But I could see how people might need big, chunky buttons while they’re driving.

In any case, major props to Jason Johnson for being one of the first UI designers to be featured in a commercial!

During today’s Design and Architecture of Social Web Experiences workshop, I took 5 pages of notes and designed a very simple, yet very cool social website. So, yeah, I’d say it was a good session.

Here are some of the highlights from my perspective…

The Webb/Butterfield/Smith Model

This is an illustration that shows 7 aspects of social networks in a way that makes it easy to describe the functionality of a social web site.

Open design patterns

Trust and monitor

The problem of the Cold Start

Group size

I arrived in Miami, FL late last night for the IA Summit, and right now I’m sitting in the first all-day pre-conference session called “Design and Architecture of Social Web Experiences“.

So far, this session has provided a grounding in what social networks are, and we’ve had our first “workshop” of the day. Everyone has been assigned a different website to consider how social experiences might be integrated. My group is considering how to design a social web experience for a non profit that helps children with cancer. First step: figure out the business goals, user goals, and overall strategy.

Most of all, I’ve really enjoyed meeting the people here. Really smart people. And people who understand what I do! What a rare thing.

I’ll update later with more thoughts from the session.

Michelle recently pointed me to a blog entry where Paul Fresty of Optiem explains why he hates wireframes. And I can’t say I blame him. Apparently, at his company, the Account and Project Management teams create wireframes on their own and hand them off to designers. The wireframes may even be shown to clients before the designers have had any input. So I really have to agree with Paul — that sounds awful.

But I also have to speak up in defense of wireframes when they’re done correctly. We’ve been wrangling with this at Bridge, and I think we’re reaching a point where everyone’s starting to feel comfortable. Let me hit on a few of the things we’re doing differently:

1. Wireframes are created by Experience Planners, not Account or Project Management.
   When we create wireframes, we don’t just capture the priorities of communication, and we don’t just put things on a page to suit our whims. Creating wireframes is a process that involves careful weighting of the priorities of communication, consideration of user needs and goals, usability best practices, and our instincts as web professionals. I would also argue that Experience Planners are well qualified to make wireframes because of our knowledge of the site’s content. In our company’s process, wireframes come after the site map, so we can tie the general callouts on the home page to specific pages within the site.
2. Wireframes are created in collaboration with Creative.
   Experience Planners lead wireframe creation, but we work with Creative throughout, even before the first line goes down in Visio. In an ideal project, I’ll sit down with the Design and Copy Directors before I make wireframes to review the brief and get their thoughts on the project.
   Do we need to explore a non-traditional site layout?
   Is there a Big Idea that ties the site together?
   Are there any key points that we need to hit in the copy?
   Then I’ll put together a wireframe that makes sense based on our discussion, and review it internally.   

   Only after everyone feels comfortable, we’ll take the wireframe to the client and explain how they should understand what they’re seeing. Yes, it suggests layout, but it’s not the final layout. We’ve tried to set up the page so it reflects the priorities of communication and the user’s needs. When the designer’s get to it, we may decide to make some changes, but only if we have good reasons.

3. We believe usability is important enough to get its own step in the process.
   Most really good designers I know create several thumbnail sketches or mockups before presenting a final design. They do this because it’s easier to explore options and make changes to a sketch than a pixel-perfect design concept. At Bridge, we feel the same way about usability. It’s so important that the user experience is right, we take the time to make wireframes before design concepts. We review the wireframes with the client to make sure it meets those objectives and, if there’s time and budget, we take the wireframes to consumers to make sure they’re able use the site the way they expect.      

   We could jump straight into design and figure out where everything goes and how it works while we selecting colors, fonts, images, and tone. But chances are we wouldn’t give user needs enough consideration in that process.

All that said, I do agree with what Paul said about wireframes at his company. For his situation, Page Description Documents make a ton of sense. (Good explanation and examples of PDDs in Dan Brown’s Communicating Design.) I just think proper wireframes would be even better.

I’m curious about other agencies’ experiences with wireframes. Have you had similar difficulties? Did you end up ditching wireframes entirely, or did you work out some kind of compromise?

This blog is the work of the Experience Planning team at Bridge Worldwide. We’re using this blog as a forum to share our thoughts, experiences, and questions about the practice of user experience planning.

To celebrate our new blog, we’ve created a t-shirt that we think suits our profession really well. How many times per week should you wear it? It depends.

Check back with us soon. Tomorrow is opening day for the Reds and for us.