Adaptive Path Newsletter for July 15, 2008

Jump to: Adaptive Path News | Selections From Our Blog | What We’re Reading

Confessions From a Team of One

Long ago, when I first started working as user experience designer, my process went something like this:
 
During this time, I had a dirty secret. I didn’t necessarily believe that the designs I was proposing where the best solution to the problem. They were simply the best that I had come up with. And so, to compensate, I focused on shoring up my arguments in the event that someone should question me.

I realize now that what I was experiencing was a common pitfall of designing in isolation. People who work on teams with other designers benefit from the natural exchange and evolution of ideas that happens when you put more than one mind on a problem, and I was missing that.

When I joined the team at Adaptive path, that all changed. Here, I saw designers working together, sketching rapidly and roughly, generating lots of ideas quickly and then mixing and matching them to produce cohesive solution. I soon learned that this way of working has a proud history in design thinking. I also saw that the more I knew about it, the more it changed how I approached creative problem-solving when I was working on my own, without other designers to brainstorm with. Did this mean you can bring the creative benefits of team thinking to a practice of one?

I believe so, and I’d like to share with you some tips and techniques that you can apply easily on your own. These are lightweight tools that anyone can employ in fifteen minutes, thirty minutes, or an hour.

TOOLS FOR BRAINSTORMING

 

The goal of any brainstorming activity is to generate a wide variety of ideas, but I find that I brainstorm most effectively when I’m guided by meaningful constraints. The following activities provide just enough structure to focus brainstorming while keeping options open ended.

Pen and paper (the most important tools you’ll ever have): You’ll find that the ability to draw a quick sketch of what you’re thinking is key to much of what follows. Yes, I know. Sketching can be daunting. When I started at Adaptive Path, I would never have described myself as someone who could sketch. But I saw right away by working with people who could sketch that it brings tremendous benefits. It makes it possible to iterate ideas much more quickly than on a computer. And people really respond to sketches. There’s something about the rawness of the form that seems to signal that this is the time for brainstorming and having fun, which makes sketching a dynamic facilitation tool.

Conceptual models: Conceptual models come in many shapes and sizes. Whatever their form, they can provide a useful structure within which to generate ideas. The key to using conceptual models effectively is to pick a structure that has inherent constraints built in, and then to brainstorm within those constraints. Some examples of conceptual models with good constraints are spectrums, two-by-twos, and the grids. You can see specific examples of these conceptual models and how they’re used in this presentation from the 2008 IA Summit.

Inspiration libraries: No doubt many UX professionals already keep an inspiration library, but I included it here anyway because it is such an essential part of the practice. Inspiration libraries can take many forms. Some people just keep a list of bookmarks. Information Architect Peter Morville stores his collection of search pattern screenshots on Flickr.  For my own inspiration library, I take screenshots of interesting examples as I find them (using the invaluable Firefox plugin ScreenGrab), and then store the images in iPhoto. I always start a new project with a meander through my inspiration library in search of interesting patterns that might apply.

TOOLS FOR WORKING WITH AD HOC TEAMS

 

You may be the sole representative of user experience in your organization, but you’re probably surrounded by people who work in other capacities, and whatever their title, you can enlist their help for group brainstorming and feedback.

Sketchboards: Sketchboards are a simple concept. Starting with a big piece of butcher paper, you tape all your sketches to it, as well as sources of inspiration, and notes about requirements and strategy. Cluster the material into related groupings where possible. The real power of sketchboards becomes apparent once you put them on the wall and share them with others. You’ll find that they give you a way to talk through a lot of different options and even discuss aspects of flow across different parts of the system. Prompted by the sketches in front of them, people become engaged and articulate in talking about the benefits and tradeoffs in various ideas. See Brandon Schauer’s article on sketchboarding for more information.

