Sketchy Wireframes

Written by: Aaron T. Travis


When it comes to user interface documentation, wireframes have long been the tool of choice. However, using traditional diagramming tools like Visio, OmniGraffle, and InDesign, most wireframes today look the same as their ancestors did from a decade ago – assembled with rigid, computer-drawn boxes, lines and text. While these artifacts have served us well, they can also be slow to produce, burdened with unnecessary detail and give a false impression of “completion.”

To compensate for the drawbacks of traditional wireframes, many practitioners put aside the computer in favor of simple pencil sketches or whiteboard drawings. This speeds up the ideation process, but doesn’t always produce presentable or maintainable documentation.

There is a growing popularity toward something in the middle: Computer-based sketchy wireframes. These allow computer wireframes to look more like quick, hand-drawn sketches while retaining the reusability and polish that we expect from digital artifacts.

The same wireframe in sketchy and traditional representation.
The same wireframe in sketchy and traditional representation.

The Traditional Wireframe Problem

Throughout a project lifecycle, wireframes can be used for different purposes depending on the stage. In the early stage, wireframes act as a tool for exploration and concept development, when sweeping changes are expected and encouraged. As the project continues, parts of the wireframe begin to be “locked down” as functionality is reviewed and “signed-off.” During this process, wireframes can become a confusing hybrid of conceptual ideas and finalized functionality. By the end of the process, wireframes can turn into a highly detailed functional specifications document.

The problem here is that traditional computer wireframing tools, like Visio, OmniGraffle or InDesign, lay out drawings as hard-lined boxes, lines and fonts. As a result, wireframes look the same regardless of which stage of completion the wireframe is representing. Early-stage, conceptual wireframes look identical to late-stage, functional specifications. This differentiation becomes especially murky in the middle of the project, where conceptual and final elements are comingled on the same page.

Sketching to the rescue?

To compensate for the drawbacks of traditional wireframing, some designers ditch the computer in favor of hand sketching. An informal poll by (as of 8/24/09) showed 22% of respondents identifying sketching as their primary tool for wireframing. Hand-sketching of wireframes, proponents argue, allows for faster expression of ideas and freedom from artificial confines of diagramming software. Sketches don’t require the same level of detail, and can be produced faster than traditional computer-based wireframes, allowing for a more iterative design process.

Why not sketch…

If hand-sketching has so many advantages over computer-based tools, why don’t we all ditch our mouse pads for sketch pads? There are four major reasons:

  • Drawing ability – Wireframes are essentially presentation tools, and not everyone may feel that their drawing skills are “presentable.” In team environments, there can be a wide range of drawing skill levels… from the “can’t draw a straight line” people to the “can’t put down their sketchbook” people. This leaves a disparity in the quality of sketched deliverables produced by the team. Many organizations feel it’s best to standardize their deliverables by forcing everyone to use the same tool.

  • Perception – When people become accustomed to seeing fully fleshed-out wireframes, introducing sketchy may be a challenge. Some may see the architect as suddenly becoming “sloppy” or “lazy.” In these cases, it is critical to sell the benefits of sketchy wireframes to stakeholders and opinion leaders.

  • In situations where wireframes are intended to live past the initial concept stage and turn into functional specifications documents or user guides, hand-sketching is not the most appropriate method. Hand-drawn sketches give the wrong impression of flexibility at later stages of development when the interface has already been “locked down.”

  • Reusability – Hand drawing is great for getting ideas down quickly. However, when wireframe documentation is lengthier than a couple of pages or when the documents must be re-worked over a long period, sketching loses its speed advantage and becomes a burden. In an electronic medium, changes can be made across pages and documents very quickly.

  • Prototype flexibility –Many practitioners prefer to go directly from hand-drawn wireframes to interactive prototypes, bypassing the more traditional wireframe process. However, in many situations, wireframes are used to generate interactive prototypes for proof of concept and/or usability testing. Hand-sketched wireframes are excellent for paper prototyping, but the amount of work involved increases quickly if they need to be scanned into the computer and converted into interactive prototypes. For on-screen prototypes, it is much easier to start with wireframes that are already in an electronic format.

Enter the computer-generated sketch

To compensate for the problems of both traditional and hand-sketched wireframes, certain programs allow you to create the look of hand-sketching with no drawing ability required, while retaining all of the benefits of a digital tool:

  • The style gives the impression of a work-in-progress, yet still retains a “polished” feeling that aids in acceptance by the workplace
  • Components are easily reusable for longer documents
  • Wireframes can be re-purposed for interactive prototyping

Sketchy Wireframes in Action

I discovered the need for computer-based sketchy wireframes while working on the website redesign of a well-known print media brand. I found myself presenting wireframes to executives, who would critique them in the same manner that they would a print-spread: with a heavy focus on fonts, text placements and graphic treatments. Despite frequent disclaimers that the wireframes were for high-level discussion purposes only, each presentation would drift into fixations of irrelevant details. To accommodate them, I found myself spending countless hours polishing the wireframes to look beautiful, when I should have been spending time on concept development and user testing.

To make matters worse, as we removed features from the wireframes that were determined to be “out of scope,” we continued to receive requests to bring them back, right up until the end of the project. Clearly, the wireframes were not helping to convey the right message.

On the next project, I generated the conceptual-stage wireframes using sketchy Visio stencils created by Niklas Wolkert. I began all of my wireframe presentations with an explanation of why the wireframes looked like sketches: they were intended to be malleable, rough outlines. I also prepared the executives for the next phase by telling them that the sketchy look of the wireframes would be removed as decisions became “finalized.”

Comparison of the sketchy wireframe stencils by Niklas Wolkert (right) and traditional ones by Henrik Olsen (left) at Image credit: Henrik Olsen.
Caption: Comparison of the sketchy wireframe stencils by Niklas Wolkert (right) and traditional ones by Henrik Olsen (left) at Image credit: Henrik Olsen.

The improvement in the executives’ perception of the process was immediate. The boxes and lines of the wireframe no longer had to look perfect, and the hand-drawn fonts couldn’t possibly have been mistaken for an intentional design. The executives, feeling less compelled to fix the visuals, were free to talk at a high-level about architecture and strategy. As the project transitioned from concept to execution, I removed out-of-scope features and converted the style from sketchy to traditional. This virtually eliminated later-stage requests for functionality that had previously been removed.

The reaction to computer-based sketches

