How to make your shopping cart suck less - The Oatmeal

via theoatmeal.com

Posted via email from Does IT Matters?

Design Meets Research

via aiga.org

Posted via email from Does IT Matters?

The "Java Life" Rap Music Video

via youtube.com

Posted via email from Whatsoever

The KJ-Technique: A Group Process for Establishing Priorities

The KJ-Technique: A Group Process for Establishing Priorities

By Jared M. Spool

Originally published: May 11, 2004

Back in the late 1970’s, the US government commissioned a study to look at effective group decision making. In the study, they asked 30 military experts to study intelligence data and try to construct the enemy’s troop movements.

Each expert analyzed the data and compiled a report. The commission then “scored” each report on how well it reported the actual troop movements. They found that the average military expert only got 7 out of a 100 elements correct.

Each expert then reviewed all of the other experts’ reports and rewrote their initial assessment. The average accuracy for these revised reports was 79 out of a 100.

What was different between the first report and the second? The experts didn’t have any new information. All they had were the perspectives of the other experts. When they added those perspectives to their own, their accuracy increased ten-fold.

Deriving Priorities When Resources are Limited

In design, our resources are limited. Priorities become a necessity. We need to ensure we are working on the most important parts of the problem. How do we assess what is most important?

In our consulting work, we’ve found that, like the military experts, our clients usually have most of the answers already in their own organization. The trick is to get all the people with the right perspectives to reach consensus quickly.

For this, we’ve turned to a group consensus technique we’ve been using for years, called a KJ-Method (also sometimes referred to as an “affinity diagram”). The KJ-Method, named for its inventor, Jiro Kawakita (the Japanese put their last names first), allows groups to quickly reach a consensus on priorities of subjective, qualitative data.

Sometimes, we’ll be in a situation when every team member has different opinions on how we should proceed, such as identifying who the most important users are for an upcoming study. Other times, we’ll have collected tons of subjective data, such as our observations from hours of user testing. We find the KJ-Method to be very effective for organizing and prioritizing opinions and subjective data.

The Accuracy of the KJ-Technique

One of the most amazing things about the KJ-Method is how well it objectively gets groups to the top priorities. Different groups can analyze the same data and will often come to the same results.

A few years back, we conducted an experiment where we had 15 teams use the method simultaneously. Each team consisted of ten usability specialists, each from different organizations. Their goal was to take their own individual experiences and prioritize an action plan as a team. We focused the exercise around the question, “What are the biggest obstacles to producing quality products that you face in your job?”

Each person started by listing their own personal obstacles. Then, using the process, they spent approximately 40 minutes reaching consensus. By the end, we asked each team to list the top 3 items.

When we compared the all 15 teams’ results, they all had basically the same top items: Need to define requirements better; Need to understand the users better; and Need to have better communication with their design team.

It was amazing how each of these teams came to basically the same top priorities, even though they each started with individual data. We’ve repeated this experiment 3 times, always with very similar results. The KJ-Method really does work to get an objective group consensus out of a collection of subjective, opinionated data.

The KJ-Method: Step By Step

The KJ-Method is simple and easy to do. It focuses the group on the task at hand and is excellent at eliminating unnecessary discussion and distractions from the goal. It’s a tool that everyone should have in their designer’s toolbox.

We’ve got it down to an eight-step process that we can do with any size group in less than an hour. Here’s how we do it: We use two colors of removable sticky notes, such as yellow and blue. We like the standard 3x5 size or the 4x6 size, if we can get it. We need a room with a lot of wall space. Typically, a large conference room will work well. We also need a facilitator. This is a person who will move the group from one step to the next. (While a facilitator can also contribute as a group member, politics may make this less than desirable. The safe road is to have the facilitator play a neutral role.)

We’ll need a whiteboard or flipchart for the final ranking step.

Step 1: Determine a Focus Question

The focus question drives the results. Every session will have its own focus question. Sample focus questions are:

• Who are our users?
• What features do users need?
• What goals do users have when they come to our site?
• What did we learn in our usability study?
• What are the biggest obstacles preventing our products from selling?

