’s Saved Items Shaun Inman’s Fever VIDEO: I gave a talk on "UI Fundamentals for Programmers

I gave a talk on “UI Fundamentals for Programmers” at WindyCityRails in Chicago last month. The talks covered modeling, breaking apps into screens, visual techniques, flows, and a few coding tips.

WindyCityRails was an excellent conference with top-notch organization and really friendly people. I highly recommend visiting Chicago and attending next year. Thanks to Ray and the folks at WindyCityRails for having me.

]> Tue, 29 Sep 2009 22:14:00 GMT
A quick lesson on how not to design your calls to action Bryan and Jeffrey Eisenberg pack a lot of theory about the psychology of persuasion into the concept of a “call-to-action”, but at its simplest, a call-to-action is the area on a page that sums up its main purpose or goal - i.e. the bit that the designer wants the user to read and click on. A good call-to-action is one that’s rapidly noticed and easily comprehended. A bad one… Well, just take a look below. It’s rare to find a site that makes the same fundamental mistake over and over again like this.


Above is a screengrab from, the site for the new Acropolis museum in Athens. It opened this year, and it’s turned out to be a very popular tourist attraction. With that in mind, it makes sense to book your tickets in advance. It’s not too hard to find this page (Hours & Ticketing), but the next step is to enter the ticket booking process. So, how do you do that? It’s almost like they’ve hidden the “Buy Tickets” call-to-action on purpose, as a nondescript link right at the bottom of the page. This is the online equivalent of designing a supermarket with the tills hidden in the stockroom - hardly the definition of good business sense.


Having clicked ‘Buy Tickets’, the user ends up here (above), which seems to be the first page of the booking process. The only thing we can see here is a text field. Where’s the rest of the stuff? Where’s the ‘next’ button? Where’s the steps-left indicator? It almost looks broken - as if the page hasn’t loaded properly. In fact, to proceed to the next step the user needs to enter a number into the text field, and then the next chunk of the form will suddenly be revealed. You can almost picture the user muttering to themselves - “Why on earth does this site have to work differently to the rest of the web?”

Having entered the number of tickets, this calendar widget appears (above). Today’s date is currently selected. What are you expected to do now? Once again, there is no clear call-to-action. In fact, you have to click any date in the future and it will reveal which times are available.

Phew! If the user’s got this far, they are probably getting the hang of this unconventional UI. They need to click on their desired timeslot to proceed, then they need to fill in their address, payment details and finally they reach a confirmation page, shown below.


Here’s the confirmation page. The user will expect this to be emailed to them - that’s normal practice, right? Not on this site. If they don’t save or print this page, they are going to have real trouble getting into the museum. This key instruction is written half-way down the page, but once again the designers have made the same mistake of providing a weak, easily missable call-to-action.

To sum up, I’m hoping that this example has given you a reminder about the crucial importance of strong calls-to-action. It’s obvious stuff really, but we all make schoolboy errors from time to time.

]> Tue, 29 Sep 2009 18:23:27 GMT
Integrating Prototyping Into Your Design Process Just like with any other UX research or design tool, context plays a critical role in determining how effective prototyping will be for you.

Prototyping is a big deal right now. We get wrapped up in mailing list threads, new tools are released at an astonishing pace, books are being published, and articles show up on Boxes & Arrows. Clients are even asking for prototypes. But here’s the thing… prototyping is not a silver bullet.

There is no one right way to do it.

However, prototyping is a high silver content bullet. When aimed well, a prototype can answer design questions and communicate design ideas. In this article, I talk about the dimensions of prototype fidelity and how you can use them to choose the most effective prototyping method for the questions you need answered.

The dimensions of fidelity

A prototype’s fidelity has the most influence over its effectiveness. Fidelity simply refers to how realistic the prototype is. Most of the time when we talk about a “high-fidelity” prototype we are referring to a prototype that has some visual or industrial design applied to it. But that leaves out what’s most important to UX designers, what it’s like to actually work with the prototype!

Fidelity is multidimensional.

Not only can you have a prototype that looks like a realistic product, but you can also have a prototype that works like a realistic product. I call these dimensions of fidelity “visual fidelity” and “functional fidelity.” By varying your prototyping methodology along these two dimensions you can ensure that your prototyping effort is successful given your particular context. Let’s take a look at some examples.

version w/ arrows

A prototype can be as simple as a series of hand-sketched wireframes that flow together. This is a good example of a low visual fidelity prototype. These wireframes show layout and functionality but have no visual design. Take the same wireframes, integrate a visual design, and your prototype has a high visual fidelity. While you might think of them as being similar, these two prototypes are most effective in two different situations.

That same series of sketches is also a low functional fidelity prototype. Moving through screens drawn on paper is much different than working with the developed system. But if you render those sketches in HTML, JavaScript, & CSS, they have a high functional fidelity. Working with an interactive prototype is very similar to working with the developed system. Again, high- and low-fidelity prototypes are most effective in two completely different situations.

After spending all this time talking about fidelity, I want to share one of my favorite quotes on prototyping. Bill Buxton said this in his Interaction08 keynote:

There is no such thing as high or low fidelity, only appropriate fidelity.

Appropriate Fidelity

“Appropriate fidelity” refers to a level of prototype fidelity that allows you to achieve the goals you’ve set for doing a prototype in the first place. By varying the fidelity of your prototype along the dimensions of visual design and functionality, you make your prototype more effective at achieving some goals and less effective for others.

bottom left Low Visual and Low Functional Fidelity

Very low fidelity prototypes are extremely useful to UX designers. Why? They can be made swiftly, changed without repercussion, and still help visualize a concept. Low visual & functional fidelity prototypes are helpful at answering large structural questions. Here are some examples:

  • Does the system have all the features required to support the user’s goals?
  • Does the workflow make sense at a high level?
  • Which UX concept works best?
  • Coming to consensus on a UX concept with stakeholders, e.g.”Is this what you meant?”

bottom right Low Visual and High Functional Fidelity

