Please tell us what you think of this issue!  Feedback

Bulletin, August/September 2008

How to Be a User Experience Team of One

by Leah Buley

Leah Buley is an experience designer for Adaptive Path. She writes online at and She can be reached at leah<at>

As information architects we tend not to think of ourselves as designers. Library and information science programs, from which many information architects (IAs) hail, do not typically emphasize design methods. And the demands of our day-to-day activities reinforce this focus. Tactical IA, usability testing, content generation and management, database design, user research – these things rank highly in the list of common IA responsibilities; design, not so much [1].

And yet, it’s the design layer that users perceive most directly as the product. Naturally this layer includes the visual design system, but it also includes the moment-to-moment experiences and the blend of information and functionality that IAs are responsible for crafting through wireframes, task flows and storyboards. While many inputs will inform what an IA designs, working out the right navigation, content and functionality ultimately comes from the IA’s own intuition and aesthetics – the timeworn tools of any designer.

Design and the Solo Practitioner
People who work on teams with other user experience (UX) professionals have an advantage here. They benefit from the natural exchange and evolution of ideas that just seems to happen when you put more than one mind on a problem. Solo IAs are not so lucky. Often they must produce creative solutions without the benefit of a team, and that necessity can make their work challenging. Or at least, that was my experience when I first started working as a solo user experience professional in a large organization. In that role, my design process (Figure 1) went something like this:

Figure 1. Design process as a solo user experience professional

My dirty secret throughout this process was that I didn’t necessarily believe that the designs I was proposing were 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 didn’t realize how different the process of designing could be until I left my position and joined a team of user experience (UX) professionals at Adaptive Path, a user experience strategy and design firm. There, I saw a version of designing that looked very different, usually involving multiple designers working together to come up with as many ideas as quickly as possible. I saw that this method of working – collaborating with others, sketching rapidly and roughly – made it possible to generate a remarkable volume and variety of ideas very quickly, which could then be mixed and matched, taking little gems from smaller ideas to produce combinations that functioned nicely as a cohesive solution. This situation was my first exposure to this way of working, but I soon discovered that it had long been a mainstay of design thinking [2].

In this approach the creative process starts with divergence and ends with convergence. Divergence is focused on generating as many ideas as possible, and convergence is focused on refining those ideas. In divergence, you unburden yourself of the need to critique or to be practical and simply invite as many ideas as possible. In convergence, you restrict yourself from further brainstorming and focus instead on refining the ideas that you already have, iterating and evolving the best ones. Throughout all of this, ideas are captured as low fidelity sketches (Figure 2:). Taking the time to polish concepts that may be absorbed into better ones simply isn't efficient. The goal here is to record ideas with the minimum level of effort and at the lowest fidelity necessary to communicate whatever is most compelling about them.