We can only work on one focus question at a time, so we pick the most important one first. (An experienced team can do two rounds of KJ’s in an hour allowing them to deal with two important questions.)

Step 2: Organize the Group

Get folks together for an hour. We want people from different parts of the organization, to get their different perspectives.

Step 3: Put Opinions (or Data) onto Sticky Notes

Putting one item on each sticky note, we ask each group participant brainstorm as many items as they can think of.

Step 4: Put Sticky Notes on the Wall

In random order, each participant puts their sticky notes up on the wall. Then, they read other people’s contributions. If, at any time, they think of something else that should go on the wall, they need to jot it down on a sticky note and add it to the collection.

Step 5: Group Similar Items

Once everyone has had a chance to add their contributions to the wall, the facilitator instructs the group to start grouping like items in another part of the room. This is what we say when we’re facilitating

“Take two items that seem like they belong together and place them in an empty portion of the wall, at least 2 feet away from any other sticky notes. Then keep moving other like items into that group.”

“Feel free to move items into groups other people create. If, when reviewing someone else’s group, it doesn’t quite make sense to you, please feel free to rearrange the items until the grouping makes sense.”

“You’re to complete this step without any discussion of the sticky notes or the groups. Every item has to be in a group, though there are likely to be a few groups with only one item.”

Notice that we’ve not allowed the group any discussion about the contents yet. We’ve found that premature discussion often focuses on borderline items -- things might be unimportant to the focus question. If they aren’t important, then spending any time discussing them is a waste.

In later steps in the process, we have time to discuss the important items. Therefore, by preventing conversation now, we save time for the important conversations later.

This step is complete when all the items are moved from the original wall into groups.

Step 6: Naming Each Group

Using the second color of sticky notes, we ask each participant to assign a name to each group. Here are the instructions we give:

“I want you to now give each group a name. Read through each group and write down a name that best represents each group on the new set of sticky notes I just gave you.”

“A name is a noun cluster, such as 'Printer Support Problems'. Please refrain from writing entire sentences.”

“As you read through each group, you may realize that the group really has two themes. Feel free to split those groups up, as appropriate.”

“You may also notice that two groups really share the same theme. In that case, you can feel free to combine the two groups into one.”

“Please give every group a name. A group can have more than one name. The only time you´re excused from giving a group a name is if someone has already used the exact words you had intended to use.”

Again, notice here that we’re not allowing the group to discuss the name. Everyone gets a chance to get their own views out, regardless of the politics and personalities involved.

This step has a hidden agenda: the final review. By insisting that everyone read every group, it forces the participants to review everything on the wall and consider it. This is critical for the next step: voting.

Step 7: Voting for the Most Important Groups

When we have finished this step, every participant will have democratically shared their opinion on the most important groups. This will be independent of any coercion amongst their peers or factors like the number of items in each group. They’ll purely use their own viewpoint to choose those groups are most important to answering the focus question.

To get through this stage quickly, we break it up into three parts. First, we have each participant grab a piece of scrap paper and write down the names of the three groups that they feel are most important.

We’ll repeat the focus question at this point, so they know which question they are answering. For example, if our focus is “What features do users need?”, we’ll give these instructions to the participants:

“On a piece of scrap paper that you will neither post nor share, I want you to write down the three names of groups that you think best answer this question: What are the most important features that users need?”

“If a group has more than one name, you are to chose the name that best represents the most important features in that group.”

Occasionally, participants will have trouble narrowing the groups to just three. We’ll often instruct the people having trouble to write down five, then cross two off. While this often produces a giggle, it turns out to be helpful to some participants.

The second part of this step happens when they have their three choices. We ask them to rank them from most important to least important. We’ve found that doing this separately from identifying the top three makes it easier on the participants.

After we’ve ensured that everyone has their three top choices and has ranked them, we give the last part of the instructions: to record their votes on the group sticky. If, for example, the group sticky notes are blue, we´d use these instructions:

“I want you to go to the blue sticky that best represents your first most important choice and put three X’s on it.”

“You can then go to your second most important choice and put two X’s on it.”

“Finally, go to your third most important choice and put a single X on it.”

When we’re done, everyone will mark six X’s on the group names that they feel are most important.