In my own practice, this is the type of prototyping I do most often. What I make are interactive, HTML interactive wireframes in HTML. Everything is black, white, and gray, but the interactions are extremely close to what they’d be in the developed system. These types of prototypes are effective in many situations:

  • Evaluating the usability of proposed designs for new systems
  • Exploring isolated interactions as a proof-of-concept
  • Validating UX design direction with stakeholders
  • Validating the implementation of requirements with stakeholders
  • Supplementing printed documentation for development teams
  • Performing remote testing

Remote testing has become more and more important over the last several years. At Evantage, we do approximately 75% of our user testing remotely. It would be difficult for us to get good data about our designs for modern, highly interactive sites if we were limited to representing those designs using low-to-medium functional fidelity prototyping techniques such as clickable PDFs or interactive PowerPoint presentations.

By prototyping isolated interactions at a high functional fidelity and testing them with users, I can get really good data about whether that interaction works before I base an application around it…. If those ideas are actually pretty slick, I can release the design with confidence instead of with gritted teeth.

I also want to expand on proof-of-concept testing. This technique supports creativity and innovation. By prototyping isolated interactions at a high functional fidelity and testing them with users, I can get really good data about whether that interaction works before I base an entire application around it. This allows me to explore my crazy ideas and find out if they are, in fact, crazy. But if it turns out that those ideas are actually pretty slick, I’ll know that and can release the design with confidence instead of with gritted teeth.

top left High Visual and Low Functional Fidelity

At first thought, these prototypes may not make much sense. Why bother making something look nice if it doesn’t work? Well, because how something looks can have a huge impact on how easy it is to use. A high visual and low functional fidelity prototype allows you to test that with users. You can print out screen images and do a paper prototype test with them, or you can image map some JPGs and do what I’ve heard termed a “slap and map” test from within a browser.

top right High Visual and High Functional Fidelity

High visual and functional fidelity prototypes are the Rolls-Royce of prototypes. They take more time and effort to build than a lower fidelity prototype and are correspondingly more complicated to manage. Most of the time, this extra cost isn’t worth it. But there are a few situations where it is:

  • Evaluating the usability of proposed UX designs for an existing system
  • Performing usability tests with non-savvy user groups
  • Supplementing printed documentation for offshore development teams

Prototype testing is all about data, right? In the first two situations above, the prototype’s high visual fidelity reduces the confounding factors a wireframey prototype can introduce into test results, thus maintaining the quality of your data. In the third situation, the high visual fidelity helps minimize the design communication and interpretation problems inherent in offshore development.

Integrating Prototyping Into Your Design Process

What I’ve talked about so far has focused on the tactical, on how to prototype effectively to achieve specific goals. What I want to talk about now is more strategic. How can you integrate prototyping effectively into your design process?

First off, do what you’d do to begin any organizational change. Start small. Find a small project, express the value of prototyping and your interest in doing it, and do it. It would be best to start with something richly interactive though, as prototyping is more crucial the more interactive a system is. Of course, make sure you use a prototype of the right visual and functional fidelity for your purpose.

People like shiny things that move. The cool factor of prototyping will be difficult to resist.

As you near completion of the prototype, make sure you walk through the prototype with the project’s stakeholders. Ask them if something like this was what they had in mind. This will impress them on two levels. First, people like to feel important, and you’re soliciting their opinions. Second, people like shiny things that move. The cool factor of prototyping will be difficult to resist. When these stakeholders are involved in future projects, it’s very likely they will actually request a prototype as a result of their first experience with you.

Once you get buy-in, you can start integrating prototyping into your process. But just like different methods of prototyping are more effective for answering certain questions, different business contexts call for different ways to integrate prototyping.

Corporate, Agile, Mature UX Practice

This situation is fast-paced and iterative, but as an employee (as opposed to a contractor or consultant) you have the opportunity to own the UX of your company’s products. In this situation, there are three points in the design process that prototyping can be of benefit.

  • Low visual and functional fidelity prototypes can help select good UX concepts from several that you develop at the beginning of a project.
  • High functional fidelity proof-of-concept prototypes can help develop those concepts into usable designs.

You can work with a dedicated prototyper to build a separate prototype using code that can be reused in the production system can build efficiencies into an Agile process.

Corporate, Waterfall, New UX Practice

In this situation, the organization might not be comfortable enough with UX design to support the development of multiple UX concepts. You might just have to begin developing the wireframes and prototypes to meet the organization’s need for documentation and measurable signs of progress. This situation relies heavily on the prototype for communicating and validating direction with project stakeholders, with user testing often not yet being a real possibility. Here’s how prototyping can help:

  • High functional fidelity prototypes can help you communicate better with stakeholders and get their input on your direction
  • These prototypes should also be used for user testing, if at all possible.
  • Walk through the interactive prototype at the same time you walk through the printed documentation for the developers during handoff.


When doing UX design for an external client, a lot of the magic is worked behind the scenes. The result is a process that is relatively unencumbered by internal politics. The challenge is to convey the importance of iterative prototyping to clients who sometimes feel like they’re paying for the same thing twice.

  • Sketch two or three of your design concepts into simple, low visual and functional fidelity prototypes and test them to decide which to go with. At this stage, testing can be very informal and done with anyone capable of putting themselves in the user’s shoes (e.g., other UX designers, customer service staff, or product managers who used to be users).
  • Build a small interactive prototype that shows the critical interactions, walk through it with stakeholders to validate your direction, then test with users.
  • Revise the prototype based on the test results, flesh it out to support more holistic tasks, and test again.
  • Revise the prototype and use it to supplement the paper documentation as you walk through both with the development team.

Just like with any other UX research or design tool, context plays a critical role in determining how effective prototyping will be for you. If you follow the simple guidelines above and prototype to an appropriate level of fidelity for your context, you will achieve your goals and improve your design. No firearms required.

]> Tue, 22 Sep 2009 22:50:01 GMT
CAPTCHA’s: Tough on Sales & Common Way to Test User Tolerance When someone visits a website, they typically have a goal in mind, and a certain expectation that they plan to achieve. User tolerance isn’t infinite however: aggrevate a viewer too much, and they will give up their goals eventually.

CAPTCHAs can test user tolerance

Strangely enough, we’ve invented a standard that’s been proven to do just that. CAPTCHA (or Completely Automated Public Turing test to Tell Computers and Humans Apart) is a method that we employ on websites to verify that a user is a human instead of, say, spam bots or some other malicious software pretending to be human. CAPTCHA’s are frequently used in user registrations, comment submission forms, and many other interactive online interfaces.