Open design sessions: Open design sessions are an informal invitation for everyone to come brainstorm and sketch — from your product manager to your senior technologist. No ideas are rejected. The goal is to leverage all the minds in the room to bring different ideas to a problem. Surprising and inventive solutions often come from people who aren’t UX professionals. Your role in the open design session is to be the facilitator, walking around, piping in with feedback or extra ideas when somebody seems stuck, and asking enough questions when people present their ideas for them to be tangible and real enough for you to develop further.

Template based workshops: When you’re working with a group of people who aren’t experienced with free form brainstorming, you can run a template-based workshop with basically the same structure and in the same amount of time as an open design session. Simply come armed with templates that give a little shape and guidance to how to think about the problem. Below are three templates that work well.

• The concept sheet is the most free form template. It simply gives participants space to draw a picture and describe the idea in as much or as little detail as they’d like.
• The design the box template asks participants to design the external packaging as if your entire product offering were to ship in a box. It’s a valuable exercise for articulating the basic “aboutness” of what you are designing – what it is, how you’d promote it, what makes it special. This exercise helps everyone on the team think about what would inspire a buyer to pick it up off the shelf (which is in effect what they’re doing when they visit your site or try out your software).
• The design the experience template is a language-oriented approach to describing the user experience that you’d like for your product. It asks participants to list nouns, verbs, and adjectives for the experience, which then map nicely to objects, functionality, and less tangible experiential qualities that would form the basis of the experience strategy and perhaps connect to brand strategy.

TOOLS FOR PICKING THE BEST IDEAS

Once you’ve done all this brainstorming, and you’ve enlisted the help of the rest of your team, how do you identify which ideas best address the problem at hand? The key is to anchor yourself to a handful of specific, meaningful objectives that this product or release should accomplish, and then to constantly gauge your progress against them. At Adaptive Path, we do this with design criteria, which Sarah Nelson has written about in previous issues of this newsletter. You can read Sarah’s complete essay on design criteria here.

Designs that are based on design criteria and built upon well explored ideas help you craft a product with tangible benefits and a little bit or personality for the people who use it — and they it make it easier for you to do it with confidence and conviction. Whether you work on your own or with a big team, that ultimately is what it’s all about.

A longer version of this article will appear in the forthcoming special information architecture issue of the ASIST Bulletin, to be published in August.

---

---

---

---

---

Jump to: Adaptive Path News | Selections From Our Blog | What We’re Reading

Making Research Actionable:
An Introduction to Design Criteria

What happens when people want a company’s product, but are frustrated by the process of trying to get it? Obviously it should be reworked—but doing so can be easier said than done. When we’re asked to redesign a process, we often start by exploring the problem space with in-context research, which generates a large amount of data. That data tends to point teams in the direction of a number of possible solutions. But how should the team decide which direction is the right one? In such cases, I’ve found that Design Criteria—a set of rules a design team can follow—can be a key tool so when a design team creates or reworks a service or product, everything it does supports the user.

Rooted in Research

How do we draw up Design Criteria, and how can they help our clients?  Let’s look at the case of a small company I’ve been working with. The company knew that users had difficulty dealing with its website, wanted to help them, and could explain some of the problems they were experiencing. It also knew that because its business is complex, one key problem couldn’t be solved: users need to devote a fair amount of time to setting up an account. But it didn’t think this problem explained its failure to turn so many prospects into customers.

We suspected that in dealing with account setup, people were having problems that hadn’t been revealed by the company’s site metrics or usability tests. So we launched an extensive in-context research study, mental model, and persona development exercise. We found that users rarely knew what to expect from the process, which constantly surprised them, particular with requests for new information. Often, they had to stop work to get this info. Users also consistently underestimated how long the process would take. Even two to three hours into setup, many said the whole process should take “about an hour.” A number either quit before they’d finished, or grew increasingly frustrated, sticking with it only because they felt they had no choice.

The client can’t do much to solve certain problems inherent in the setup process. Users have to retrieve information from their personal files and badly designed government web sites, and make decisions based on confusing tax laws. And users vary widely in their ability to deal with these obstacles, as well as with the site itself. We had to minimize the effect of all these factors, to make setup easier and quicker for everyone.