Figure 2. Example of a sketch (

Once I’d learned a bit more about this way of working, a surprising thing happened. I found that I was changing the way I approached creative problem solving even when I was working on my own. Did this mean that these design techniques could be used to 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 techniques are lightweight tools that anyone can employ in 15 minutes, 30 minutes or an hour as needed.

Tools for the Team of One
The tools that I have found particularly effective are pen and paper; brainstorming; and assembling an ad hoc team to help.

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.

The beauty of sketches is that they don’t have to be perfect. They don’t even have to look good. They only have to be meaningful enough to convey the essence of the idea. If you would like to learn more about sketching and follow some of the same steps that I did to further my own sketching skills, please see the list of resources at the end of this article. And, as in so many things in life, you get better when you practice, so just get started.

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. I have found that the following activities provide just enough structure to focus brainstorming while keeping options open ended:

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. 

Spectrums simply take one attribute of a design and plot it on a continuum (say, familiarity of use with the product, from first time to expert) (Figure 3). The brainstorming happens when you work on dreaming up ideas for designs at various points along the continuum.

Figure 3. Spectrum model (

Two-by-twos are basically just one spectrum on top of another, with some added interest in the overlapping dimensions (Figure 4). Whereas in a spectrum you’d brainstorm along the continuum, here you brainstorm within each quadrant.

Figure 4. 2 x 2 model (

Grids (Figure 5) simply add more spectrums and more overlap. You can experiment with points along a continuum, as you would in a spectrum or explore different ideas that are less connected to each other.

Figure 5. Grids (

• Word games. Consciously or otherwise, we often use language to evoke ideas about what type of product we're designing. Words that we use every day without much thought have very specific interface and experience implications. You can use these visual associations to come up with surprising new ideas by combining things that don't naturally go together. Pattern libraries such as and the Yahoo! Pattern Library are great resources for words or patterns to start mixing and matching.

• Inspiration libraries. No doubt many information architects already keep an inspiration library, but I include 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 [3]. 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.

Assembling an Ad Hoc Team. 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 (Figure 6). 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 will find that they gave 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 [4]. 

Figure 6. Sketchboard (

• Open-design sessions. Open-design sessions are an informal invitation for everyone – from product manager to senior technologist – to brainstorm and sketch. 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 freeform 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. Here are three templates that I've used to good effect. 

The concept sheet (Figure 7) is the most freeform 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.

Figure 7. Concept sheet (

The design-the-box template {Figure 8) 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, 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).

Figure 8. Box template (

The design the experience template (Figure 9) 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.

Figure 9. Experience template (

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 call this anchor having a star to sail your ship by. As you make your way across what can sometimes feel like a vast ocean, you constantly realign your little ship to that star. 

Business requirements have for many years been the star for projects that IAs work on. But organizations are beginning to appreciate that simply meeting business requirements is not enough if the product itself is not compelling to users, and so our goals as user experience professionals have evolved. Our mandate now is to create products and services that create differentiated experiences and that people can have a meaningful relationship with.

How do we do this? This is where your final and most powerful tool comes into play: design principles. Design principles are a handful of short statements about what the experience of using your product will be like. They are informed by business requirements and user goals, but ultimately design principles are something different. They are meaningful, directed, catchy statements that are unique to the product. Most projects have about five design principles, give or take a few. 

Here are some examples:

Figure 10. Design principles (

You can see how these statements are more specific than general rules of thumb like “easy to use” and have a distinctness that probably makes them different from what your competitor’s design principles would be if they had them. 

Different design principles create different experiences. Once you articulate your design principles, you’ll find that many of the ideas that were generated through brainstorming fall away, and you’re left with a much smaller handful of options that point the way to a focused experience.

So how do you get started? It’s easy. Sit down and draft some design principles. It’s great if you can develop them with your stakeholders, but even if you can’t, just do them for yourself. 

Designs that are based on design principles and built upon well-explored ideas help you craft a product with tangible benefits and a little bit of personality for the people who use it – and they it make it easier for you to do the job with confidence and conviction. Whether you call yourself an IA or a designer or something else entirely, such mastery ultimately is what it’s all about.

Resources for Sketching 
Anything from the Grove International (, especially including the following:

Sibbet, D. (1993). Fundamentals of graphic language. San Francisco, CA: Grove Consultants International.

Sibbet, D. (2006). Graphic facilitation: Transforming group process with the power of visual listening. San Francisco, CA: Grove Consultants International.

Grove public workshops. Calendar retrieved June 9, 2008, from

Buxton, B. (2007). Sketching user experiences: Getting the design right and the right design. Redmond, WA: Microsoft Research.

Edwards, B. (1999). The new drawing on the right side of the brain. (2nd rev. ed.). New York: Jeremy P. Tarcher/Putnam. 

Hanks, K., & Belliston, L. (2006). Rapid viz: A new method for the rapid visualization of ideas. (3rd ed.). Boston: Thomson Course Technology PTR. 

Taking any class with a technical drawing component, such as interior design, architecture or drafting. I took this class:

Last but not least, keep a sketchbook and force yourself to draw one sketch every day.

Resources Mentioned in this Article
[1] Information Architecture Institute. (2007, November 3). Salary survey, 2007. Retrieved May 13, 2008, from

[2] Jones, J.C. (1992). Design methods. (2nd ed.). New York: Wiley-Interscience. 

[3] Morville, P. (200?). Search patterns. Retrieved May 28, 2008, from

[4] Schauer, B. Sketchboards: Discover better + faster UX solutions. Retrieved May 28, 2008, from