It’s absolutely clear that CAPTCHA’s reduce spam, but at what cost?

CAPTCHA’s Can Harm Business

How often will a user give up in a situation when presented with CAPTCHA? A recent case study from SEOmoz suggests that nearly 3.2% of all conversions were losts over a 3 month period on 50 websites when CAPTCHA is used to verify one is human. Other studies have reported similar potential losses in sales, some as high as 10% in failed conversions.

No one likes SPAM, but is the cost of lost sales worth deferring potential customers?

CAPTCHA’s deter user interaction

Another cost of CAPTCHA is that it may defer users from interacting whatsoever. Just like a reader may turn down reading a lengthy post on a blog based on it’s perceived size, a user may decide not to fill out a form where a CAPTCHA is involved based simply because they see it as taking extra time.

Even the users who decide to use the CAPTCHA won’t stick around long if they fail the test 2 or 3 times. For Users, CAPTCHA does not fit into their set of expected tasks when they’re attempting to accomplish their goals online. It’s just another barrier between them and what they want to happen. In short, a CAPTCHA slows users down, and provides less satisfaction than the alternative.

CAPTCHA’s Aren’t Accessible to People with Certain Disabilities

The average CAPTCHA is a string of warped/distorted text as an image. This distortion makes it very hard for a computer to recognize a string of characters, but a human can usually match the text in the image in a submission form. People who are blind or have poor vision however will have no way of knowing what the text is.

Some sites have begun adding audio alternatives for visual CAPTCHA’s, but there is still distortion which can make identifying yourself as human difficult.

Should You Use CAPTCHA?

It’s obvious that CAPTCHA’s are less than ideal, but they remain to be a necessary evil until a better alternative has been proven. For the time being, this question should probably be answered case-by-case.

Before employing a CAPTCHA, consider alternatives and also consider the potential cost of a human verification test. Will a CAPTCHA harm your business? Will it defer more users from interacting with your site? It may be worth doing an A/B Split Test to find out for sure.

What other ways are there to verify if a user is human? Do you know of any alternatives that have proven effective for yourself?

]> Tue, 22 Sep 2009 13:30:42 GMT
Jane Austin & Chris Neale on Sketch Prototypes

The paper prototype is generally used as a design tool and even usability testing tool, but the folks at IG Index have figured out a creative way to use sketches and paper prototypes as a communication tool in place of wireframes for demonstrating interaction to development teams. Martin Belam posted video from UX London 09 of Jane Austin, Chris Neale and Frances Eida discussing this simple method of taking wireframe/storyboard sketches or paper prototypes, and creating stop-motion animation to demonstrate interface. Wonderful stuff. More at Currybet.

]> Mon, 21 Sep 2009 15:41:34 GMT
Pencils, Pens & Markers Sets

This one is for all you interface sketchers. Wireframes Magazine asked designers what their favorite pens, pencils, and markers are for UI sketching, and posted photos of the responses. Click the first photo to view the expanded gallery of tools.

]> Thu, 17 Sep 2009 16:07:41 GMT
Rapid Prototyping Tools Revisited

Dan Harrelson at adaptive path posts his updated list of prototyping tools. You can view the Google Doc directly here.

Via @andrewkorf

]> Thu, 17 Sep 2009 15:49:03 GMT
Help, we’re drowning in wireframing apps! Back in the 1990s, when wireframing was a niche activity, you were pretty much limited to Visio or Illustrator. Nowadays there are a huge number of alternatives. If you want an online app, you can choose from Balsamiq, Just in Mind, Jumpchart, iPlots, iZotz, HotGloo, Connect-A-Sketch, ForeUI, Pidoco, Simulify, Mockup screens, Mocklinr, Wireframe sketcher, Gliffy, Lovely Charts, Project Draw, Creately, Napkee among zillions of others. Offline the situation is equally messy, we’ve got Axure, Omnigraffle, Visio, Sketchflow, iRise, Inkscape, Illustrator, Fireworks, Indesign, Pencil, Denim, Serena, Qmockup, Flairbuilder, Photopro, Caretta Studio, and there’s also reams of GUI builder apps if you’re designing desktop apps. The list just goes on and on. How do you know which ones to use and which to avoid?

Has anyone actually tried them all and created an über comparison table? Not as far as I can tell. Instead I’m sort of hoping for some kind of K-T event to kill of all of the weaker ones. Not sure how that would work, though. Any ideas?

Amendment: post has been repeatedly edited to include additional tools.

]> Wed, 16 Sep 2009 10:50:17 GMT
AxureWorld 2009 Like using Axure as much as I do? Check out the first Axure-centered conference, AxureWorld 2009, on October 10. It’s all online, and completely free.

I’ll be presenting two panels: Variables and Conditional Logic; Raised Events, and Axure Tips and Tricks. There are a bunch of other great panels hosted by Axure ninjas: Fred Beecher, Jeff Harrison, Luke Perman, Mark Johnston, Dhawal Shah, and a Q&A session with the Axure folks themselves.

And a huge thanks to Ezra Schwartz for organizing the whole thing.

]> Tue, 15 Sep 2009 20:42:28 GMT
OmniGraffle Wireframe Stencils, Version 3

Version 3 of the OmniGraffle Wireframe Stencils has been posted. Download it now.

Modified all form and controls elements for color consistency. Added the following: sliders, new form icons, tag clouds and lists, a-z lists, IAB advertising units, iphone chrome, web browser chrome. You'll also see the start of a style guide based on the UI components here, which is being used for the Prototyping Kit we're developing.

]> Tue, 15 Sep 2009 20:06:58 GMT
Design is Messy

I learned this lesson the hard way in an architecture class. For the first assignment, most of the students showed up with intricate, beautiful, and fragile homework assignments. One hardy soul showed up with a pile of cardboard shards, duct taped together hastily into an uneven tree. All five feet of the fiery professor stormed over to this monstrosity, and she began to laugh as she grabbed it by its shredded trunk and waved it around menacingly at the other students.

“THIS is what I want to see!” she bellowed. A nearby student ducked as she swung it. He saved himself from getting decked, but his painstakingly crafted homework caught a branch and fell to the floor in pieces.