Having used computer-based sketchy wireframes on a number of projects, I’ve found many ways that they can decrease confusion with teams and stakeholders:

  • Clients and Executives – People in this group typically want to push projects forward as quickly as possible. Consequently, the more “finished” the wireframes look, the faster they will expect to see the finished product. You can do yourself a disservice by making your wireframes look more complete than they are. To quote Kathy Sierra, “How ‘done’ something looks should match how ‘done’ something is.”

  • Programmers – Programmers who see traditional wireframes too early in the process may misinterpret their functionality as “signed-off.” Don’t be shocked if you hear frantic questions like “Did we agree to this?” Programming requires meticulous attention to detail, so programmers read wireframes with an eagle eye. Consequently, they may expect a level of specification from wireframes that isn’t appropriate in the early stages.

  • Designers – Designers make their living with their visual creativity, and they resist anything that could constrain it. Consequently, in situations where designers must work with wireframes created by someone else, designers can perceive them as a creative straightjacket, or worse, as a threat. A sketchy representation can help reduce friction by removing unnecessary details and adding a certain amount of “fuzziness” to the wireframes, thereby giving designers more leeway in interpreting the look and feel of the interface.

  • Users – In my research, I’ve found that users who are asked to comment on traditional wireframes can be intimidated by an overly finished look and feel. This is mirrored by a general consensus in the usability industry that the “less done” a demo looks, the more comfortable users feel with giving feedback. Where traditional wireframes can elicit comments like “I don’t like the font on those words,” sketchy wireframes are more likely to elicit comments like “I don’t know what those words mean.”

Computer-Based Sketchy Tools

There are now a number of programs that are capable of generating computer-based sketchy wireframes. However, in working with them, I’ve found that many of them are missing what I have identified as four essential capabilities necessary to be considered a “complete” sketchy wireframing tool:

  1. Ability to Draw New Sketchy Shapes –
    These days, many components of user interfaces are standardized into stencils that can be dropped onto wireframes to build them out quickly. While this can be a real time saver, not all UI problems can be solved with prepackaged stencils. In fact, one could argue that the best use of wireframes is to illustrate new concepts that have not become standardized. Many tools use pre-built, sketchy-looking stencils to allow designers to create sketchy wireframes. However, at some point you will need to create new shapes that aren’t available in your set, and a true sketchy tool must enable you to create new ones in the same sketchy style.

  2. A sketchy tool should allow you to draw.  These were created in Visio using custom line styles. This tutorial tells you how.
    A sketchy tool should allow you to draw. These were created in Visio using custom line styles. This tutorial tells you how.

  3. Easy Conversion from Sketchy to Traditional Style –
    Sketchy wireframes are a great tool for encouraging creativity, exploration, and collaboration. However, at some point, your blue-sky, creative ideas fall away and you are left with what you are actually going to build. In environments where wireframes morph into spec documents and user guides, those rough lines and hand drawn fonts must be converted to a more finished, traditional style to avoid the impression that your technical documentation is still changeable.

    Does this mean you have to go back and re-draw all of your sketchy wireframes with straight lines? Not if you can avoid it. Fortunately, certain programs allow you to convert your existing sketchy lines and fonts to traditional style without having to recreate them.

    Some software automatically converts from sketchy to traditional lines.
    Some software automatically converts from sketchy to traditional lines.

  4. Realistic Lines –
    It’s always been difficult to approximate the look and feel of true hand-drawings using software tools, but some do it better than others. The quality of drawings generated by a computer-based sketchy tool could have an impact on whether the wireframes are perceived as “conceptual” or just plain “sloppy.” These are the 3 major components needed to completely represent hand-drawn styles in wireframes:

    • Wavy Lines – No human can match the rigidity of a computer’s lines. Adding waviness and movement to lines humanizes them.
    • Varying Line Weights – When drawing conceptual wireframes, there are often areas of the screen that have yet to be explored. One way to represent this is to fade out lines as they enter these areas.
    • Smudging and smearing – These effects help to reduce focus on unimportant areas of the wireframe.

    These lines, created in Fireworks with a graphite line texture, could hardly be mistaken for true hand-sketches.
    These lines, created in Fireworks with a graphite line texture, could hardly be mistaken for true hand-sketches.

    These lines, created in Illustrator, are much closer approximations of true sketching.
    These lines, created in Illustrator, are much closer approximations of true sketching.

  5. Prototype Flexibility – For those who prototype their products, speed and efficiency of workflow is a critical issue. In this case, the benefits of creating a sketchy look and feel will become irrelevant if doing so increases the time needed to create prototypes. Fortunately, some tools allow themselves to slip naturally into the process by generating interactive prototypes that maintain the sketchy look and feel.

  6. In interactive sketchy prototype created in Visio and imported into Axure.
    In interactive sketchy prototype created in Visio and imported into Axure.

Comparison of Computer Based Sketchy Tools

Software developers are starting to recognize the importance of computer-based sketchy wireframes, and there is a growing assortment of tools to create them. This is a quick breakdown of how each of the major tools matches our criteria for a complete computer-based sketchy tool:


Draw Shapes

Easy Conversion

Realistic Lines

Prototype Flexibility











Expression Blend 3





Fore UI



































None = No Support
Partial = Partial Support
Full = Full Support
  1. Assumes prototype flexibility using a 3rd party program called Napkee
  2. Assumes use of custom line styles, as demonstrated in this tutorial


As the industry evolves, there is a growing trend toward hand-drawn styles, as evidenced by an expanding amount of literature and workshops on the subject. This is a positive step in the evolution of our field. Sketchy wireframes allow practitioners to guide creativity and problem solving in the early stages of projects, rather than getting lost in a sea of documentation. Hopefully, this trend will continue as software manufacturers focus on enhancing their tools for creating computer-based sketchy wireframes.

What design researchers can learn from hostage negotiators

Written by: Bryan McClain

It’s 2 a.m., and a call comes across the radio that a young man with a gun has barricaded himself and his mother in his home. No shots have been fired, and little communication has been established between the man and police officers outside. The officers on the scene report that the young man has been struggling with the loss of his job and feels like there’s no reason to live. The crisis response team has been called, and hostage negotiators are en route. It’s the negotiator’s job to ensure that the young man does not harm himself or others during this crisis.

What would you do? How would you handle this situation?

Throughout the past six years, the founders of ActiveComm Labs have not only been performing design research but also assisting the law enforcement community by conducting research on the communication patterns of hostage negotiators. Specifically, we have been analyzing the communication between the hostage negotiator and hostage taker to locate patterns that could introduce new strategies to help resolve crisis situations peacefully.

We’ve come to realize that the techniques used by hostage negotiators to resolve crises are also extremely valuable to user experience researchers. In essence, both parties are attempting to establish a relationship, both are trying to keep the communication flowing, and most importantly, both are trying to extract valuable data.

There are certain myths about hostage takers. Most of them are not bank robbers or terrorists demanding millions of dollars and a plane to Cuba. The vast majority of hostage situations are a result of domestic violence, psychological disorder, or barricade situations in which a person is threatening to commit suicide, possibly with a child in the next room. Hostage takers are usually confused, upset, and very scared. It’s also pretty rare for them to be outright hostile toward the negotiator. Hostage negotiators are trained to gather important data about the situation. Who’s in there? Is anyone hurt? What kind of weapons does the hostage taker have? How much ammo does he have? To do this, negotiators have to master a variety of communication techniques.

Have you ever worked with a research participant who will only give you “yes and no” answers? How about a participant who tells you exactly what you want to hear? These situations can be frustrating, especially when you invest so much time and energy in recruiting candidates. But these experiences don’t necessarily mean that these people can’t provide valuable data, it means that you need a different approach to extract that information.

A research session isn’t usually an emotionally charged situation and research participants aren’t typically in crisis, but the fundamentals of communication tend to hold true across different types of people and contexts. Our negotiation instructor told us that we should approach a hostage negotiation in much the same way as going on a first date; it’s important to bring a certain level of calm into the situation and put the hostage taker at ease. It is also extremely important to connect with the hostage taker on a personal level. Negotiation provides a great example of how to perform this kind of communication because it demonstrates these fundamental communication elements under the most difficult of conditions. Ultimately, negotiation is about two strangers coming together to work toward a common goal built on an understanding of each other, much like design research.

Application to Design Research

There are two types of behavior that we try to extract when conducting research:

  1. What the participant does (physical interaction with product)
  2. What he or she says (communication about the product)

Our goal is then to study the interaction between these behaviors in order to tell a story about the user’s experience of the product.

One of the most difficult parts of research is getting the participants to tell us their story about the product. Some researchers only focus on physical interaction data, but we think too much valuable content is lost. We’ve found that the communication piece of the equation provides the emotional and logical connection that participants make with products and how it relates to their lives.

With that said, one of the most common issues with communication-related data is how to gather accurate information. What a participant says is not always what he or she believes, and what a participant does is not always what the participant reports.

Much like a hostage negotiator, who must build trust in order to successfully resolve the crisis, a user experience researcher must establish a relationship with the participant in order to extract useful and accurate information. So, the fundamental element of becoming a better communicator, and also researcher, is to establish a relationship. Hostage negotiators focus on establishing relationships in order to save lives, there’s much we can learn from the methods that they have established.

Learning from Negotiators

Dominick J. Misino is a retired NYPD crisis negotiator who has been involved in more than 200 hostage and barricade incidents. He is recognized for his successful resolution of the Lufthansa hijacking in 1993 and numerous other successful negotiations. When it comes to communicating, Dominick knows what he’s doing. Since retiring, Dominick began training other hostage negotiators. To date, he’s trained thousands of negotiators across the country and around the world. A few years ago, we had the privilege to attend all three phases of Dominick’s negotiator training and certification program, which included hands-on practice as a negotiator and hostage taker. We learned communication techniques that we currently employ when interacting with research participants. These techniques include building rapport, building alliances, and using a team approach.

Building Rapport

Rapport is established through trust, open communication and empathy. Negotiators know that rapport is essential in their job. They use rapport to influence the hostage taker and gather information. If you can effectively build rapport with the participant, there is a higher likelihood he or she will trust you and disclose more information.

The following techniques used by hostage negotiators can help you build rapport with research participants:

  1. Go slow – Engage in small talk at first. If you dive right into business, the situation can become uncomfortable.
  2. Communicate openly – While you can’t disclose everything, it’s important to encourage an atmosphere of open communication. Tell the participant that there are certain aspects of the study that you can’t reveal, but he or she shouldn’t feel that you’re hiding something.
  3. Actively listen – When you are listening to a participant’s story, listen for the emotions behind the words. Ask open-ended questions that dig for the source of those emotions.
  4. Discuss personal topics – In a hostage situation, some of the most valuable topics that lead to a peaceful resolution are personal ones. The more a person feels that you accept them, the more comfortable they will feel with you.
  5. Share your experiences – Building rapport is as much about sharing your experiences as it is about listening to the other person’s. Negotiators know that the more you reveal about yourself, the more the participant feels like he or she knows you and therefore trusts you.
  6. Show you care – Hostage negotiators build rapport through empathy. Empathy is extremely important because it shows that you care about the other person and that you have their best interests in mind. As a researcher, you should do this also. If you show that you care, the participant will appreciate it and respond with more openness.


In a hostage situation, the negotiator works for the police department but he has to show the hostage taker that he’s on his side. In order to do this, the negotiator can never be the one in charge; it cripples his or her ability to negotiate. Anytime the negotiator has to tell the hostage taker “no” it’s because his boss is being a jerk. Anytime the negotiator says “yes,” whether it’s a pack of cigarettes or just some extra time, it’s because the negotiator fought hard to get it for him. The negotiator intentionally shifts the blame for anything negative and takes credit for anything positive. It convinces the hostage taker that the negotiator is on his side.

In user experience research, the researcher is on the side of the user. In our work, we establish this by telling the participant that we are not the people who designed the product and that their comments, whether good or bad, will not offend us. This establishes objectivity and allows a certain freedom in the research session. In most cases, participants open up when they hear that you have nothing at stake. Also, if the participant can see that you share his or her common goal of improving the product, the participant is more likely to be truthful in his or her evaluation.

Team Approach

Hostage negotiators always work in teams, and so should you. In the event of a hostage situation, a negotiation team is called to manage the situation. Each person in that team holds a different but critical role in the event. One of the most important positions on that team is the coach. As the negotiator acts as the primary point of contact with the hostage taker, the coach sits with the negotiator and functions as another pair of ears. The communication can move very quickly during a negotiation, and the negotiator can have a hard time catching all of it. The coach specializes in listening, controlling access to the negotiator, generating questions and helping guide the communication process by passing notes to the hostage negotiator. Through crisis negotiation training, my partner and I have learned that the ability to gather useful and accurate information dramatically increases when you work in teams. For example, when conducting an expert interview we have one person ask the questions and another person as a secondary moderator. Like the coach in negotiation, the secondary moderator listens closely, takes detailed notes and chimes in when he feels that something is being missed. This type of setup will reap maximum data in the shortest amount of time. We can’t always work in teams for logistic or financial reasons, but it is our preferred method.


For hostage negotiators, training is a crucial part of the job and they understand that the more you train, the more comfortable you will feel in the situation and in turn the better the outcome.

From what I have seen in the user experience community, little or no time is spent training on the best practices of communicating with participants. Every so often a workshop is attended but that only happens a few times a year. If we take a page from the book of negotiating, we would learn that just a little bit of training on a regular basis will take us to a whole new level of success. Here are some modified exercises that we can use to polish our communication skills as researchers:

  1. Communicate with new people all the time – every time you have a chance to meet someone new and learn about their life, do it. Ask questions about who they are, where they come from and what they’re like. When you start to feel more comfortable doing this, start pushing yourself and asking more intimate questions about their life such as “What keeps you up at night?” Play a little game with yourself where you try to learn as much as you can about a person in a short amount of time. Three things will happen when you do this. First, you will learn about boundaries and what you can ask and you should not ask. This doesn’t mean that you’ll necessarily insult people and then learn not to do it; it means that you will see what topics are challenging to people and how to pull that information out of them without upsetting them. You’ll also learn more about people in general and how they function in the world. You’ll get a better sense of behavior and start to see trends in people. Finally, you will make more friends in the process and that is always a nice outcome.
  2. Learn to listen – A well-known question asks, “When someone is speaking to you, do you think about what they are saying or do you think about what you are going to say next?” This is a very important question when learning to communicate more effectively with others. When you are communicating with participants or friends, really listen to what they are saying. Listen to the emotions behind the words, look at body language, and ask questions about their responses if they are unclear. There are sometimes differences between what a user will answer and what they believe. Ask yourself what those statements say about the speaker as a person; it will enable you to discover the areas where people are most passionate.
  3. Learn how to disclose – When talking with friends and new people, start disclosing about your life and observe how people respond. Most people will feel more comfortable sharing information if you share information also. You’ll be amazed at how quickly people will open up.
  4. Learn to trust your gut – When working with a participant or talking with a friend, learn to listen to your instincts. There are times when you need to speak up, times when you need to bring the communication back on track and times when you need to let the other person just open up and talk about whatever they feel is important. Different types of communication are needed for different situations. If you train frequently, you will notice that your gut tells you what you need to do.


This article began with a scenario of a hostage situation. After the first 30 minutes, the hostage taker and negotiator were talking like old friends about food, sports, and pets. At two hours, the hostage taker confided in the negotiator about his relationship problems and issues that led to him losing his job. At two and a half hours, the young man sent his mother out of the house, despite her protests that she wanted to stay with her son. At four hours, the young man placed his empty gun in a bucket attached to a rope outside an open window, where it was retrieved by the police tactical team. At 7:50am, after five hours and fifty minutes of negotiation, the young man peacefully exited his home and surrendered to police. The negotiator followed up on all of his promises. He rode with the young man to the police station, allowed his mother to visit so that he could apologize and even made a statement on the young man’s behalf at his trial, resulting in a reduced sentence.

This process should be mirrored in a research session in a condensed period of time. After the first ten or fifteen minutes, the participant should feel like you know each other and feel pretty comfortable talking with you about your product or service. After about twenty minutes, the participant should understand the product and its goals. After thirty minutes, the participant should be discussing how the product would fit into his or her life. In order to achieve this, some form of communication training should be implemented. Researchers typically receive a great deal of training in research methods, statistics, human factors and elements of design, but little training on advanced communication. Researchers who really want to invest into their skills as a researcher should think about spending time and energy to learn effective communication methods.

Experience Themes

Written by: Cindy Chastain

There’s an old adage among screenwriters that when a writer can sum up a story in a sentence or less, he has discovered what’s important about the story. He’ll know what the story is about and therefore have a strong sense of theme. And in knowing the theme, he’ll have a compass to use in the process of “designing” the damn thing (i.e. what to keep, what to lose, what actually happens at the end). The story will be all the better for it because it all hangs together with a central idea that will give it greater impact and meaning.

Now wouldn’t it be nice if we had something like that for user experience design?

This article is about a method drawn from storytelling that can help us build a better story about our product, unify teams, inspire design concepts and get us closer to evoking the pleasure, emotion and meaning of the experience we intend to deliver to users through the products and services we design.

So, What’s the Problem Anyway?

As designers, we spend a lot of time examining design solutions against an array of information–business goals, user needs, design principles, best practices, the results of usability tests–but less often (if at all) against a definition of the core experience we hope to deliver. If you’re not sure what I mean, think about this:

We had a big problem at our company. The problem was that the websites we were designing and building were coming together like potluck meals made by a loose confederation of team members and stakeholders who were all working out their dishes independently, and on their own terms.

You know the story: User experience brings the structural framework and behaviors of the interface; creative brings the visual design; client marketing brings the copy; business brings content; our engineering folks were sometimes bringing error messages. When each of these more tangible elements are cooked up in separate quarters without a shared vision or intent how can we possibly deliver an optimal experience, let alone agree on what that experience should be? It’s not that the meal is bad–it often makes a lot of people very happy–it just seemed that we were missing out on a chance to serve up something better, something that would distinguish itself as a dining experience people would remember in a marketplace of potluck dinners.

Coming from a filmmaking background where it’s a matter of course to see an army of people with specialized roles focus their efforts around bringing the story of the “project” to life, it often seemed as if our practice as UX designers neglected an important approach. On a film set, bringing a project to life involves having a very clear understanding of the experience the story is supposed to deliver to an audience. Everyone from the prop master to the camera person has a sense of this experience goal. If the story (or a particular scene) is supposed to make the audience fall over with laughter, the cameraperson, to be sure, will frame each shot in a way that maximizes that goal. Every scene, every moment, every tangible element of a film works together for a purpose: to make it easier for audiences to understand and engage with a story and to create an emotional response to walk away with.

experience elements

In the case of user-centered design, we do well at coming up with the right technology and features that perform in a way that meets the needs or behaviors we observe in our users. But we often neglect to consider the story that’s told through the interactions people have with the things we make. For this story to be apparent to people, let alone meaningful, those involved with the design of a product should have a shared sense of the kind of experience they are trying to create. In the domain of digital products the story comes from asking the big questions: What’s the product or service about? What will it do for the customer? Where does it fit into their lives? In what ways might we create an emotional response the customer can walk away with?

How does a good story get built? With a theme, of course. Writers and filmmakers have been using themes to build stories for a very long time. They’re also not shy about designing explicitly for emotion and meaning. So why not designers? For us, a definition of the core value of experience can function as the theme that helps teams collectively build a more meaningful product. It’s the thing that can serve as a coordinating force behind the design. When the tangible elements of a product are all working together for the same purpose the product has a stronger story to tell. The theme is merely the thing that helps us deliver that story in the form of an experience.

From Theme to Story

For a writer, a theme is not the thing one starts with, but the thing one “finds” or discovers at some point after the writing has begun. It’s an idea that should emerge organically from the raw material of one’s research, note-taking, plotting, scene-making, and character sketches that are produced during the story planning and early writing process. Typically, a story theme is expressed as a value (greed), an opposition (freedom vs. security), a value plus a cause (justice is restored when the truth is revealed), or simply a very strong gut feeling of what the story is ultimately about. The form can vary widely, and often depends on the bent of the writer or the type of story.

An experience theme also emerges from the raw materials of our design process: the business goals, market considerations, user research and content analysis, among others. Yet while a story theme may express a topic or idea, an experience theme expresses the core value of the user experience. One such theme, for a project commissioned by Agnes Nixon, the renowned writer and creator of the soap _All My Children_, looked like this:

_Reliving All My Children_

Agnes Nixon and her family had asked us to create a site that would leverage their “tremendous library of content in a new, engaging interactive video-centric web property.” That was their only requirement. So where to start?

We started where one might expect. We immersed ourselves in the domain, read about soap operas, watched episodes, and spoke to fans until we got to the point where we felt like we finally understood what this rather obsessive world of fandom was all about.

But when it came time to define functional requirements, it simply wasn’t enough to take the business objectives and our user research and conclude that we should create a flexible video portable that would do x, y and z, include a really cool interactive timeline of Agnes Nixon’s life and a blog authored by Ms. Nixon herself. This wasn’t a concept or an experience. It might be easy to use. It might perform well and look great. But to go that route would do no more than deliver a library of branded video content.

What we needed to know was what this site was all ABOUT. What will it do for these fans? Where does it fit into their lives? In what ways might we create an emotional response the fans can walk away with?

So in an attempt to break away from our customary ways of approaching design we started hunting for themes. We looked at what we had learned about prospective users and soap fans in general and considered our business objectives. With this information we then spent a long time brainstorming ideas that would answer two questions: “What’s the site all about?” and “What kind of experience would be most compelling and meaningful to our users?”

_Reliving All My Children_ was just one of three possible themes. Our plan was to take these themes to the client to see if it would help them further articulate their vision.

experience theme grid

Each of these themes sprang directly from what we knew to be true about soap fans, and each evoked a different kind of experience. For each theme there’s also an associated concept and story premise as well as an altogether different set of primary activities. If the site was to be “about” _Reliving All My Children_, then our design process would focus on creating an engagement that would tap into the memories of loyal soap fans who grew up watching the show. This theme evoked a product story about an immersive time machine where fans could engage with a “story timeline” of episodes, read blog posts about memorable moments, ask Agnes Nixon questions about what happened to certain characters.

The idea was that one of these themes would drive the site’s concept, functional requirements and our design strategy. The amazing thing: when the client saw these themes they were suddenly able to talk at great length about their vision for the fan’s experience of the site. We had, together, begun to form our product story.

Go team, go!

Once your team has an experience theme, they can begin to behave more like film crews. Everyone involved in the project will have a clear sense of what the site is about and their efforts can be focused around achieving that experience. When this happens all of the component parts of the product will begin to work together. If you’re a consultant or designer working alone, you can think of the theme as the thing that will coordinate your inner team.

But how does this happen? In our practice, the experience theme is packaged in a way that can be shared and internalized by all stakeholders. This usually takes the form of an _Experience Brief_ that outlines the purpose of the theme, the attributes upon which it was founded and the strategy it informs. And in a manner of speaking this document becomes another iteration of the product story.

For another project we created a theme that was to capture the value of the experience of an entertainment alerts program:

_Don’t Miss Out. Discover something new. Get it first._

With this long-term client, comprised of stakeholders from separate interactive, business and marketing departments, we introduced the concept of a theme with an experience brief that looked like this:

experience brief

Our goal was to get this client to step away from discussions of pure functionality and to consider the value of using the product. As we were leading the research, we did the work of finding the theme that seemed to best reflect their business goals as well as their user’s expectations. We also appended a strategy, drawn from this theme that would connect it to more tangible, measurable goals.

experience strategy

With this brief on the table in front of them, the concept of user experience no longer seemed so abstract. By expressing the value of that experience, it gave them a way to look at their program from the point of view of their users. It gave us, as their vendor, a way into their ideas of what they envisioned as well as a chance to validate our thinking behind what kind of experience the program could deliver. It led to a discussion about how the efforts of marketing could match up with what we were doing in the design of the online piece.

The overall effect of this simple document was to synchronize our collective thinking about the project. In this way our product story was beginning to form. With this shared story, the copywriter from the marketing department and the interaction designer with our agency could now work toward the same experience goal.

Designing with Themes in Mind

What’s really interesting is how themes, once found, function in the creative process. In the words of Robert McKee, the author of “Story” and screenplay workshop guru, the theme (or, as he liked to call it, the “Controlling Idea”) is the thing that “_shapes the writer’s strategic choices. It’s yet another Creative Discipline to guide your aesthetic choices toward what is expressive of your Controlling Idea and may be kept versus what is irrelevant to it and must be cut._” A subplot, for example, may be constructed as a counterpoint to that controlling idea. A character might be designed to embody some aspect of theme. A scene might be cut because it’s simply not relevant to the theme.

The best way to understand how this applies to design is to think of the theme as the geography as well as the compass. When generating concepts, the theme acts as the region within which our ideas circulate: this conceptual lay of the land gives us an area of focus and a space to create. When analyzing and reviewing solutions, a theme functions more like a compass: if a creative solution doesn’t line up with North, it might mean that it doesn’t quite chime with the theme. In this way theme can inspire solutions as well as help us make decisions during the design process.

In another project, our team used the following theme to inspire solutions ranging from functional requirements to content strategy, site architecture and interaction design.

_Where the Fight Never Ends_

This project was for Showtime Sports, a site delivering content and event information for fans of Boxing and Mixed Martial Arts. We felt this theme encapsulated the idea that the site could provide an online experience that seamlessly extended the kinds of real-world engagement found among fans of the sport. Not only could the fight live on in the context of the site, but fans would be able to engage, follow and learn about the full fight story. It was supported by our research, and potent enough to carry around as an idea that could inspire and inform anyone working on the project and at all phases. It was expressive of what differentiated the site as well as what would be compelling to users. It was good for business as well as design.