Again, notice that there we’ve not allowed any group discussion up until this point. Even though they’ve worked as a group, we’ve prevented discussion from eating up any portion of the meeting.

This is because, up until now, we’ve not known what items were most important. It just doesn’t make sense to spend time discussing unimportant items.

Step 8: Ranking the Most Important Groups

Once everyone has marked their votes, we grab all the group sticky notes with votes on them and place them on the whiteboard (or flipchart). We’ll order them by the number of votes each sticky received, with the highest numbers at the top.

At this point we ask the group to gather around the whiteboard and we read off, in order of importance, the names of each group that received votes.

Because some groups may actually represent identical priorities, we allow the team a few moments to consider combining groups. We have a simple process for doing this. Here’s how we explain it to the participants:

“We now need to see if there are any groups that we should combine. You can nominate two groups that you think are the same thing.”

“We’ll then take a preliminary vote, to see if anyone thinks they aren’t the same. If anyone believes they are different, we’ll spend a little time discussing why they believe that.”

“After the brief discussion, we’ll take a final vote. That vote needs to be unanimous for us to combine the items and their scores.”

“Remember, the two groups being considered need to be identical. That means you could substitute one for the other. A group that’s a subset of the other group does not qualify for combining.”

As each pair is nominated, we take the preliminary vote. We let the participants discuss amongst themselves why they are for or against combining. As facilitator, we let everyone have their say and pay close attention to the group dynamics, to prevent people from getting their opinions bullied.

Since we insist on unanimous agreement for combining items, it gives great power to a single person. However, since the items were already scored, it’s hard to abuse the power in any meaningful way. Someone who is trying to hold up the process by being argumentative won’t get very far.

Every time we combine two items, their scores are added together and they are moved higher in the list. Usually, we reach a point where there are three or four items which are ranked much higher than the rest. At this point, the facilitator can stop the process, since any further combinations are unlikely to change these top priorities in any meaningful way.

At this point, the facilitator declares the exercise finished and reviews the top three or four ranked items. These are the top priorities for the focus question.

Reaching Consensus in Record Time

When the KJ-Method works (and it has rarely failed us), we reach group consensus much faster than any other method we’ve had. Because we’ve encouraged people from all over the organization to participate, the resulting priorities will typically stand the test of time and won’t come under constant challenge.

The KJ-Method is a fascinating mix of independent brainstorming, group dynamics, and democracy. It allows a team to be creative and critical in a productive manner, where strong personalities and politics play second fiddle to the independent perspectives and experience of the team.

The KJ-Method is such a valuable tool that we sometimes wonder how we’d ever get our job done without it.

via uie.com

Posted via email from Does IT Matters?

Inbound Marketing Ecosystem

via 4.bp.blogspot.com

Posted via email from Does IT Matters?

Bite-Sized UX Research

Bite-Sized UX Research

By Steve Baty

Published: May 7, 2008

It’s not uncommon for projects to lack the time, money, or resources to conduct ideal user research activities. There are many reasons why this occurs:

• Sometimes we’re brought onto a project late.
• Perhaps we’re new to an organization that doesn’t really get UX.
• Maybe a company is rushing to bring a product to market for some reason—and there are plenty of good and bad reasons this might be so—and there simply isn’t time to “go big”.
• Perhaps your client or organization is following an Agile development methodology.

“As UX professionals, we can always add value, at any stage in a project.”

At such times, it can be tempting to just throw up our hands in dismay and do nothing or lament the fact that everything isn’t perfect. But the simple fact is that, as UX professionals, we can always add value, at any stage in a project—even if a project team can’t act on our advice straight away.

Focus on Winning Small Victories Often

Regardless of the cause for your company’s resource crunch, focus on getting small wins as often as possible throughout your involvement in a project. This is a fairly common piece of advice that crops up time and time again, but it’s very much worth repeating. And it applies just as readily to both situations where time is short and those when there’s just not enough of you to go around.

This advice is equally valid for UX professionals who find themselves in new positions as the sole user experience person. It’s common for new hires to ask: “How do I sell the benefits of UX?” The answer is generally something along the lines of: “Focus on small wins.” In other words, don’t waste your energy putting together a series of case studies on how other people have created value at other organizations. Instead, do something positive and tangible—however small—and it’ll carry a lot more weight.