“THIS is a prototype! It gets the idea across quickly and sturdily. Do not even THINK about beauty yet!” She swung around again, as if to yell at anyone behind her who had missed her point. This time, the draft alone was enough to knock over another unlucky student’s paper-crafted structure that had obviously taken many nights’ sleep. Unfortunately, that unlucky student was me.

She slammed the tree back on the desk and stomped to the far corner to begin her critiques with a defiant “Explain yourself.”

Ever since, I have laid projects out and built prototypes in front of me early and dirty. I don’t need the perfect shade of ochre to see how everything will come together, and once it happens, it may be cerulean anyway. The early sketches and prototypes over the years have gotten many laughs, both due to their roughness and the little jokes I put in to entertain myself. They are built to get what I need from them. They make sure the design has a solid foundation with no surprises that will sneak up later. When I return to add the polish, I know it will stand up to whatever I throw at it, or whatever I throw it at.

]> Tue, 15 Sep 2009 07:01:06 GMT
Wireframing with incomplete requirements The value of wireframing even with incomplete information

The task of wireframing in application development, as I've come to know it, should begin after user research has been performed, and a complete set of requirements gathered.  But what happens when, for whatever reason, you just don't have access to user research, or a full set of requirements?  What if all you have are some rather unspecific, vague notions of what the user should and should not be able to do?  Is wireframing at this juncture useful?  I say yes.  With incomplete or even almost non existent information about target users and or requirements, wireframes can still be a valuable tool in the interface designers toolkit.

The key to a wireframe's usefulness is that it is a visual document.  Presumably it will be presented to one or more product stakeholders, and they will have the opportunity to review it and comment.  Having something visual to respond to is one of the easiest ways to generate ideas, and identify incomplete specifications.  A good assumption is that if a product's requirements are incomplete, someone at the wireframe review will notice the gap by responding in the context of the visual presentation.  "Where is the Cancel button?  Oh...not in the requirements?  Well it's obvious that on this screen the user will need to be able to cancel, so we have to add that as a requirement."

In this way, a wireframe can be an ever evolving document, which begins by starting the requirements conversation.  Of course ultimately, just prior to feature development, the wireframe should have all of the necessary specifics so that the developers can use it as a guide (along with the relevant user stories).

Pathfinder is a software development firm. Hire us to build complex software that's easy to use.

Wireframing with incomplete requirements

Related posts:

  1. Exactly What are Wireframes?
  2. Writing Agile Requirements
  3. Developing Good Wireframes Ahead of Visual Design

]> Thu, 10 Sep 2009 21:43:16 GMT
Design for Interaction: Ideation and Design Principles
You know what needs to be designed. You’ve listened to your business stakeholders and to your users. You’ve made models of the strategy and of the design research. And now you are staring at a blank piece of paper or screen. You have to, well, design something. This is where ideation has to happen.

This is a chapter from 'Designing for Interaction: Creating Innovative Applications and Devices, 2nd Edition'

This is a chapter from Dan Saffer's book 'Design for Interaction, 2nd edition'

Once you’ve come up with tons of ideas, how do you choose which ones are worth pursuing? You use a set of design principles that will not only help select the best ideas, but guide the design through refinement, prototyping, development, and beyond. But first, let’s diverge and come up with concepts.

Creating Concepts

The purpose of brainstorming is not to find the one perfect design for your project. That will come later. Instead, the reason to ideate is to generate many concepts as rapidly as possible. At this point in the design process, quantity — not quality — is what matters the most. You want a wide variety of concepts that approach the project from a wide variety of angles. Even ideas that seem outlandish and completely unfeasible are welcome.

As an ideal, each brainstorming session, even a short one of an hour, should generate dozens of ideas. For a new product, you should brainstorm over several days to generate hundreds of ideas, concepts, and fragments of ideas. It doesn’t matter if they are variations on an idea, or even if you or others have thought of them before. Just put them down and move on to the next idea.

Ideation - courtesy oCricket

Ideation - courtesy oCricket

What you want to do is get every idea you can possibly come up with out there, on paper as a sketch not in words (although sometimes giving your concept a name is helpful later, as are words to explain a part of the sketch) so that they can be considered later. Be as specific as you can be. No “Fix the thing with a drop down” type notes. Draw the solution you’ve come up with. The quality of the drawing doesn’t matter.

Brainstorming requires some tools. First, because of the limitations of today’s available technology, brainstorming should never be done digitally; it should be done with paper, pencils, pens, markers, and possibly whiteboards and sticky notes. You need to be able to jot down an idea quickly, set it aside, and move on to the next idea. Fumbling with technology just gets in the way. You can capture your ideas with a digital camera later if necessary. For now, analog means pencil and paper work best.

When brainstorming, designers should have all the research and models close at hand and in view (taped to walls perhaps) for reference and inspiration. Also, brainstorming doesn’t have to be limited to the designers on the team. Inviting stakeholders, developers, engineers, and even outsiders can sometimes lead to productive ideas you might not have thought of. Just be sure they understand the “rules” of brainstorming:

  • There are no bad ideas. There is no judgment about anyone else’s ideas.
  • Stay focused. Put stray thoughts or unrelated ideas into a “parking lot”: a physical place in the room where those sorts of wayward ideas can be captured, but not discussed.
  • Don’t spend a lot of time on any one idea. In the initial brainstorming sessions especially, the goal is to generate as many ideas as possible. Save going into depth on any one idea for later. For now, more is, indeed, more.
  • Use the whole room. Post things up on walls. Simply seeing all the ideas may generate connections between them or generate new ideas.
  • No multitasking. You can’t do brainstorming well when you are focused on answering email, IMing, texting, or working on other things. It’s a concentrated activity, so all distractions should be removed as much as possible.

(…) brainstorming should never be done digitally; it should be done with paper, pencils, pens, markers, and possibly whiteboards and sticky notes.

Getting Started

Ideation requires being able to make fast mental leaps and connections, so start with a warm-up exercise to get everyone’s brains working. For instance, first dwell on the subject at hand in the broadest possible sense. For example, on a project to build an installation for a museum, spend 10 minutes doing a word association game on what art is or what a museum is. Or do drawings based on famous artists. Or have all the people in the room talk about their best (or worst) experience at a museum. What the exercise is doesn’t much matter: the point of the warm-up is to get brains, hands, and mouths engaged before starting to generate ideas.