Here are some examples of how the theme impacted our design:

  1. Functional Requirements – We used the theme as a compass when looking at our standard spreadsheet of features for determining scope. In addition to frequency of use, importance and level of technical difficulty, we looked at these items against theme. For example, someone had an idea for a really “cool” dynamic ranking tree. Fabulous, but when it’s put up against the core story of the site it really had no place. The site wasn’t about seeing the sport in this way. It was about extending the experience of a fight. With the theme as an additional filter, it was easy to remove this from the list without prolonged discussion about its value. The idea simply wasn’t contributing to the core experience we were hoping to deliver.
  2. Content Strategy – As a basis for content strategy, we analyzed the available content against the theme and created suggestions for new content ideas. Showtime had a wealth of footage related to each event and some promo clips shot before the fight, but nothing about what happened well-before or after a fight was over. When thinking about content that could support our theme, we suggested creating short, cheaply produced segments of the fighters’ private struggles in preparation for an event. We also suggested in-depth interviews with the fighters after the fight–something that would give them a chance to reflect on what they needed to do in preparation for the next fight. In this way, the theme functioned as a space in which to generate ideas that would support our collective vision about what was most important about this site experience.

  3. Site Architecture – The theme inspired ideas for the structure and user pathways. For this, we began thinking about how the users flow through content would reflect our theme. We created a concept model as a way of seeing these paths and their relationship to key content areas. To further explore this idea, we created an animated version of the model which added a dimension of time, where certain content elements appeared during specific “phases” of the fight (illustrated by the colored bands around the content buckets). Our hope was that this evolving structure would also support the theme.
    experience strategy
  4. Interaction Design – When it came time to create solutions for the interface, our interaction designers sketched with the theme in mind as way to ideate concepts. This is the moment when the use of theme feels closest to “writing”. In this context theme is simultaneously our geography of play as well as our compass for analysis. We try not to be over-conscious of theme when generating ideas and sketching, but we do want to have it in the back of our minds.

    To this end, we usually have our theme written somewhere on the whiteboard. Then, while iterating on sketches, we’ll pause and discuss the way we usually do, but we’ll also reflect on whether or not the sketches are doing anything to support our theme.

    This process eventually led to the design of a flash component that stored all video content related to the fight in a carousel organized by time. The linear progression of videos would together create a “fight story”, from early pre-fight videos to post-fight interviews.

    Whether users wanted to catch up on something they’ve missed, follow the fight online in absence of TV or revisit the fight at some future point the interaction design was supporting our experience goal of providing a place where the fight never ends.
    experience strategy
  5. The lesson? Experience themes can inspire solutions, help teams make decisions and (perhaps most important) help us remember the quality and value of the experience we intend to deliver.

    Final thoughts

    As Robert McKee writes: “The more beautifully you shape your work around one clear idea, the more meanings audiences will discover in your film as they take your idea and follow its implication into every aspect of their lives.” Themes, used in the context of experience design, can function in a similar way. By aiming to capture the value and focus of experience, themes have guided us in the design process and, by extension have strengthened the impact and meaning of that experience. Equally important, they’ve given us a path to holistic design.

    As user experience professionals we should be looking at all aspects of the product or service design, as well as the aesthetic potential of every element that comprises the experience. Themes can help us do that. They can be a potent tool for harmonizing otherwise distinct, tangible elements of a product or service in a way that will effectively distinguish it from competitors and offer a more pleasurable and meaningful experience on the part of the user. A theme can be applied to all stages of the experience design process, and it helps everyone involved in creating the “whole” of the product or service, no matter what their role. From the critical perspective of leaders and stakeholders, a theme will help unify the efforts of those who play a role in anything from the strategy to the design, development and delivery of the service.

    The ultimate beauty of a theme is that, in the product or service context, it can simultaneously inform the practical, tactical and aesthetic considerations of our work. It can be the coordinating force for an entire product, or a smaller component of a larger service. It is the organizing principle behind our product story. It can work for business as well as design. And in the end, it ultimately works for the benefit of customers.

    Special thanks to Steve Baty, my editor, as well as Joe Lamantia, Jared Spool and Andrew Hinton for their immensely helpful support and feedback for this article.

UI Pattern Documentation Review

Written by: Patrick Stapleton


User interface (UI) patterns have the potential to make software development more efficient. The prospect of such efficiency gains has led to interest in user interface (UI) patterns by individuals and organizations looking for ways to increase quality while at the same time reducing the costs associated with software development.

The very nature of UI patterns requires that they be familiar to end-users. An individual UI pattern is a discrete, repeatable unit of user experience. I refer to collection of patterns as a library.

In many cases, less proprietary patterns are more useful in solving a design problem as they can be implemented more uniformly across platforms. This characteristic and the efficiency gains make patterns an excellent opportunity for software companies to come together and promote UI patterns to the wider development community.

Producing a common pattern library, however, implies that the patterns presented are at the very least, consistently documented and most probably presented in the same single classification system. Currently though, patterns are classified and documented in various manners across publishers with no clear standard evident.

The problem

To date, the most common approach to propagating a single user experience standard is the development of UI guidelines and principles documentation within an organization. Development teams  — usually incorporating a user experience specialist — then reference this documentation during implementation and upgrade processes.

However, as the numbers of systems grow within an organization, so does the effort needed to maintain the quality and consistency of the user experience. For many organizations, it is now impossible to assign much, if any, time of a user experience specialist to all implementation efforts, and experience has shown that the UI guidelines and principles approach to propagating a single user experience standard does not scale well.

There are two common issues, both major.

The first issue is ensuring developers are familiar with all the principles and guidelines.

Documentation to fully describe a UI standard is, by its nature, extremely detailed and complex. Getting developers to know all this information intimately is an ongoing and often un-winnable battle.

The second major issue is that the application of guidelines and principles can be open to wide interpretation.

Requiring developers to combine guidelines and apply principles together to create a complete UI can be inefficient. This synthesis process can result in widely-varying solutions to a single design problem across teams — especially when working with widely distributed and possibly culturally diverse groups. Removing these variances to create a more consistent user experience requires rework.

The solution

UI patterns to a great extent mitigate the problems of weight and interpretation experienced with the principles and guidelines documentation approach of the past. In essence, patterns can be seen as prepackaged solutions based on guidelines and principles.
Patterns and pattern libraries are more convenient for developers because they solve common higher-level design problems without the need for deep knowledge of often-complex guidelines and principles documentation. Also, they implement best practices, so developers don’t synthesize what are often “slightly original” solutions that would need to be reworked later.

Much of the value of a pattern to the developer is its less granular and more physical nature. Principles of good UI design dressed up as UI patterns add little value over traditional guidelines and principles documentation, as seen in many of the UI patterns as described in the Design of Sites; examples such as “Low Number of Files” — while an important design principle or guideline — do not deliver up a usable UI component.

Also important is creating the patterns to begin with. The guidelines and principles that form the foundation of patterns still need to be developed before any patterns themselves are developed.

Integrating UI patterns

Integrating UI patterns into the culture of software development is to a large extent still beginning. Next-generation development tools such as those proprietary ones being developed by enterprise software companies that implement patterns natively are now or will be soon in the hands of developers around the world.

Embedded drag and drop UI patterns hold the promise to empower developers to create better user interfaces, faster — unsupervised by user experience specialists. While this may strike fear in the hearts of many a user experience specialist, issues of scale dictate such a pragmatic approach. Be aware though, that they also can perpetuate problems if the UI patterns implemented are out of sync with end-user expectations.

Why standardize UI patterns?