Go for Impact

Concentrate on getting bang for your buck. Depending on your circumstances, you may not get many opportunities to demonstrate the value of UX, and when time is short, there can be a tendency to just do something—anything. It’s an urge you should try to resist. If you want to have a greater impact, ask your project team—the project manager, the development team, and the business stakeholders—a few pointed questions before you get started:

• What are the critical features of the Web site or application?
• What features would be hardest for the developers to change once they’ve developed them?
• What are the areas of greatest ambiguity in terms of user requirements, audience groups, or competitive offerings?

And then ask a few more questions:

• How can I best document my user research findings, so the project team can use them?
• Do we have time for iterations? And if so, how many?

With this information, you can start planning some activities that focus on the most important elements of the project—the critical features for success; the features that are hardest to change; or the gray areas of the project—and deliver some real value.

It’s all very well to say “do something small,” but what, exactly, can you do?

Early Days

You can demonstrate the value of UX during the early stages of a project—such as scoping, initial designs, general requirements, and so on—when there’s the potential for more leeway in the feature set of an online service and more ambiguity around users’ needs. Some activities that can demonstrate value early in the process—and may even alleviate some of your resource constraints further down the track—include the following:

• user interviews or contextual enquiries—Get out of the office and meet some of your prospective users. This is a really low-cost way of rapidly building up an understanding of your users’ needs and their context of use. You’ll also learn in what ways users differ from each other and may uncover some surprises. The best part is that—aside from the cost of your time—it’s largely a free activity. 

• competitor reviews—Help map out the current state of the domain, allowing your team to set better targets. Look at the existing offerings of your competitors to identify the things they do really well and the things they’re failing to do well. Competitor reviews also provide you with a baseline set of features that represent the barrier to entry and can also help to identify opportunities the obvious gaps represent.

• internal stakeholder interviews—If you don’t have direct access to your audience, go and talk to the business stakeholders and ask them about the decision-making process by which they selected and prioritized features. This can help you uncover assumptions that you can test as a project progresses. It can also provide insights into the mental models in operation for the project.

• mud map personas—There’s a good chance you won’t have the time or resources to conduct the in-depth user research you’d need to turn out well-defined audience personas. However, low-fidelity personas that capture all of the information you do know about your audience segments can be valuable as time progresses. While you can flesh out these mud maps as you learn more about your audience, they also serve to demonstrate how little your team currently knows first-hand about your target users.

About Mud Maps

A mud map is a drawing scratched into the dirt. You can use mud maps when there are no other materials at hand and draw them with a stick or boot. Mud maps are low fidelity, but contain the main characteristics of the terrain.

What About Card Sorts?

Conducting a card-sorting exercise early in a project is desirable when the concept space is not well understood. Early on, you’d typically perform an open card sort, which may require more time and resources—for recruitment, implementation, and analysis—than you have.

Although it is possible to design, recruit, conduct, and analyze a card sort in a matter of days, the question remains whether you might spend that time on another task, offering higher impact to the project. However, there are times when nailing the information architecture is the most critical element for the success of a project, and a card sort would be the best use of your time.

What to Deliver?

“The critical features of your project will drive your choice of what elements to detail.”

Although your time may be short, don’t abdicate responsibility for an information architecture to others. Do wireframes, even if you show only some elements in detail. The critical features of your project will drive your choice of what elements to detail. You might spend your time designing the elements that are most important to the success of a project, leave less important elements to the development team, and iterate the design of those less important elements later on, when you have more time. Alternatively, design and test complex elements that it would be costly to redesign and reimplement at later stages in a project.

As Time Goes By

As a project moves out of its early stages and into the implementation cycle, you can start shifting your attention from requirements to refinement. At this stage of a project, useful activities include

• user walkthroughs
• closed card sorts
• usability testing
• definition of metrics

User Walkthroughs

You can do small-scale user walkthroughs of wireframes, a paper prototype, or a stack of screen shots for very little cost. The aim is to generate feedback from real users—or, at least, realistic users—on the design of features at a relatively early stage in a project—that is, before too much development work has taken place.