At this point in the design process, no idea is a bad one.

Mind map - courtesy Squallwc

Mind map - courtesy Squallwc

Set aside a fixed amount of time for brainstorming—usually not more than two hours at any given time period. Allow for breaks between sessions. It’s tiring work and without breaks, it quickly becomes frustrating and tedious. It’s also ideal to spread brainstorming over several days. The unconscious will work on the problem while you are sleeping, in the shower, walking, etc. and possibly provide you with concepts and ideas slowly over time.

At this point in the design process, no idea is a bad one. Set aside most of what you know about the technical, user, or business constraints (you’ll add them back in later). Right now, you want to ask yourself the question Alan Cooper challenges interaction designers to ask: How would it work if it was magic? Meaning, if all the constraints were gone and the user could just push a button, what would happen? How would the system accomplish the task? What would the feedback (see Chapter 7) be like?

Structured Brainstorming

Alan Cooper’s “magic” framing is just an example of structured brainstorming. If you’ve ever sat down to do anything creative, you know that one of the hardest things is to begin. Without any structure, it is easy to stall after one or two ideas or simply stare at a blank page.

Some common structures to use in brainstorming sessions are:

  • Pain Points. Hopefully one of the things learned in design research was what part of the process or activity is problematic or difficult. These moments make excellent focus points to brainstorm around.
  • Opportunities. Likewise, if there are known places for innovation, those can be points to begin.
  • Process Moments. If there are known steps in the activity, you can ideate around each of them. Of course, you will eventually have to put the pieces together, but each piece can suggest a greater whole, a framework (see Chapter 7).
  • Personas. Personas generated by design research can also serve as structure by focusing solely on addressing the direct expectations, motivations, and behaviors of one particular persona. Do this for each persona in turn.
  • Metaphors. Human brains work in metaphors. We can harness this natural ability to compare unlike objects to aid brainstorming. Sometimes by using metaphor, you can discover a framework that can wrap around the whole project. What is this product like? What is the product not like? For example, what if you thought of a mobile device as a toy? As a musical instrument? As a cooking utensil? Sometimes, the oddest metaphors will uncover a previously unthought-of direction for the design.

Spend a fixed amount of time (30-60 minutes) on each pain point, opportunity, process moment, etc., then take a break. Then move on to the next session.
There are many other known brainstorming techniques that can help structure your ideation sessions. Here are samples that are especially good for interaction designers:

  • Brainwriting. Each person writes down or sketches the beginning of an idea silently on a piece of paper. This could be as simple as a single word or a shape. After three minutes, the person passes the paper to his neighbor, who continues the idea. This repeats around the circle until it gets all the way back around to its originator.
  • Break the Rules. Rather than ignore the constraints you (hopefully by now) understand, you list them and one-by-one figure out how to break them.
  • Force Fit. Distill the problem down to two words that are in opposition, then put those words together into a phrase. For example, “intense peace.” Ruminate on what exists in the world that embodies that phrase, then try to apply it to the project for inspiration. Nature and art often work well for this.
  • Poetry. Reduce the problem down to a haiku or short poem. Such a small form makes you figure out what is most important.
  • Questioning. Start with a very general concept and keep asking two questions: how and why. For example, “We are going to build a social networking site.” Why? “So record collectors can exchange albums.” How? “By uploading their rare albums.” How? Etc.
  • Laddering. Laddering means either moving “up” to a level of abstraction (“What is this problem an example of?”) or moving “down” to something concrete (“What is an example of this problem?”). Laddering is especially good for getting unstuck.
  • Swiping. Swiping means stealing the best ideas from another field or domain. It starts by abstracting your problem (“This is about finding something small”) and asking what other products or fields have ways of doing the abstraction.
  • Bizarro World. Pretend you wanted to make the opposite product or the opposite outcome. Invert everything: what is good is bad, what is desirable isn’t, etc.

It’s not a bad idea to incentivize idea generation as well. Small rewards or prizes for the most ideas generated, or a group reward once you reach 100 concepts, can do wonders for enthusiasm. To be more egalitarian, give everyone a raffle ticket for each concept generated, then pick a prizewinner at the end of a session.

Organizing Concepts

Once you’ve generated your concepts, it’s a good idea to spend some time organizing them. Just like with data generated via design research, it’s good to cluster, name, and sort all the ideas you’ve created so that it is easy to examine and discuss them.

Give each idea a number, or better yet, a descriptive name, especially for major concepts. Collapse similar concepts together, as there will likely be duplicate ideas.

As a way of comparing concepts, it might make sense to sort them by various criteria. You can put them on a 2×2 matrix (see Chapter 5) to show where each falls on a continuum. You can put them into a spreadsheet, labeled by attribute (“safe,” “powerful,” etc.).

The purpose of organizing concepts is so that when you have your design principles, it is easy to use them as a lens on the ideas you’ve already generated.

Creating Design Principles

Once you have your concepts, how do you determine which ones are worth pursuing? That’s where design principles come in.

Design principles are a set of phrases designed to help guide design decisions throughout the remainder of the design process—and even beyond, after the product launches. They can be thought of almost as design requirements, except they should not be a specific prescription for solving a particular problem; rather, they are general statements that apply across the project. Think of them as a design strategy, the same way there is a business strategy.

Design principles are a set of phrases designed to help guide design decisions throughout the remainder of the design process…

Let’s say, for example, you are designing a new recipe display for kitchens and you’ve noticed people’s hands can get covered in flour or other foodstuffs while cooking—too soiled to be able to operate most controls easily. Thus, one of your design principles might be Operate with Messy Hands. It’s almost a requirement, but it applies across a number of features and suggests the concepts that might work well for the product, such as touchscreens, voice commands, or maybe a gestural interface. Using this principle would also stop you from designing small buttons or using materials that couldn’t be cleaned easily. And it might also cause you to discard many of the concepts you came up with during ideation.

Design principles are a combination of three things:

  • What is known about the users, the context of use, and the design strategy.
  • The best ideas/themes that emerged from ideation sessions.
  • What the designer thinks is necessary for a successful project, based on experience or subject matter expertise.