Enter Design Criteria

Project goals, success metrics, brand and mission statements, and universal design principles are all useful in their own way. But in improving specific experiences, Design Criteria can play the critical role, because they’re research-based, and tailored to each project.

There’s an art to drawing them up. They should give a design team clear direction, while leaving it room to explore different approaches to each problem. And they have to be clear and concise, but neither so reductive that they’re open to broad interpretation, or so abstract that they don’t suggest concrete solutions.

Let’s look at a key pain point for my client’s customers: information gathering. We knew that no matter what, they’d need to rely on a number of sources, and some information would need to come from other people. We could help them store and organize it once they had it, but couldn’t help them collect it. 

What Design Criterion would help us make this process less difficult? We could have gone with something abstract and general—say, “Make information gathering easy.” But what’s “easy” in this context?  And could we really make this process “easy?”  We needed something more specific, pointing the way toward a viable solution.

We might have chosen “Tell customers upfront exactly what they’ll need.” But checklists didn’t seem like they’d be much help. So we settled on “Find Efficiencies.” Working with this directive, the team looked at various stages of setup, and asked, “In this context, what does it mean to be efficient?” The next step was drawing up “dimensions of efficiency,” such as streamlining data entry, asking at the same time for information that’s taken from the same source, or entered in the same place on a form, and presenting tasks in groups, to make them more manageable. Following on this, team members asked more questions, such as, “How do we make data entry efficient? Can we provide access to electronic versions of necessary government forms, for example, and batch-upload entered data, rather than asking users to transfer it manually from forms to the system?” As we asked these questions, we built a base of ideas for creating workable, powerful solutions to the problems plaguing setup.

Generating Design Criteria

For most projects, I like to use five to seven Design Criteria. Too many, and the team can’t remember them all; too few, and they won’t cover all the problems at hand. Rather than draw them all up at once, at the beginning of the design process, I tend to keep a running list of ideas as I work, making particular note of anything that jumps out at me as I look at the results of user research. At the end of the research phase, I put together the final Criteria, drawing some from my notes, and supplementing them as need be. Often our design team plays a key role in fleshing out the list.

A starter list might look like this:

• Ask customers for what they have, rather than asking them for what the company needs.
• Allow customers to say they “don’t know.”
• Provide a consistent experience, from interaction and visual design to copy.
• Be clear about what the system can do, and what the client is responsible for.
• Be friendly and reassuring.
• Show customers where they’ve been, and where they’re going.
• Allow graceful recovery from unexpected interruptions.
• Make it easy for customers who need to gather critical information to pick up where they left off.
• Set clear expectations.

Here’s where the art comes in. I’ll sort the list, identifying items that can be combined or are thematically related. Once I have five to seven that are both unique and specific to the project, I refine the wording. I look for statements that are short and memorable. The statements should both help team members focus, and inspire them to generate ideas. Then I test each draft Criterion by asking myself:

• Am I inspired by this? Can I think of ways to translate it into real-life solutions?
• Does this challenge me to ask useful questions?
• When I show this to someone else, can they understand it easily?

When sharing Design Criteria with clients or those outside the team, I like to support each one with a powerful quote from user research, as well as examples from the Web and elsewhere, showing solutions that embody it. These supporting materials serve as a source of inspiration, and a starting point for further discussion.

Using Design Criteria Throughout the Design Process

I’ve talked about Design Criteria mostly as a source for generating ideas early in the design process. But they can be used throughout that process, to support communication, evaluate concepts, and quickly bring new team members up to speed. Keeping them short, memorable, and directive will give your team a great foundation on which to build elegant, powerful designs, then help them do so, from start to finish.

---

---

---

• YouTube: Video of Paper Prototype
• The Atlantic.com: Is Google Making Us Stupid?
• Data Visualization by Chris Harrison: An Amazon Book Map
• Back of The Napkin: Solving Problems and Selling Ideas with Pictures

Your email address: