The recent release of Windows 7 got me thinking about development cycles. For those of us who suffered through the last 2+ years of Vista, Windows 7 has been a welcome relief from the lagging, bugs, and constant hassle of a failed operating system. Overall, as a customer, I’m pretty happy with Windows 7. But, at least on my part, there is still some latent anger – if Windows 7 hadn’t been quite as good as it seems to be, they would have lost me to Apple. They still might.
A big part of my unhappiness is the fact that I had to wait for more than two years before they fixed my problems. That’s a lot of crashes and frustration to forget about.
One approach that many software companies have been adopting to combat the huge lag time built into traditional software releases is something called continuous deployment. This sort of deployment means that, instead of having large, planned releases that go through a strict process and may take months or years, engineers release new code directly to users constantly, sometimes multiple times a day. A “release” could include almost anything: a whole new feature, a bug fix, or a text change on the landing page.
I worked with a software development organization that practiced continuous deployment on a very large, complicated code base, and I can definitely say, the engineers loved it. From the point of view of the employees, continuous deployment was a giant win.
But how was it for the users? The fact is, some decisions that seem like they only affect engineering (or marketing, business, PR, etc.) can actually have a huge impact on end users. So, whenever organizations make decisions, they should always be asking, “how might this affect my customers, and how can I make it work best for them?”
Is Continuous Deployment Good For Users?
As with so many decisions, the answer is yes and no. Continuous deployment has some natural pros and cons for the customer experience, but knowing about them can help you fix the cons and benefit even more from the pros.
Big Customer Wins
Fast Bug Fixes
Perhaps the biggest win for users is that bugs can get addressed immediately. Currently, even Microsoft releases patches for some of its worst security holes, but there is certainly a class of non-critical, but still important bugs that have to wait until the next major release to get addressed. That means weeks, months, or even years of your users dealing with something broken, even if the fix is simple. In continuous deployment, a fix can be shipped as soon as it’s done.
Fast Things vs. Slow Things
Similar to the first point, continuous deployment lets you get everything, not just bug fixes, to users as soon as they’re ready to go. Small features, easy changes, and UI tweaks don’t have to wait for larger, unrelated features to be released to customers. After all, should a new design for the splash screen really have to wait on the implementation of a whole new payment system?
More Opportunities for Community Involvement
If you’re having a constant dialog with your customers (you are, right?), they’re probably making some pretty good suggestions about problems they’re having or ways to improve the product. A by-product of the first two benefits is that those users are going to feel even more involved in the development process when their suggestions or concerns are dealt with quickly, rather than if they have to wait months or even years for the next major release.
(Mostly) Avoidable Customer Problems
As with anything, continuous deployment can also cause some problems for users. Of course, some of these problems can exist in big, staged deployments as well, but these are a few things in particular to watch for.
Constant Change
Imagine if every day, the layout on your car changed, sometimes slightly, other times drastically. You want to drive to the store, but the steering wheel is on the other side and you’ve suddenly got an extra pedal. It would make it a lot harder to get where you were going, wouldn’t it?
Well, presumably your users are using your product to get something done, and they’ve got a certain way that they’ve learned to do it. Continuous deployment can mean that the interface for your product can change at any moment, even several times a day. If features constantly appear and disappear, it can be very disruptive to your users’ process.
There are a few things you can do to minimize the disruption. First, make sure that you’re testing your biggest changes on small cohorts of people. Iterate on a subset of your user base, rather than hitting every single user with every single change. This will limit the change that any individual sees while still giving you the benefit of constantly pushing code to customers. In fact, use this as an opportunity to do the A/B testing you should be doing anyway.
Also, and this should be obvious, try to limit your truly disruptive user interface changes so that things don’t feel like they’re in constant flux. You can still change things, but be aware of how frequently you’re making major changes and stay in contact with your users to make sure they’re not feeling dizzy.
Inconsistent UIs
When a big new release is planned, often there is a comprehensive design phase where all the new changes are mapped out and discussed. This means that any inconsistencies in the UI can be found and addressed.
In continuous deployment, different pieces of the product are getting built and shipped to customers all the time, and there is rarely a time when the entire UI is reevaluated as a single entity. This means that sometimes UI standards can tend to…oh, let’s say evolve.
This problem can be controlled by having a UX team member embedded in the development team and constantly working with the engineers to enforce standards before things ship to customers. It can also be improved by providing wireframes, visual designs, and tools like templates to developers so that the look and feel of the product doesn’t shift too dramatically over time.
Avoiding QA
I’m certainly not claiming that every single thing in a traditional release process gets a full QA pass, but I do find that continuous deployment makes it easier for code to slip out to users without any human testing at all. Any time you give engineers the ability to ship code directly into production, you’re tempting fate. Somebody’s going to say, “oh, it’s just a tiny change,” and it’s going to get out without any testing. I’m not naming any names, but you only have to have a tiny change break the entire product once before you realize that there’s no such thing as a tiny change.
Also, continuous deployment can make certain types of testing much less likely to happen. While large release cycles tend to have a code freeze and weeks or months devoted to testing, hopefully including regression, unit tests, and end to end testing, continuous deployment doesn’t necessarily have that baked into the process.
You can always add periodic end to end testing of the product to your own process, of course, and it can be quite helpful in improving code quality, especially when your engineers occasionally slip through a “tiny change.”
Communication Issues
When you’re constantly releasing new features and bug fixes, communication with your users can be a challenge. You don’t have one big release with new help docs, a big roll out plan, and an advertising campaign. Instead, stuff is coming out all the time, and users can get overwhelmed by keeping up with the changes.
Context sensitive help and inline information for each feature can help users get quickly oriented. Also, clearly marking new features as alpha or beta can let users know when a feature is still being developed so they can set their expectations accordingly.
Documentation can also easily get out of date when things are getting released constantly. Big, staged development cycles often have a built-in time for creating documents. Typically, manuals or help documentation and FAQs go through QA sometime after code freeze and before release. But since you’re not necessarily doing a big, monolithic release with continuous deployment, you can end up with this material never getting any sort of end to end editing to make sure they stay current. Make time for this. It’s good for both your customer experience and your customer support team.
Frequent Downloads and Updates
While continuous deployment is quite natural with web applications, even downloaded products can be constantly updated. However, you should always be aware of the burden you’re placing on your user base. If you’re forcing people to download a large file and go through an installation process too often, you’re going to annoy people. As a personal example, iTunes appears to have a new version every week, and I’ve started to flinch every time I open it.
There are a few things you can do to make downloads easier on your users. First, you can ask the user to allow the update to download in the background and install automatically the next time the product opens. This means that the updating happens with very little user annoyance. Also, it’s best to keep the update quick by making the downloads incremental. For example, your virus protection software probably updates its virus information daily without asking you to reinstall the entire product every time.
So, Is It Good for Users or Not?
Continuous deployment can be done in a way that’s good for both engineering teams and users, but you do need to take some precautions. By taking care when you introduce changes that your users will really notice and making sure that you make time for important processes like QA, you can get features out faster and constantly improve your product. And that is very good for users.
Interested? You should follow me on Twitter.
For more information on the user experience, check out:
We’re excited to share the infographic we designed for the Intuit Health Benefits Center project to answer this question.
In July 2009, Intuit conducted a survey with over one thousand small business owners in California asking about the health insurance options they offered their employees and how much they were paying for health insurance plans. From prior discussions with business owners, we knew employers were very interested in finding out the results of this survey, as they wanted to remain competitive with other businesses in their industry. We decided that an infographic would be the perfect way to transform our huge collection of data into a single, compelling visual. Our goal was to create a comprehensive infographic that would be instantly meaningful and easily understandable to the many employers looking to get a handle on the best way to offer competitive insurance packages to their employees.
Sound easy? Not exactly. Like most aspects of design, it turns out that creating infographics is a tricky business – on the one hand, we had to be careful not to present too much information so as to be overwhelming, but on the other hand, our infographic had to be able to provide enough detail to be useful to a wide range of employers looking for very specific information. And, of course, we had to do all of this without getting bogged down in the details or jargons of health insurance plans that often don’t make sense to someone at first glance who isn’t in the healthcare industry.
Here are our top design principles for creating an infographic:
1) Focus the infographic around a single, key question
We centered our infographic around the fundamental question new small business owners cared about most: “How do my health insurance costs compare?” Then, to answer this question, we created an infographic design to breakdown some of the important specifics – like employer and employee costs by region, and the average employer contribution. We placed secondary information, such as the various plan types offered by employers, on the side of the infographic and used subtler visuals so it would not to compete with our key message.
2) Identify a visual metaphor to help expose differences quickly
We wanted viewers to be able to notice variations in data quickly, as this is the fundamental power of a good infographic. Consequently, we came up with helpful visual metaphors that allowed us to visually represent plan costs by region in two ways. First, we used a heat map of California to indicate employer costs so viewers could quickly see regional differences at-a-glance. Second, we displayed horizontal bars that corresponded to the relative costs by employers and employees per region so viewers could visually compare differences in amount.
3) Use minimal text, and rely on visuals to tell the story
We wanted to keep our infographic clean and simple by requiring minimal reading, so we included a visual key for our chart at the bottom of the infographic to help keep the text and fine print to a minimum.
Overall, our quest to create an effective infographic helped us to double-deliver to our client — we not only revealed interesting findings, but also presented the findings in a ready-to-go format that met the needs of the employers Intuit wanted to reach. We’re excited to share our newest piece of healthcare artwork with you, so take a look and let us know what you think!
https://benefits.intuit.com/content/infographic.pdf
Henry Ford once said that, if he’d asked his customers what they wanted, they’d have asked for a faster horse. In the high tech industry, this quote is often used to justify not talking to users. After all, if customers don’t know what they want, why bother talking to them?
You need to talk to users because, if you ask the right questions, they will help you build a better product. The key is figuring out the right questions.
For starters, users are great at telling you when there’s something wrong with your product. They can tell you exactly which parts of the product are particularly confusing for them or are keeping them from being happy, repeat customers. Figuring out what to do about those problems is your job.
In general, users are not going to be able to answer the following types of questions:
- What new technical innovation is going to revolutionize a particular industry?
- What’s the next cool gadget that you’d like to buy?
- Do you think that people like you would buy this new cool gadget that you’ve just learned about?
- What new features would make this product more interesting/compelling/fun/easy to use? (although, this question becomes more answerable when the user is presented with some options for which features they might prefer.)
- How exactly should we change the product to make it easier for you to use?
They are fantastic at answering questions like these:
- What do you most love or hate about this product?
- Do you find anything about this product hard to use or confusing?
- Does this product solve your problem better or worse than what you’re currently doing?
- How are you currently solving a particular problem that may or may not be addressed by this product?
- What don’t you like about your current solutions for a particular problem?
- Why did you choose this particular solution as opposed to another solution?
Obviously, there are innumerable other questions that you might want to ask your users, so how do you decide which ones they’ll be able to answer with any degree of accuracy?
Problems vs. Solutions
Users are much better at telling you about problems that they’re having than solutions that they want. In Ford’s example, when people asked for a faster horse, what they were really saying was that the horses they had were too slow. They didn’t specifically want a faster horse. They wanted a faster means of transportation that was no worse than a horse in other respects.
Frequently in user tests or customer feedback sessions, customers will tell you very clearly, “I want x!” Your job is to understand why they want x and then to determine whether or not x is really the right solution. It’s not that they never have good solutions, but users tend to only look at the product from their own perspective and usage patterns, while you should be talking to lots of different types of users with lots of different types of problems. They’re not thinking about the product as a whole or how to fix things for the other several million people who might have slightly different problems.
When users try to give you solutions, encourage them to talk about their problems instead. Then figure out what they’re really asking for, and give it to them.
Past vs. Future Events
It’s much easier for people to answer questions or give opinions about something specific that has already happened than about something that might happen in the future.
Consider the question, “What do you want to eat tonight?” vs. the question, “What did you think of the meal you just ate?” For the vast majority of us, the second one is much easier to answer. It simply asks you to formulate a concrete opinion about a single event that has recently happened. The first question asks you to imagine all the various available options for food and make a decision about what you might like in the future based on probably imperfect information.
This is true with products, as well. It will be much easier for your user to explain how performing a particular task went than to predict how he would like to perform that particular task in the future. That’s why, when you’re doing your preliminary research to determine product direction or early feature development, it’s very important to give users hands on tasks that they can perform for you and then give opinions on rather than to talk abstractly about the solution you’re considering providing for them with your product.
Users vs. Other People
Unless you’re really lucky, you’ve probably realized that people are terrible at figuring out what other people want. Perhaps you came to this realization on some birthday or other gift giving holiday. Users suffer from the same problems as gift givers. They’re almost always terrible at telling you how other people will react to a product.
And yet, talk to just a few customers or user test participants, and you’re guaranteed to hear one of them say, “Well, it’s not for me, but my mom/friend/boss/brother would be really into this…” Another one you hear a lot is, “My mom/friend/boss/brother would never be able to use this. It’s way too complicated.”
This information can be marginally useful if you’re trying to find the right customer segment, but take it with a grain of salt. Reassure the user that you’re also going to talk to people like their mom/friend/boss/brother, and what you’re really interested right now in is the user’s opinion. Then talk to the mom/friend/boss/brother to find out their real feelings. Chances are, the person you’re talking to doesn’t really know what anybody else wants as well as they think they do.
The Right Questions
So, what should Henry Ford have been asking his customers? Instead of, “What do you want?” he could have asked, “Is there anything you particularly like or don’t like about your horse and wagon?” If they chose not to buy a car, he could ask, “Why didn’t you buy that car?” Once they bought a car, he could have asked, “What made you decide to buy a car?” or “Was there anything you found particularly confusing or hard to use about your new car?” He could even have gone for a drive with some of them and observed the various problems that they encountered.
In fact, there were dozens of things he could have done that might have helped him improve the design and marketing of his product. He just couldn’t ask them, “What do you want?” because they almost certainly would have said, “a faster horse.”
For more information on our approach to getting customer feedback, check out:
So, you decided to do some user research in order to find out where you can make improvements. After a few hours of user interviews, you ended up with a notebook full of scribbled information that all seemed really critical. How in the world do you figure out what to do with all that information?
If your answer is “talk about it all abstractly with everybody in the company or write a huge paper that nobody will read and then go on with business as usual,” you’re in good (bad?) company.
But you have to DO something with all that data. You have to analyze it and turn it into actionable items that your engineering department can use to fix your product. It’s not always easy, but I’m going to give you an approach that should make it a little easier. This isn’t the only way to do your test analysis, but it’s one of the quickest and easiest that I’ve found when you are concerned with key metrics.
When to use this method:
- You have an existing product with a way to measure key metrics, and you’re interested in improving in particular areas related to your bottom line
- You have a limited research and development budget and want to target your changes specifically to move key metrics
- You are looking for the “low hanging fruit” that is getting in the way of your users performing important tasks with your product
- You are working in an agile development environment that is constantly tweaking and improving your product and then testing the changes
When not to use this method:
- You have an existing product that you are planning to completely overhaul, and you want to understand all of the major problems before you do your redesign
- You are trying to create an overall awesome, irresistible user experience that is not related to a specific metric
- You are designing a new product or feature and are observing people using other products to identify opportunities for innovation
If you fall into the first bucket, read on…
The Five Basic Steps:
- Identify key metrics you’d like to improve
- Identify the tasks on your site that correlate with improvement in those metrics
- Observe people performing the appropriate tasks
- Identify the barriers preventing people from completing or repeating the tasks
- Develop recommendations that address each specific barrier to task completion
Step 1: Identify Key Metrics
First, identify the metrics that you care about, and look at the distinct steps that your users are most likely to take to change those metrics. This way, you can plan your qualitative testing to show you exactly what is getting in the way of your users reaching each subsequent step.
As an example, let’s imagine that you have a social networking site that earns revenue when people give virtual gifts to each other to display on their profile pages. Because your revenue depends on lots of users purchasing lots of things for each others’ pages, you might care about the following metrics: how many people register, how many people customize their profile pages, how many people make friends, how many friends they make, and how many people purchase one or more gifts. Obviously, that last is the most important, since that’s where your revenue comes from, but the others are also important, since improving those numbers should increase everything downstream, if done in the correct way.
Your goal is to get people from point A to point D as quickly and pleasantly as possible. To do that, you want to look at all of the barriers you have erected in the way of your users accomplishing those tasks.
Here’s are the pieces of the user flow that change your key metrics:
Registration > Profile Customization > Finding a Friend > Purchasing a Gift
Step 2: Identify Individual Task Flows
Now that you know what your key metrics are, you need to make sure that you observe your test participants trying to accomplish the tasks that will eventually lead to changing those metrics. To plan your tasks and analyze your data, it helps to break down your individual tasks into smaller user flow steps based on your user interface.
For example, while the number of successful registrations may be a single metric, there may be several screens or discrete interactions involved in your entire registration process. Make a list of what they are now.
As an example, I ran a test recently for a product that had a 4 step registration process. The user flow for registration on the site looked like this:
| Landing Page |
> |
User name |
> |
Personal Info |
> |
Download |
Step 3: Observe People Performing Tasks
So let’s say that, based on the metrics you want to change in your hypothetical social networking site, you’ve determined that you need to gather data about registration, profile customization, finding friends, and purchasing a gift. You’ve scheduled 5 people in your target demographic to come in for user test sessions. I’m not going to teach you everything you need to know about running a test, but here are some basics.
First, let the user begin using your product however they want and note all of the things that they do that aren’t the tasks you’ve identified. Remember, any time spent not doing your target tasks is time that is not being spent improving your metrics, so you want to know what these other things are! If you give your participant a targeted task right away, you will never learn what other things they are doing instead. Finding these distractions allows you to eliminate them or change them so that they also improve your key metrics.
Watch everything your user does with the perspective of the ideal flow for your metric. Do your participants wander off track or getconfused during registration? Do they fail to find their own profile? Do they not have the information they need to find a friend? Do they fail to understand what gifts are or how to purchase them? Do they get distracted by a totally different part of your site that doesn’t contribute to improving your key metrics?
Once you’ve allowed the participant some free exploration time, you may need to move them to a particular task. For example, in our current example, it might be that you need to ask the participant to try to purchase a gift, even if that’s something they wouldn’t do in the context of a study environment. You can move them along by saying something casual like, “Did you notice that there is a way to purchase gifts? What do you think about that?”
Meanwhile, record what the participant is doing and encourage them to talk about their impressions of the product.
Step 4: Identify Barriers
Once you’ve gathered data by watching 4 or 5 people repeat the same tasks, you need to analyze your data to figure out where the barriers are and communicate them effectively to the team. Determining the barriers should be pretty easy. Just ask yourself the following questions:
- Where did participants seem confused or distracted and stop performing a task?
- Which things took longer than they should have?
- Why did participants fail to accomplish a task?
- What tasks did the participants perform that would not improve the key metrics?
In the product I tested with the four step registration process, the metrics showed significant drop off one each screen. On screen number 2, the user was asked to choose a unique user name and enter some information. It had a surprising amount of drop off considering how simple it was. After watching a few user tests, I noticed that many people were trying to select user names that were not available, but they were failing to notice the error message telling them to choose a different one. Even if they noticed the error, several people had a tough time finding a user name they liked and would spend minutes typing in word after word, getting frustrated, and finally giving up.
By watching people try to register for the product, we identified several significant barriers to successful registration in just one step of the process. In fact, we found similar problems – some large, some small – in each of the steps.
Once we’d identified the barriers, organizing and explaining them to the team was easy with a simple, annotated flow of the steps leading up to the goal along with the problems associated with each step. For example, the flow for the registration test might have looked like this:
Landing Page
- Didn’t understand the product
- Felt the product was aimed at teens
- Thought the network was very small
User name
- Didn’t know when a user name was taken
- Couldn’t come up with a decent name
Personal Info
- Were concerned about privacy
- When failed Captcha, all info had to be re-entered
Download
- Were uncomfortable downloading b/c of viruses
- Didn’t know what they were downloading
Overall
- Were bored during registration process or complained that it was taking a long time
Step 5: Develop Recommendations
Now that you know what barriers are keeping your customers from accomplishing the goals you’ve set for them, you need to generate recommendations for ways to remove those barriers. You can do this by looking at exactly what the barrier is and what the users’ reactions were to it, and then brainstorming ideas to help the user overcome that barrier. Yes, this is the tough, somewhat creative part. You don’t want to just take any recommendation that the user gives you. You need to understand what problem they’re having and come up with a way to fix it that doesn’t cause any other problems.
Going back to my example, once we found the problems on the user name page, we looked at several solutions. We definitely needed to make it more obvious to the user when they selected a name that was already taken. We came up with a few simple ways to solve this particular problem: we could suggest other user names when people tried one that was already taken; we could make the error more noticeable; we could make the Next button obviously disabled so that they couldn’t even try to move on; we could free up some names that had been taken but weren’t currently in use so that the selection of user names was better. We then selected a couple of these solutions based on expected ROI calculations.
Even the lowest effort of these suggestions, improving the visual design of the error, caused an immediate and statistically significant decrease in drop offs for that step in the registration flow, and eventually improved revenue by increasing the number of successful sign ups. The barrier was lowered, if not entirely removed.
You may have noticed that the last section is labeled “Overall.” This is where you look at the process as a whole, rather than a sum of its parts. For example, one comprehensive solution for drop off at each step might be to reduce the number of steps it takes to register (almost never a bad idea!). Doing this wouldn’t necessarily mean that you wouldn’t have to address the other problems individually, but you might get fewer drop offs simply because it would take less time for users to finish the process.
How Is This Different?
You might be wondering how this is different from more traditional ways of running user tests and analyzing data. In any user test, you’ll need to come up with tasks, observe users, figure out where they’re having problems, and come up with solutions for the problems.
There is a difference though. My experience has been that companies do not fix every single UX problem that they find in user research. I don’t love this, but I do understand the need to prioritize important changes.
So, if you’re only going to fix a few problems, you should make an effort to identify the most important ones. The counter intuitive part is that the most important problems might not be the worst problems from a user experience stand point, but they will definitely be the ones that are keeping your users from reaching the goals that improve your most critical metrics.
Using this framework will help you identify your key user flows, find and communicate the major barriers to success, and propose targeted solutions that will improve both your user experience and your business.
For more information on our approach to getting customer feedback, check out:
Ok, maybe hate is a little strong. Paper prototypes and sketches have their place in interaction design. For example, they’re great for helping to quickly brainstorm various different approaches to a problem at the beginning of a design process. They’re also a very fast and cheap way to illustrate a new idea, since most people can draw boxes faster than they can build interactive prototypes. But, in my opinion, they have several serious drawbacks.
Before I get too far into this, let me define what I mean by a paper prototype, since I’ve heard people use the term to refer to everything from sketches on actual pieces of paper (or cocktail napkins in a couple of cases) to full color printed mockups with a polished visual design. In this instance, I’m referring to a totally non-interactive screen, mockup, or sketch of any sort of application that is meant to be shared with customers, test participants, or team members. It can be printed on actual paper or shown on a computer screen, but whatever the viewer does to it, a paper prototype is not interactive.
So, what don’t I like about them?
Screen vs. Paper
This first couple of peeves apply to screens that are actually printed out or drawn directly on paper. With a few exceptions that I’ve listed below, I’ve found this approach to be really counterproductive.
Iterating On a Design
One of the biggest problems with hand drawn sketches on paper has less to do with user interactions and more to do with my work flow as a designer. Sure, sketching something quickly on a piece of paper can be quick, but what happens when I realize that I want to swap two sections of the screen? I can draw arrows and lines all over it, but that gets messy pretty fast. Whenever I want to make any changes to my design, I need to create a whole new sketch. This can mean redrawing the entire screen quite a few times.
If I’m creating a design in HTML or any other prototyping tool, the very first version might take a little longer than a quick sketch, but the second through nth iterations are a whole lot faster. And, as a bonus, I can check them into source control, which means I’m a lot less likely to lose my work than if I have dozens of pieces of paper scattered all over my office.
Interacting With Paper
Whether they’re sketched out by hand or printed out on paper, people interact with paper screens differently than they do with computer screens. They view them at a different angle. They focus on different parts of the screen. They use their hands to interact with them rather than a mouse and keyboard. Any feedback that you get on a printed design will be colored by the fact that people are fundamentally interacting with it differently than they would if it were on a computer screen.
Given all of these drawbacks, there are a few situations when designs printed on paper can be used effectively:
- You are at the very beginning of the design process, and you want to explore a bunch of different possible directions with other team members very quickly before committing yourself to fleshing out one or two specific options.
- You’re designing material that is meant to be printed, like brochures, user manuals, books, etc. In this case, you want to know how people will interact with the printed media.
- Your product is an interface for some sort of embedded or small screen device that would be very difficult to replicate in a quick interactive prototype. For example, a screen for certain mobile devices or the heads-up display for a car dashboard might be hard to show interactively in the appropriate context.
- You have several different visual designs, and you’d like to show them all to users at the same time in order to see which one is the most attention-getting. You’ll still need to show the designs on screen, of course, since colors can vary so much between screen and print, but it can be helpful to lay out several pieces of paper so that the various options can easily be compared.
- You need to share screens with people in an environment with absolutely no access to a computer whatsoever. You know, maybe you’re in the middle of a meeting and need to sketch something quickly, or the rest of your design team is Amish, or you are designing in a post-apocalyptic wasteland where the computers are trying destroy humanity.
On the other hand, if you’re designing desktop or web applications for standard computers, at the very least, show your prototypes on a computer, even if they are not interactive!
A few reasons why it’s especially important to show interactive designs on a screen:
Animations and interactions
I am an interaction designer. A big part of my job is to determine what happens when a user interacts with a product. Sometimes that’s obvious. For example, if I click on a link with some text that reads, “Contact Us,” I expect to be able to communicate in some way with the people who have created the product.
But is it so obvious? Back in the day when links could only take you to another static web page, sure it was. But now, all sorts of things could happen. I might have different behavior on hover vs. on click. I could be given the option to have a live chat with a rep. I might be presented with an inline contact form so that I don’t have to leave the page I’m visiting. The contact form could have some information already prefilled for me based on my present location or account type. There could be animation involved in displaying the contact information. There could be some sort of contact wizard that would change later screens depending on choices the user makes initially.
All these interactions are much harder to convey with paper prototypes than with interactive wireframes. Sure, you can make a different screen showing each stage of the interaction, but with anything more complicated than a few steps, your observers can get lost pretty fast shuffling through papers. Having it all working in an interactive prototype allows users to click through and explore naturally. They can also discover things like hover interactions or animations on their own, which are particularly unsuited to paper.
Testing
What? You don’t need to test your designs with users? Your designs spring from your brain fully formed and perfect? Well, good for you. The rest of us mortals actually like to show our designs to test participants and get feedback from people who aren’t familiar with the product.
Now, I’ve run a lot of user tests. I’ve run them with working products, interactive prototypes, pictures of screens displayed on computers, pure paper prototypes, and physical mockups of products. I’ve used prototypes built with everything from HTML to Visio to cardboard. The one constant was that the closer the prototype mimicked the final product interaction, the fewer problems we found once the product was built. And since we recommend iterative testing during development rather than waiting to test until the product is 100% built (you know, just in case your design wasn’t entirely perfect the first time around), an interactive wireframe is the best trade off of speed for functionality.
Communicating the design
You can have the best design in the world, but if you don’t communicate it effectively to the engineers who have to build the thing, it doesn’t matter one bit. Of course, once you’ve designed all of your static screens, you could paste them into a big spec with extensive documentation about what each button on each screen does and how many seconds an animation is supposed to take and blah blah blah. I’ve done it when it’s been specifically requested by a client. I’ve also never met an engineer who was particularly happy to read through one of those three hundred page documents. Besides, just the thought of making changes to every screen in that document every time there’s a change makes me tired.
An interactive prototype, when built intelligently, is a different story. It allows engineers to see exactly how every element of the design is supposed to work. What happens when you click on a link? Click on it to find out! Is the animation supposed to sweep horizontally or vertically? Take a look! Of course, you’re free to add notes to screens as necessary to fully communicate absolutely everything, but the difference between using this lightweight approach and a full design document for reference is night and day.
What’s the alternative?
So, what should you use other than paper prototypes? I’ve mentioned it throughout the post, but I’ll be perfectly clear. Your best bet is an interactive wireframe that mimics the behavior of the actual product as closely as possible. It doesn’t have to be hooked up to a database on the back end or use real data. It doesn’t even have to be fully functional if you’re only testing parts of it or if you’re annotating it with notes. But it should make the user, whether they’re a test participant, an engineer, or your design manager, feel like they’re actually performing tasks with the product.
Luckily, you’ll find plenty of products out there that will help you build interactive wireframes with very little technical expertise. You don’t need to be an engineer or a Flash expert to make your screens clickable. My favorite tool is Dreamweaver for creating quick HTML prototypes with basic animations and interactions, but other people have had good luck with applications like Axure and or even PowerPoint (although, that has some serious limitations).
There is, of course, one quick caveat. I know I’ve been harping on how closely your prototype should match your eventual product. However, you do not need, and probably shouldn’t have until quite late in the design process, a full visual design for your interactive prototypes. Why is that? Well, I’ve found that making the visuals look too polished can actually focus the user on the aesthetics rather than on whether they can accomplish a task. A lovely or flashy visual design can distract the user from interaction problems that you’d rather find early in the process.
For best results, focus on creating a simple, clean wireframe with as much interactivity as you can possibly give it. Your users will thank you for it.
We’re proposing two panels for South by Southwest. Audience voting on the panels is open until September 4th and you can vote thumbs up or down on any as many panels as you want so if these sound interesting, please vote yes! (note that you’ll have to register but it only takes a second)
Comfort foods are the epitome of success. Delicious, ubiquitous, and easy. This panel of chefs and designers will explore what food can teach about product design. What makes a new recipe take-off? How do you make your product comfy on first use and then make people want to use it again?
Questions this panel will answer:
- What do eating a food and using a technology/software/website have in common?
- What makes comfort foods so appealing?
- Can those same qualities translate into software/websites?
- How do you create a new recipe that a mass audience will like as much as an old standby like mac-n-cheese?
- How do you have a successful yet cutting edge restaurant?
- How do you create a new product that people will feel comfortable using from the start?
- What techniques/lessons from recipe creation (for magazines and restaurants) can be applied to the design of new technologies?
- How do you innovate if people like known things?
- How do you get a following for your food? For your restaurant? For your product?
- What mistakes should you avoid when doing something new?
Dazed and confused in a sea of technology and marketing fluff? This talk will help you pick the right technology for your Rich Internet Application based on the user experience implications. See specific examples of the trade-offs with each so that you can finally make an informed decision.
Questions this panel will answer:
- What is a Rich Internet Application (RIA)?
- What sorts of features should you expect a RIA platform to offer?
- What is Microsoft Silverlight?
- What is Adobe Flex/Air?
- Can you create a RIA using HTML/CSS/Javascript?
- Are there any other technology platforms to consider?
- What are the pros and cons of each platform from a user experience perspective?
- What are specific examples of applications using each technology effectively and ineffectively?
- What tools are available to design for each platform?
- What are the ten key points to think about when deciding which technology to use?
I’m a big advocate of lazy registration. Lazy registration is the concept that you don’t have a sign up form on your site but instead let the user try out your site for as long as they like and ask them for user data as part of their natural trajectory. This results in an experience full of open inviting doors.
The key is providing users with a reason to give you the registration data you’re looking for. If you’re site is good enough to do that (and if it’s, than that’s a bad sign), you’re golden.
How to make this pattern work:
- Let the user enter as much data as they want wherever they want to do it
- Then, to let them save their data, choose from one or more of these solutions:
- Provide a Save or Submit button that on click asks them for their email address to register
- Provide a link that they can save on their own to get back to their data
- Save their data automatically via cookies so that when they revisit your site, the data is still there
Examples
Picamatic, an image hosting service, is a fantastic example of lazy registration.
A user can upload their images and can then either copy and paste a link to that image on their own:
Or click Save these images to get emailed a link to the images:
Asking after data entry
Another good example is the way that commenting works in blogs. It’s only when you enter a comment that you are asked for your email address to register.
Similarly, on sites like Stackoverflow , when you ask a question, then you are asked to enter in your email address at the bottom of your post:
On GetSatisfaction, when you’re done entering in your question, you get a pop-up after you hit submit that asks you to register:
Cookies
Cookies are another key to lazy registration. See how much info you can keep for the user when they come back to your site. If you’re an ec-ommerce site you should be saving anything the user adds to their shopping cart. You can also save items they visited, searches they did, etc.
Kayak is a great example which retains searches you’ve made and saves them to your account when you do register.
Now go out there and rid your site of those registration black holes.
The new shopping area of the Intuit Health Benefits Center has just launched! We’ve been working very closely with Intuit on the design of this new venture for months and are proud to be a part of making healthcare insurance more accessible to small businesses.
In response to everyone’s awesome feedback on last week’s diagram of what we do, I’ve posted a new one:
This one adds a circle for the user which I agree is super important and a key part of our process. It also more specifically spells out what we do — strategy, user research, and design. The idea is that someone has an initial concept and we can help create the strategy and design for that concept based on our understanding of the concept, user needs, and development constraints. Thoughts?
I recently sketched this diagram to explain what we do and wanted to see if it resonated with people. Is this too high level? Does it add a layer of understanding? Basically, we work with clients on all levels of product design including feature definition, interaction and visual design, user research, and specification. The only thing we don’t do is the final code. Thoughts?