Using our recipe display example, other design principles might be Help From Across the Room, Allow for Improvisation, and Act Like a Sous Chef.

The best design principles are:

  • Pithy. A short phrase is best. If it needs to be described, you can do that, but make sure it has a short phrase as a lead-in because you want it to be…
  • Memorable. The best design principles can be remembered easily by everyone on the team. Funny, witty, and provocative statements and plays on words work best.
  • Cross-feature. Design principles should be applicable across the product. If you can’t apply it to more than one feature, it’s probably a requirement, not a principle.
  • Specific. Easy to Use is not a design principle. It is too general, and doesn’t give any guidance on making a decision between options while refining (see Chapter 7). Of course it should be easy to use (and intuitive, and delightful, and innovative, and other clichés) but what about this particular product is unique?
  • A differentiator. After you’ve made your design principles, see if they as a whole could be applied to a competitor (if there is one). If they can, then they probably aren’t specific enough (or your product isn’t differentiated enough).
  • Non-conflicting. You want the product to be harmonious, and you don’t want to pit one principle against another, so be careful not to create principles that might be in conflict once applied, such as Never Ask Questions vs. Give The User Total Control.

Once you have your design principles, you can use them as a measuring stick against the concepts you’ve generated to see which ones best fit. Hopefully several ideas will work within the guidelines, or could be tinkered with to fit.

But design principles can also be used from this point in the process forward to help make design decisions. When there are multiple options to choose from (“Should we ask users first, or just do it for them?”), the design principles can sometimes help make the correct decision clear.
Design principles can sometimes outlast the specific product itself, or even be extended across lines of products to give them all a similar grounding.


Brainstorming can be mysterious. Frequently an idea will come to you when you are not in a brainstorming session. Ideas seem to have a life of their own, but they can sometimes be coaxed into existence, and that’s what you hope ideation will do.

The design principles you create are a way—granted, a subjective way—of measuring your ideas for value and feasibility. Of course, the only way to really tell if an idea is a good one is to play with it, test it out, and refine it. That is the topic of the next chapter.

For Further Reading

Photos by oCricket, Squallwc

]> Thu, 10 Sep 2009 19:03:10 GMT
The Sketchiness of Reality One of the most frequent questions I get asked by students and colleagues in the field is “What tools do you use?”. There is always an interesting assumption that software is the key to mind-blowing design, and if they find that latest Adobe beta or esoteric tool by some basement start-up, it will give them the edge they crave over others in the field. They are looking for something to either make their job easier and more efficient, or give their designs some flash and sparkle that will make coworkers gasp and think they are obviously more experienced than they let on.

Sketching tools

My standard response used to be “Pen and paper”, though my time at IDEO has mutated it to “Sharpie and Post-its”. I never touch software until I have thought through several iterations of a design, and I often just present sketches. People are much more likely to chime in on a drawing, and there have been numerous times I’ve had someone suddenly stop themselves after a few minutes of illustrating points by drawing on top of my sketches, thinking they have mutilated a rare artifact, not thinking about the fact that I have been drawing with them the entire time.

Sketchiness provides an invitation for change, regardless of how well you can draw. My artistry is actually rather lacking, especially compared to some of my Industrial Designer colleagues. I’ve found that my drawings only encourage people to jump in and give it a shot themselves once you show that you aren’t afraid to embarrass yourself first because it’s the best way to get across a point.

The roughness of a drawing also helps reduce overall complexity. With software, it’s easy to get caught up in making things look amazing or fall into a rut of using the same tools repeatedly. When you have an empty page in front of you and a marker in your hand, no two things will ever look the same, and you work to convey concepts as simply and directly as possible, or the odds are they will take far longer than expected, while only becoming more ambiguous.

Sketching throughout the process opens up the table to everyone, giving everyone a common voice and an easy way to build on ideas quickly and fluently. Even if you are the worst artist in your company, grab a marker in the next meeting and start sketching out concepts instead of just writing interpretable words. You will be surprised how quickly people understand, and once people warm up to how easy and effective it is, you may have to fight to use the colors you want.

]> Mon, 07 Sep 2009 19:47:23 GMT
SpoolCast: Managing Sites for Top Tasks Guest Gerry McGovern speaks about finding out what tasks your customers want to complete on your site, and how to help them.
Duration: 36m | 19MB
Recorded: August, 2009
Brian Christiansen, UIE Podcast Producer
[ Subscribe to our podcast via Use iTunes to subscribe to UIE's RSS feed. ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]
[ Direct Link to MP3 File ]

One of the most popular speakers in the history of our User Interface Conference is Gerry McGovern. Certainly most of that popularity is thanks to Gerry’s no-nonsense, customer-centric approach to content management strategy. Perhaps a small portion is due to his dulcet Irish brogue. Gerry coined the term “customer care words”, which are distinct words and phrases that visitors are looking for that lead them to success and satisfaction. This is complimentary to a concept we at UIE call “trigger words”, but not quite the same. Trigger words are content-related and navigational–words that help lead you along the path to what you seek. Care words are task-related not content-related; they are the words that visitors need to see to complete the task they are on your site for. These words are not always found in your search logs or in keywords that have led people from Google to your site. But, through polling, testing and observation, care words can be discovered.

Customer care words are both a concept and a eponymous technique that Gerry uses with his clients. When enough participants take part in his processes, his technique both shows top words people are attracted to and, perhaps more importantly, reveals the top tasks the customers are visiting the site to accomplish.

Top task management, quite simply, is what Gerry thinks your site’s whole design should revolve around. Most site owners view their sites as places that house information, but your visitors are on your site to accomplish a task. You should optimize your site, mostly through language, so that it excels in helping visitors accomplish their most common tasks. Traditional site management concentrates on technology, like search engines, and content. But all site projects should ultimately be judged by the satisfaction and success of the users… not by whether your new CMS transition went technically well.

Once the content management system is in place, many organizations write and publish copy without knowing how it will be used. Optimizing your content for top tasks can produce increases in customer satisfaction and task completion. Gerry has seen this with many of his own clients, some of whom were skeptical at first. The biggest objection to optimizing for top tasks is the fear that your customers look to do many things on your site, not just these top tasks. However, if customers have trouble with their common tasks, why would they trust your site to dive into the other ones? In some cases, the top tasks weren’t the most obvious ones to site owners, underlining the importance of both talking to your customers and observing users on your site regularly.

Measuring your customers’ success rate, time-to-completion and their disaster rate–when they think they’ve successfully completed their task, but actually have not–will show you whether or not your changes are beneficial. What’s key is to measure and to revisit these areas until we have them right. Too often, Gerry says, there’s a culture of “launch and leave” with sites: build it and then never revise. Constant, incremental improvement is a better culture to work towards. Gerry has seen seen customer satisfaction rates “sky-rocket” after such changes.

There’s so much more Gerry and I discussed. Please listen to him in his own words on the podcast; your customers will thank you. And if these issues are truly hitting home for you, you won’t want to miss Gerry’s full-day workshop on Mastering Top-task Management for top tasks at our User Interface Conference this November.

How are you ensuring your customers are completing their top tasks successfully on your site? Discuss your methods in the comments below.

]> Fri, 04 Sep 2009 18:53:31 GMT
What You Always Wanted to Know About Eye Tracking - Part 1 ]> Fri, 04 Sep 2009 14:23:31 GMT Creating a Usable Contact Form