Currently, there is no recognized standard for the classification or documentation of UI patterns, as seen by browsing through pattern libraries from:

  1. Martin Welie’s UI patterns
  2. Jennifer Tidwell’s UI Design Patterns
  3. Sari Laakso User Interface Design Patterns
  4. The Design of Sites: Patterns, Principles and Processes for Crafting a Customer-Centered Web Experience by van Duyne, Landay and Hong.
  5. Yahoo Design Pattern Library

The variety isn’t surprising, since applying the pattern concept to user experience design is a relatively recent phenomenon. However, the successful introduction of a single classification and documentation standard could significantly increase the value of a UI pattern library to developers by…

  • Reducing confusion among pattern versions across collections. Not surprisingly, many of the same patterns exist across collections. A standard classification system (discussed below) can help developers make sense of both these patterns and their different versions in collections across the web and in paper publications.
  • Promoting development of net new UI patterns. A clear classification taxonomy is likely to make the “holes” in the current crop of pattern libraries more apparent, which in turn hopefully will increase the pace of development of new UI patterns.
  • Providing a standard UI pattern interface. As the number of patterns increases, pattern search tools will become more important. A standard classification and documentation approach will enable developers to quickly display their UI options.
  • Promoting UI pattern adoption. A clear classification taxonomy is likely to have the effect of making patterns easier to find and in turn increase their use.

Problems with the solution: UI pattern Classification Approaches

The following is a high-level analysis and discussion on classification approaches of the previously mentioned UI pattern collections. Each collection is mapped and discussed from a classification and documentation perspective.

Martin Welie’s patterns

Classification Analysis

Patterns in Interaction Design

Cropped version of Welie's patterns

Figure 1. Classification Map (click image to enlarge)

Welie divides the patterns into three delivery methods: Web design patterns, GUI design patterns, and mobile design patterns. Within the web design patterns channel (the focus of this document), the patterns are categorized into ten groups based on a mix of content and functional subjects.

Documentation Approach

Cropped version of Welie's approach

Figure 2. Documentation Map (click image to enlarge)

Welie’s documentation approach is simple, with a focus on visual elements to explain the function of the pattern. It can be broken into three main parts:

  • Description: This area of the documentation provides the name and image to describe the pattern.
  • Rationale: This area provides a description of the problem that is solved by the pattern, how it works, and the scope of its use.
  • Associations: This area provides links to other patterns related to the current pattern.

Jennifer Tidwell’s patterns

The following is a map of Jennifer Tidwell’s UI Design Patterns. (Click image to enlarge.)

Cropped version of Tidwell's patterns

Unlike Welie, Tidwell does not take into account different delivery methods. The eight categories she does specify look to be based on functional subject areas only.

Sari Laakso’s patterns

The following is a map of Sari Laakso’s UI patterns. (Click image to enlarge.)

Cropped version of SL's patterns

Like Tidwell, Laakso does not differentiate between delivery methods; he bases all seven of his categories on functional subject areas.

The Design of Sites’ patterns

The following is a map the patterns presented in “The Design of Sites.” (Click image to enlarge.)

Cropped version of Design of Sites' patterns

The most extensive pattern collection of the four sampled, Design of Sites does not specify delivery methods, and, in some cases, the items presented could be regarded as design guidelines or principals rather than patterns. Twelve categories are presented with a mix of content and functional subjects.

Summarizing the classification types

From this analysis three main types of classification are present — content subject, functional subject, and delivery platform.

Content subject classifications normally specify an application genre (for example, ecommerce and supply chain management). Examples of content subject based classifications can be found in the Design of Sites collection under “Site Genres” and in Welie’s collection under “Site Types.”

Functional subject classifications are based on logical breakup of functionality (for example, shopping cart and two-panel selector). This is the most common prevalent classification type and is found in all the collections sampled.

Delivery method is used to describe the platform on which a pattern has been designed to operate. This classification type opens up the possibility for unique patterns to be developed for the same subject classifications across platforms. This classification type has the potential to provide more resolution for developers looking to offtake a pattern within a specific UI delivery platform such as mobile, desktop, or web.

Based on the publicly available pattern libraries available today, there is no clear indication as to whether “delivery method” is a valid classification type. An argument could be made that the process of binding a pattern to a specific technology is will reduce the life of the pattern as platforms develop. However, the timelessness of a pattern is of little consequence to developers whose primary goal is product delivery rather than pattern lifecycle.

Another Classification type – Level

This author would like to include an additional classification type: Level.

The level classification would further divide patterns into the following areas of concern:

  1. Navigation architecture: Patterns relating to the navigation of content within an application
  2. Screen architecture: Patterns which position functionality and content within a screen
  3. Site furniture: Patterns for formatting functionality and content

In the case of the collections previously reviewed, the great majority of patterns would be classified as falling under the “site furniture” level type. However, it is this author’s view that considerable potential remains to develop patterns within the proposed navigation architecture and screen architecture level types.

A proposed classification system

Cropped version of the classification system

The above diagram (click image to enlarge) describes a potential pattern library classification hierarchy. In this case, client classification nodes are presented at the top of the tree similar to that of the Welie collection; the proposed new level classification nodes are added above subject.

Content and functional subjects would be implemented as tags because these classifications would occur across levels.

Why have a classification hierarchy — aren’t filters or tags more useful?

In many cases, being able to filter by classification node as required is more flexible than drilling down through a preset hierarchy. However, a present classification tree is also useful to:

  • Automate the generation URLs to enable cross linkages within the UI pattern library.
  • Provide a simple drill experience for end users who have no specific problem to solve but rather just wish to browse to learn and or generate ideas.

UI pattern Documentation Proposal

The value of a standardized UI pattern documentation to developers is a single interface for search tools. Such tools hold the potential to streamline the off take of UI patterns by developers with specific problems to solve in a world with hundreds and potentially thousands of UI patterns to choose from.

UI patterns are by their nature visual. It must be noted that strong support for pictorial content would seem obvious and reduce the necessity for long verbal descriptions that add little value next to their visual equivalents.

Bringing Holistic Awareness to Your Design

Written by: Joseph Selbie

Gone, thankfully, are the days when the user experience and the user interface were an afterthought in the website design process, to be added on when programming was nearing completion. As our profession has increasingly gained importance, it also become increasingly specialized: information design, user experience design, interaction design, user research, persona development, ethnographic user research, usability testing—the list goes on and on. Increased specialization, however, doesn’t always translate to increased user satisfaction.

My company conducted a best practice study to examine the development practices of in-house teams designing web applications—across multiple industries, in companies large and small. Some teams were large and highly specialized, while others were small and required a single team member to perform multiple roles. We identified and validated best practices by measuring user satisfaction levels for the applications each team had designed; the higher the user satisfaction scores for the application, the more value we attributed to the practices of the team that designed it.