This activity doesn’t necessarily have to be a big deal. Take a stack of paper printouts to a local cafe and ask people if they’ll walk through a task or two with you, in exchange for a coffee or snack. Don’t take up too much of any one person’s time. It’s better to get several different people to try out a feature or two rather than possibly annoying people by demanding too much of them. They’re trying to relax after all!

Iterate this process if you can.

Closed Card Sorts

“Focus on task failures and look for common mistakes participants make.”

A closed card sort is a little easier to conduct than an open card sort— and, in my opinion, a lot easier to analyze. Using decks of cards representing a site’s structure as you’ve designed it, ask people to find their way to particular low-level pages. You can plan your card sort based on the major user tasks, critical features, or areas of known ambiguity.

You can easily conduct a closed cart sort just about anywhere, and it should take only a few minutes per task. For each task you test, note the path each user takes—that is, the card a user selects at each step—and whether a user successfully located the low-level page.

You can carry out a test like this in a single day, including its setup. Since time is short, focus on task failures and look for common mistakes participants make. Report only such issues, but make the full test results available to your project team. You don’t want to be the bearer of only bad news. Instead say: “A lot of stuff worked well, but here are some things we need to look at changing.”

Usability Testing

Using whatever version of a Web site or application you have available—whether wireframe printouts or a low-fidelity prototype—conduct a more formal usability test, during which you ask each participant to complete all tasks. Although this can be time consuming, a usability test with six participants takes just a few days and can provide valuable insights for your project team.

You can take this opportunity to test your whole design solution. Alternatively, you can concentrate on high-impact features, according to your time, people, and budget constraints.

As a finished Web site or application becomes more tangible, continue doing iterative, small-scale usability testing. There will come a time when you can’t incorporate the findings from your testing into the upcoming release, but your recommendations can form the basis for a subsequent version.

Define Metrics

If you’ve joined a project very late, there may be very little you can do to influence the finished product. However, you can still add value to the project by defining a set of analytics that can help the project team make design decisions during the product lifecycle. So, get the team to record page-completion times for a multi-step transaction process, make sure you get good search logs and reports, and give yourself an opportunity to learn something about how customers are interacting with your site.

Don’t be disheartened if your project team can’t incorporate your changes straight away. Start laying the groundwork for the next iteration of the product or service and stay ahead of the curve if you can.

Summary

“Undertake small, tactical, iterative user research activities throughout the course of the project.”

If you don’t have the resources of a large UX team, with the budgets and timelines to undertake the ideal user-centered design (UCD) or activity-centered design process, you can still make a valuable contribution to a project. Undertake small, tactical, iterative user research activities throughout the course of the project. Focus your efforts on the areas of greatest impact, and produce documentation that your project team can understand and use efficiently.

If you demonstrate value through a series of small, high-impact UX activities, the extra budget, people, and timeline flexibility you need will eventually come your way. Then, you can come closer to implementing your ideal UX process.

I’d like to thank Ruth Ellison, of Stamford Interactive, Daniel Szuc, of Apogee, and Russ Unger, of User Glue, for motivating me to write this column and for their input into the ideas it presents.

Topic: Columns | User Research

via uxmatters.com

Posted via email from Does IT Matters?

10 Heuristics for User Interface Design

Ten Usability Heuristics

by Jakob Nielsen

These are ten general principles for user interface design. They are called "heuristics" because they are more in the nature of rules of thumb than specific usability guidelines.

Visibility of system status

The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.

Match between system and the real world

The system should speak the users' language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order.

User control and freedom

Users often choose system functions by mistake and will need a clearly marked "emergency exit" to leave the unwanted state without having to go through an extended dialogue. Support undo and redo.

Consistency and standards

Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.

Error prevention

Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.

Recognition rather than recall

Minimize the user's memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.

Flexibility and efficiency of use

Accelerators -- unseen by the novice user -- may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.

Aesthetic and minimalist design

Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility.

Help users recognize, diagnose, and recover from errors

Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.

Help and documentation

Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user's task, list concrete steps to be carried out, and not be too large.

via useit.com

Posted via email from Does IT Matters?