Contact forms can fail in many ways. Be sure they do not by following these guidelines.

There are some simple steps you can take to create the best bridge possible between you and your clients. The most obvious way to receive that feedback is through a contact form. It is an essential component for owners of websites. It creates a channel to hear feedback, suggestions, and even sell services.

The Basics

There are several things that a basic contact form should include. Meeting these standards will ensure you are on the right path for creating an excellent contact form.

What to include

Studio 7 Designs‘ contact form is clear and to the point

For the most basic contact form, you will need to include several key components. These almost always include the senders name, a way to get in touch with them, and a message. Also be sure to include a clear submit or send button. Failing to meet these basic needs will insure in a quick failure.

Make sure not to get too lengthy in what you are asking for. Remember that the user is simply contacting you not asking for a quote on their next large project they want to hire you for. If they are requesting a quote it is best to allow contact in two forms, one for simply contacting you and one for quotes. If too much is required a user will abandon ship.

How to structure it

When structuring your contact page it is best to place your fields in a traditional location that leads from who is sending to what they are saying. This can easily be done in two ways. One is to offer a single row of fields to fill out. The other is to create a two column contact page by presenting a few fields on the left (possibly including name and email) and then presenting the message field on the right. Both of these structures are intuitive and easily understood.

Breaking these conventions (Redd has discussed conventions in the past) can often lead to confusion or a failed attempt to contact you. It is also of utmost importance to offer a tab through order that is conducive to your contact form. For example, do not set your form up so that if you tab from one field to what you expect to be the next that it goes to the header of the page.


Clearleft utilizes a two column contact form that is beautiful in every sense.

Submission is Key

Submitting the message in the contact form is yet another seemingly simple part that many people overlook. There are two key components that must be considered when asking the user to send a message to you through a contact form:

The call to action button

Looking back to David Hamill’s discussion on Good Call to Action buttons we can learn much about what we must consider when choosing our “send” button. When choosing what word to use, we must always consider our audience. The two most common choices are ’send’ and ’submit.’ Both of which convey their message clearly. Another option to consider is describing your action more clearly. This could be worded as ‘Send Email.’

Submitted. Now what?

Once an email is submitted, a user expects for a sign showing them that their intended action was successful. If the message sends and no confirmation is offered, then a user may have doubts of whether or not their message will be received. We always want to leave the users feeling confident about their actions.

At UX Booth we show our users a message highlighted in green that reads ‘Thank you - your message has been sent.’ You may also consider including a more detailed message. If you know that you don’t ever answer emails over the weekends that may be something you would like to include, or tell the user that you will work hard to respond within 48 hours.


UX Booth offers a confirmation message to inform users their message has been sent.

Going the Extra Mile

So that covers the basics. That is how you can make an effective contact form, however, maybe you want to go a bit further. I believe the following tips should be done to create the optimal experience.

Fail Gracefully

If a user encounters an error on your contact form,  it creates a barrier between yourself and feedback or even a sale. When a user encounters an error be sure to offer useful feedback. An example of what to avoid could be “Error 4055″. What does that mean? How is that going to help the user correct his or her problem?

Offer helpful hints along the form to help guide users while they are attempting to get contact in contact with you. One of the easiest ways to accomplish this is through jQuery. Be sure to visit Web Resource Depot’s ‘16 Free Ajax Contact Forms‘ for some excellent examples.

One particularly interesting jQuery option is one that is truly geared towards usability. Comments are often presented to a user in the respective fields, but when the user clicks it, the text disappears and becomes lost. Now there is a way to keep the tip in the field when clicked. Be sure to check it out and consider it on your next design: In-Field Labels: A Better Way + jQuery Plugin.

Offer an Alternative to the Form

FireHost offers many forms of contact along side their contact form.

One of the best ways to avoid a total loss of communication is to also offer an alternative to the contact form.

Depending on your audience you may notice you receive fewer emails and more phone calls if the chance is offered. This is a common difference in generational use of the internet. David Hamill (yet again) saves the day by writing about the basics of providing contact details. In this article he discusses many different ways to include information that should not be left out.


Your contact page is often the only way for clients, readers, and users to reach you. Make it as easy and pleasurable as possible for them. In many circumstances it can be the make or break point in terms of a sale or networking opportunity. By incorporating a  few of these simple guidelines, you can increase the chance of that user getting through to you.

What contact form blunders do you hate? How have you made your contact form easier to use?

]> Tue, 01 Sep 2009 13:00:48 GMT
Back to Basics with Interaction Design As an interactive designer, it is easy to get carried away. Part of being a good designer is knowing how and when to use the techniques at your disposal. While there are tons of great tips on how to do certain things on the web, these few tips aim to help designers of any experience level avoid problematic situations by getting back to the basics.

Don't Forget That Your Users are Human

One of the most important aspects of a website is its usability. Don't forget your audience is human. When you forget this you don't communicate your message effectively.