We did not find any correlation with user satisfaction and those teams with the most specialized team members, one way or the other: some teams with the most specialization did well, and some teams did poorly. What we did consistently observe among teams that had high user satisfaction scores, was one characteristic that stood out above all the others—what we began to call shared, holistic understanding. Those teams that achieved the highest degree of shared, holistic understanding consistently designed the best web applications. The more each team member understood the business goals, the user needs, and the capabilities and limitations of the IT environment—a holistic view—the more successful the project. In contrast, the more each team member was “siloed” into knowing just their piece of the whole, the less successful the project.

All of the members of the best teams could tell us, with relative ease, the top five business goals of their application, the top five user types the application was to serve, and the top five platform capabilities and limitations they had to work within. And, when questioned more deeply, each team member revealed an appreciation and understanding of the challenges and goals of their teammates almost as well as their own.

The members of the teams that performed less well not only tended not to understand the application as a whole, they saw no need to understand it as a whole: programmers did not care to know about users, user researchers did not care to know about programming limitations, and stakeholders were uninvolved and were considered “clueless” by the rest of the development team. These are blunt assessments of unfortunate team member attitudes, but we were surprised how often we found them to be present.

We also observed that the best teams fell into similar organizational patterns—even though there was a blizzard of differing titles—in order to explore and understand the information derived from business, users and IT. We summarized the organization pattern in the diagram below. We chose generic/descriptive titles to simplify the picture of what we observed. In many cases there were several people composing a small team such as the “UI Developer(s)” or the “User Representative(s)” often with differing titles. Also fairly common were very small teams where the same person performed multiple roles.

Holistic Awareness Fig 1

Fig. 1 — Teams tend to organize in similar patterns in response to the information domains they need to explore and understand

Even this simplified view of the development team reveals the inherent complexity of the development process. The best team leaders managed to not only encourage and manage the flow of good information from each information domain, but they also facilitated thorough communication of quality information across all the team members regardless of their domain. Here’s how they did it.

Five Key Ways to Promote Shared, Holistic Understanding

1. All team members—all—conduct at least some user research

Jared Spool once wrote that having someone conduct user research for you is like having someone take a vacation for you—it doesn’t have the desired effect! On the best teams, everyone, from programmers to stakeholders, participate to some degree in user research. A specialist on the team often organizes and schedules the process, provides scenario scripts or other aids to the process, but everyone on the team participates in the research process and thus has direct contact with actual users. There is no substitute for direct contact with users. Interviewing living breathing users, ideally in their own home or work place, makes a deeper impression than any amount of documentation can duplicate.

2. Team members participate in work and task flow workshops

Designing applications to support the preferred work and task flow of the users—providing the right information, in the right features, at the right time—is one of the hallmarks of applications that get high user satisfaction scores. The best teams devote enough whiteboard-style collaborative workshop time to explore work and task flow (including in the sessions actual users when possible), until all team members truly understand all the steps, loops and potential failure paths of their users.

3. Team members share and discuss information as a team

A simple practice, but one which is often overlooked, is taking the time to share and discuss findings and decisions with the entire team. Too often teams communicate information of significant importance to the project through documentation alone or through hurried summaries. Even if it is not possible for the team to participate in all user research or in mapping out all work and task flow on a whiteboard together, at a minimum, the team should go through the results of these processes in sufficient detail and with sufficient time to discuss and understand what has been learned.

Direct participation is the most effective way to learn and understand. Full and relaxed discussion with team members is the second best. Reading documentation only is the least effective way for team members to retain and understand project information.

4. Team members prioritize information as a team

Not only is it important that all team members be familiar with information from all three domains (business goals, user needs, and IT capabilities), but it is especially significant that they understand the relative importance of the information—its priority.

My company developed what we call a “Features and Activity Matrix”, based on our own experience designing applications, and from the practices we observed in our study. The features and activity matrix accomplishes two things:

  1. It forces teams to translate business goals, user input and IT capabilities into specific proposed features or activities that a user would actually see and use at the interface level. We have found that if an identified user need (for example, the need to know currency conversion values) isn’t proposed as a specific feature (say, a pop-up javascript-enabled converter, tied to a 3rd party database) then a potentially important user need either gets lost, or is too vague to design into the application.
  2. The features and activities matrix allows team members to prioritize the proposed features and activities from the perspective of their own domain through a process of numeric ranking. Business ranks according to the importance to the business, IT ranks according to “doability” (measuring budget, resources and schedule against each proposed feature and activity), and the user representatives rank according to their assessment of what will make users most satisfied.

The numeric ranking for each feature or activity, from each domain, is then averaged to arrive at a consensus prioritization of every feature and activity proposed for the application. If, as is usually the case, the team is already aware that they cannot do everything that has been requested or proposed, this is a very effective way to determine which features and activities are not going to make the cut and which ones have the highest importance.

Holistic Awareness Fig 2

Fig.2 — Features and Activities Matrix. Note that we used a ranking scale of 1-5, 5 being the most important.

5. Team members design together in collaborative workshops

Once information from all three domains is gathered, analyzed, shared and prioritized, the remaining—and most powerful—practice to promote a shared, holistic understanding is to conduct wireframe-level, whiteboard-style, collaborative design sessions. Your session participants should include a solid representation of users, business and IT but not exceed roughly 12 people. In these workshops teams can work out together the basic layout, features and activities for most of the core screens needed for a project. These sessions can, and should, require multiple days. We have found that between 10 and 20 core screens can be considered, discussed, iterated and designed in 4-5 days of workshops.

Make sure everyone is fully engaged: business cannot be half committed, and IT cannot say that they will determine later if the screen can be built. All team members should be prepared to make real-time decisions in the collaborative design session. Inevitably there will be a few things that simply cannot be decided during the session, but the greater the shared, holistic understanding that already exists, the fewer things that will require processing and final decisions outside the session.

A well prepared collaborative design session both promotes and leverages the team’s shared, holistic understanding of the project. Even though they are time consuming, collaborative workshops eventually save time because the team ends up needing less iterations to refine and finish the design. Collaborative workshops also insure higher quality; there are fewer missteps and errors down the line because of the shared understanding of the design. Finally, collaborative workshops create great buy-in from business and IT. It is far less likely that some—or all—of the project will undergo unexpected or last minute changes if the goals and priority of features is clearly established during the design process.

Whatever the size and structure of your team, and no matter how many or how few specialists it has, your outcomes will be better if everyone shares a holistic understanding of the work at hand. Taking the extra time as a team to develop a shared holistic understanding pays off in greater efficiency in the long run—and most importantly—in greater user satisfaction and overall success!