A great example of this principle applied is found in form design. Ryan Singer outlined 10 ways to make forms better, one of which being the language that you use when a error occurs. We've all had it happen, you forget to fill out one of the questions on a form and when you submit it you get a nasty error screen that makes you feel like you've done something illegal.

Error: Not all of the fields were completed! Self-destructing in 5...4...3...2...

You have to consider that many people aren't as comfortable online as you and I. Errors that aren't friendly and informative are scary to users.

A Better Approach

Remember to be conversational in your errors/notifications. So what if they messed up a little bit? Gently let them know they skipped a field and move on.

It looks like you forgot to tell us your first name.

This allows for a better user experience that communicates to your users what you'd like them to do, not to mention it treats them with a little respect.

Don't Jump Straight Into Photoshop

So, you're excited about a new project and you start out by opening up a crisp white canvas in Photoshop. You've launched yourself into a huge ocean of tools without a good idea where to begin. By doing this you can end up with a design that is not very well informed and it makes it very difficult to create a successful web experience.

A Better Approach

Resist the temptation! At a minimum you should always map out the goals for each design and start by simply sketching out ideas.

Sketching is an efficient and effective way to explore concepts because you don't have to focus on typography or making everything pixel perfect. Photoshop is great for executing a design, but not so great for exploring broad ideas.

Design Sites That are Both Necessary and Useful

One of the highest priorities of any project should be to make it usable. If people can't use your site then what good is it? Many designers lose perspective of big picture goals and focus instead on just making something that looks good. Designing with no purpose in mind makes it hard to know where your going.

A Better Approach

Believe it or not the Shakers came up with a design philosophy that can be perfectly applied to design on the web.

"Don’t make something unless it is both necessary and useful; but if it is both necessary and useful, don’t hesitate to make it beautiful."

The Shaker Design Philosophy

The most beautiful site in the world can also be the most useless. As with all forms of design, the best work has a foundation of usefulness.

Got it. Now What?

These tips may seem like common sense, but unfortunately, many people don't consider them in their day to day web work. If you're just starting out, these tips can take some designers years to pick up so learn them now.

If you've been an interaction designer for a while, try to examine your daily routine to see if you can apply these tips. You may be surprised at where you've neglected the basics.

]> Mon, 31 Aug 2009 20:20:00 GMT
SpoolCast: Getting to Good Design Faster Guest Leah Buley speaks about getting to good design earlier in your process.
Duration: 40m | 21MB
Recorded: August, 2009
Brian Christiansen, UIE Podcast Producer
[ Subscribe to our podcast via Use iTunes to subscribe to UIE's RSS feed. ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]
[ Direct Link to MP3 File ]

I had the pleasure of chatting with Leah Buley recently, in advance of her appearance at our User Interface Conference. She’ll be speaking about getting to a Good Design Faster with new techniques to getting at your creative ideas. She’s done some wonderful research on early-project design stages that you really need to hear. There’s a ton of great content in this podcast, and I can only share so much with you here, so please tune in for more of her insights.

When Leah told me that wireframes are really holding back the design process, she grabbed my attention. Designers sit down with some rough ideas and start trying to fit them into one or two pages. Next they start sliding design elements around until things feel good, and then they show it to someone for feedback. That someone or group then sees a design that’s pretty far along, and looks pretty concrete. If some of the ideas in the wireframe are not developed as much as they should be, it’s difficult to stop the forward momentum and reassess.

How can we explore a range of solutions before diving into a single solution? Wireframes are very useful to the process, but instead, we should consider delaying them. Before wireframes, Leah suggests a very open, cross-team exploratory stage. Invite people from across your organization and even collaborate with those who might not normally be within the core design group.

Leah suggests a week-long ‘design sprint’ that begins with a group brainstorming meeting in the morning with lots of people… and everyone’s opinions count. Then that afternoon, the group sketches out a large number of low-fidelity sketches further exploring the experience they’re looking to design, based on the morning’s activities. Sketching many iterations based on different perspectives like, ‘how would we optimize this for a first-time user?’ ‘how about for a power-user?’ ‘how about for this demographic?’

Then the week-long process continues. Grouping the different approaches together, sort the best from the bunch, mixing and matching the best ideas and build upon them (Leah calls this ’sketch-boarding’). Next, take the sketches and flows with the most potential, and make those the first round of wireframes, which you present to a group critique. At the end of the week, take the feedback from the group critique to improve the wireframes.

The end result is a wireframe that has a tremendous amount of collaborative thought behind it. Instead of surprising many stakeholders at this point, their good ideas are already baked inside. You can now share these fire-tested ideas with the next groups that need to see them. This is clearly different from the way many groups and designers are using wireframes today, and I think it’s a really powerful proposition.

Leah and I also talked about ways to become an effective sketcher, how to run productive group critique sessions and much more. You really need to listen in, this could really help your teams process. After our conversation, I’m even more excited to see her full-day workshop on this topic this November at UI14 in Boston. I hope to see you there, as well.

Till then, what are your experiences with the early rounds of design? What are you doing in advance of your wireframing? Can you see implementing this process in your organization? Let us know in the comments!

]> Fri, 28 Aug 2009 14:52:48 GMT
UI Design Guiding Principles Just as my team and I began working on establishing a set of core guiding principles, I came across a post from John Schrag and his team at Autodesk describing their core design values. Based on their list and our own brainstorming, we have developed our own list of UI Design Guiding Principles:

  1. Understand the problem before solving it (and avoid “design on the spot”)
  2. Sketch before making it pretty (and discuss abstractions versus specifics — “selection” vs. “combo-box”)
  3. Validate designs before investing in (production) code
  4. Well designed key features & workflows over quantity
  5. Ease of use over ease of coding
  6. Validated designs over expert opinion
  7. Don’t make things “consistently” wrong
  8. Don’t let users shoot themselves in the foot
  9. Context is important (Where am I? How did I get here? Where can I go next? What is my current state?)
  10. Whitespace is good (… the more you add, the more you detract from what is there. … every element added to a page detracts from the rest. (Paul Boag)

This is a living list - I expect to tweak it over time, adding, deleting, editing…

Related posts:

  1. Design Guiding Principles
  2. 6 Metrics for Managing UI Design
  3. Design Process at Facebook

]> Tue, 21 Jul 2009 15:32:39 GMT