“We need help creating this new <insert mobile app/website/etc>.” “Our existing <digital thing> needs redesigning.” This is how a great deal of User Experience design work gets started. Somewhere, someone gets an idea for a new experience, or feels that an existing experience has gotten long in the tooth. Both of those things inevitably happen; ideas and time. As is most common, the idea and/or problems with an experience get communicated to UX practitioners and then translated into a “project”.
As UX people, we’re good at doing projects. We have many methods, approaches, tools and methods to do great design. The stickier situation for me frequently occurs when I get started on a project and suddenly ask why we’re doing this project. See, by the time the project is under way, asking why we’ve decided to commit precious time and resources to doing this is not only an uncomfortable conversation, it’s often an unwelcome one. There is a choice to be made, by many parties, as to whether or not that conversation is important enough to have, yes, but more importantly, when.
Where to Begin?
A conversation in someone’s office, the morning shower, the annual planning meeting. Those are all places where the inception of an idea for a new experience probably take place. Events that, in all likelihood, are lacking the participation of an experience designer. Commonly, those ideas get later communicated to the design team to take on the “execution” role of that idea. Make it real. As mentioned, we’re good at doing that, so it makes sense. The problem is that those new ideas and changes can be informed by the very work we do. The same tools and methods we apply to create the thing(s) are the same that can define them. I will go so far as to say that UX designers have the opportunity to even create spaces for those ideas to occur.
In the scenario mentioned before, if we’re trying to figure out why we’re doing a project, how it will be useful or relevant to an audience while we’re designing, it can end up feeling like we’re forcing a business idea into the lives of people who don’t want or care about it. To be clear, that usually sucks. Creating meaning during design can be done, it just doesn’t typically work that well and at best, we can hope for the hippocratic oath of “first do no harm”.
There’s a better way. Experience design principles and methods can inform decision making in business. As designers, we’re constantly seeking to learn about people. We synthesize that understanding into some insight that informs design decisions. That practice can be applied much earlier to inform decision making about business, operations and strategy. Business, audience, design. If we create continuous feedback loops of understanding for all of these, theoretically they can inform each other to establish and maintain a bedrock of understanding with which to make sound product and service decisions.
Creating Spaces for Decisions
When I mentioned creating spaces that allow for those ideas to occur, I’m directly referring to the ability to design situations in an organization, ones that possess insights to business direction and goals, current products and services and the people they’re meant to serve. I’ve often referred to these as feedback loops. In a former article I wrote about experience strategy, I talked about explicitly separate efforts of continuously and objectively learning from ourselves (the business) and the people we serve (our audience). In establishing such feedback loops, inherently therein creates a convergence and divergence of understanding. Some cases will prove that the audience, culture and expectations have changed the goals of the business. Other times, we may find that business decisions have subsequently changed what people need.
The practice of UX design can create these feedback loops through strategic execution of methods like analytics review, ethnographic research and business discovery sessions that happen on a regular basis with clear intent on the purpose and frequency of each activity. It’s no secret that organizations have a difficulty in alignment between separately operating areas of any company. Further, I’ve found it to be more common than we should care to admit that we often don’t know enough about the people we’re hoping to provide value to. All that said, if we created feedback loops with each (business and people), and committed to a regularly occurring time when the aggregate understanding of each were meant to inform each other, we’ve essentially created a space for informed decision making to take place. Decisions that are defining what “projects” should take place. Those spaces allow for business leaders to determine even what decisions should be made. Essentially, I’m suggesting that experience design can begin before we even know when the actual beginning is. How meta.
The End (not yet, keep reading)
Value provided by a designed experience never really dies. The needs and expectations of people rarely change dramatically enough to render a product or service obsolete. Products or services most often fail due to unmet expectations of the people they were created for. They don’t adapt to the changes in people. Lucky for us, we’ll have created an ongoing feedback loop with our audience, and our business intentions, to keep in step with behavior and expectations of a product or service. If we’ve done that, we’ll know when and how to make changes in existing products and services, but just as well we’ll be confident when a new or complementary product/service is warranted. With such a bedrock of understanding, we shouldn’t have to face a daunting, large-scale redesign as often as we now do. Additionally, we would have a deeply rooted confidence for moving in a new direction if and when we do. You can see where this is going. Experience design doesn’t end (I’m very sorry for the trickery in the title). If we use existing design methods of research and discovery to inform decision making in an ongoing basis, we can create feedback loops between people and organizations that allow for products and services to evolve when necessary, in the right ways. In that way, we’re also well positioned to create new products and services that have clear and uniquely separate meaning in the lives of the people we’re designing for. Doing so increases the chance for success in meeting business goals and serving people the way we hope to..
A colleague of mine recently attended SketchCamp Chicago. She was talking to me about all the things they discussed and ways of using sketching that she hadn’t readily thought of before. We ended up talking about how she was going to take pieces of what she’d learned and apply them to a current project on our team to design a mobile app.
Forgotten But Not Lost
This conversation reopened my eyes to something I’ve been doing for nearly my entire career thus far of calling myself a UX designer. Sketching is so often overlooked in the shuffle to produce visually compelling, highly polished documentation. I personally was able to take for granted that the “real” effort behind any design is the thought work that goes into creating the document, not the document itself. That is to say, the document deliverable is only a communication of that idea or concept. We all too often lose sight of where the priority should lie in our effort; the thought work.
Sketching allows us space and freedom for the thought work effort of a design. More importantly, it provides the much needed oil for our creative engines. We’ve all read articles or seen presentations about the importance of sketching and the perils of starting too early in a higher fidelity medium. The former is well tread in the UX community and in general tells us that sketching helps generate better ideas, while the latter often cautions us that a higher fidelity medium can be limiting in our creation of a concept. My intention isn’t to revisit those statements but rather take a different outlook on it and share my own approach. Measure twice, cut once, is an English proverb that suggests exactly what it means. Traditionally, it was an axiom for craftsmen and carpenters that served as a reminder (and caution) to carefully plan their approach before engaging creation. It’s relevance in what we do is incredibly powerful. In experience design, sketching is measuring.
The Measuring Tape
I’ve always been a relative fan of constraints. Not the kind that stifle creativity or limit an idea, but ones that actually do the opposite. The way I’ve always designed has started with sketching, but as I progressed through my career, I added little bits along the way that I felt made sketching even better. The idea of “measuring twice” is great, but examining the ruler every once in a while is useful to ensure the right measurements.
In starting most design efforts, I begin using the 6-up sketching template I found by Leah Buley. The 6-up template forces me to think through, at minimum, six different ways a screen interaction might work. In this case, I’m “measuring” up to six times, or sometimes more! The way I’ve always used the template is to generate a number of ideas in a short time frame. This 6-up template has several benefits:
it forces me to think through at least 6 different ways a set of interactions could work
it requires priority as the windows of the template are small and simply cannot contain everything the screen may have
it shows me the graduation of my design ideas in progression, all in one place
Boxing Yourself In
When sketching, sometimes I go free-form and just explore ideas, but more often than not, the exercise of sketching is more structured for me. I’ll start by using the blank 6-up template. Here’s the catch though, I actually “time-box” myself to 15 minutes. I force myself to come up with 6 different designs for the particular problem I’m trying to solve within 15 minutes. Has to be six different designs, has be to done in 15 minutes. Why 15 minutes? Well, in truth it was an arbitrary number I placed on myself a long time ago that felt right when trying to solve a design problem quickly. I hardly ever expect to have the answer after 15 minutes, but I DO expect to have a bunch of ideas. I’ve found that it actually goes one of two ways. Either I end up scrambling to fit everything in within those 15 minutes, or I actually find myself struggling to fill all six of the the boxes with newer ideas. There are huge advantages to each situation. If I’m struggling to fit all my ideas into 15 minutes, the time constraint forces priority in my thinking and focused restraint to meeting the goal of that interface. If I find myself “done” with only 2-3 boxes sketched out after 5 minutes, it then forces me to explore my design ideas more deeply. In essence, the exercise does not allow me to take my first ideas at face value, nor does it permit me to meander in concepts for eternity. Here’s an example of the approach I take, showing the progression of a comparison screen interface I did a while back:
I start with Leah’s 6-up template.
Then, giving myself 15 minutes, I force myself to come up with 6 different sketch concepts of the interface I’m trying to design. You’ll notice how the idea visually progresses, building on itself from left/right, top/bottom. I’ve often found that I continuously “steal” things from the prior sketch, however small. There are times when I’ll actually run through more than one 6-up template if I don’t feel like my concepts are sound enough for a particular interface. In that case, I simply repeat the cycle; another 15 minutes, another 6 concepts.
Finally, once I feel as though I’ve explored the majority of possibilities for the screen I’m working on, I’ll move to the 1-up template.
If you notice from the 6-up template, there are several items that ultimately made it into this larger version. From the 6-up template, I was also able to explore specific parts of the interface in subsequent sketches with a bit more detail. That later allowed me to add such detail to this larger version and bring together several ideas in a single interface.
Ultimately, I was able to make a ton of revisions during my sketch cycles, rather than wireframes or, worse yet, development effort. With all the “measuring” I did, I could feel confident in moving to a higher fidelity medium knowing I had accounted for all of the possibilities available for the interface. In this case, it was an information-heavy page, which also gave me a head start on prominence, priority and hierarchy of that information. That’s something a little harder to do if you’re jumping right into a wireframe.
The final wireframe ended up looking like this:
A recap of the sketching process I usually take is:
Start with the 6-up template
With a time limit of 15 minutes, generate 6 concepts for the interface
Review and repeat the 6-up if necessary; otherwise…
Move to the larger, 1-up template
Again, with a time limit of 15 minutes create 1 comprehensive sketch for the design based on your ideas from the 6-up template(s)
Repeat 1-up as necessary
Move to a higher fidelity such as wireframes, prototype, etc. (if the situation calls for it)
This approach has helped me rapidly explore ideas for complex interactions. Just as it would be difficult to measure while you cut, the challenge persists for designers to create concepts and explore ideas as they’re attempting to communicate those ideas. Sketching allows us to understand our own ideas, refine them and plan for the best way to communicate them thoroughly.
I had a conversation with a friend and colleague recently that got me thinking about what actually makes a “good” client. It’s important to note that we both work for a services organization. That is to say, we provide experience design skills and people hire us for them. Typically, that comes in the form of a project and that’s exactly how the conversation started. We were musing over our history and why he and I had the good fortune of working together on some of what we considered the best projects, with the best clients. These kinds of things can happen when two esoteric designers get together over cocktails. But with jokes aside, it got me thinking about what actually makes a good client, or for that matter, even a good project.
“This Client Sucks”
Working in a services organization will inevitably bring these thoughts to mind, or even spoken aloud. In some agencies, I’ve heard it said almost daily. Being on the providing end of a service or skill many times means we’re working with (read: for) people who don’t know what we do and that can cause wrinkles in a relationship. It’s kinda like a mechanic. Most us of aren’t equipped to go in and ask specifically for the parts and labor we want for our cars. Often enough, even if we do, the mechanic typically tells us that we were wrong (at least that’s happened to me). Yet, this is a service we know enough about to say “I need that kind of help”. Sometimes, we get angry with the mechanic for telling us that we need a bunch of work done that we didn’t have in mind when we started. All of this back and forth has harmed the relationship and trust of the mechanic and I can’t imagine they think very highly of us when we tell them how to do their job. In actuality, the mechanic probably isn’t being unethical but rather making decisions based on knowledge that we don’t share.
Arguably, the biggest reason that ever leads us to say a client sucks is lack of knowledge. There are, of course many other factors. Ignorance, however, breeds a host of negative emotions like distrust. That, in turn, erodes any relationship. Again, while the mechanic doesn’t expect us to come with the level of expertise in their trade, it sure would go a long way wouldn’t it? I’d imagine some of the most enjoyable jobs for a mechanic are ones where the clients trust them to do their job well and have educated themselves enough to know what they don’t know. It’s the same for us. Maybe we should only hire the clients that are as smart as we are about design. That should solve our problem, right?
After the conversation with my friend, I couldn’t help but try to understand what made up a lousy client relationship. It’s one thing (and a pretty easy one) to say, “hey, that project rocked and the client was great”, but to actually articulate why is trickier. In UX, I’m often found exploring what wrong looks like to determine good. With regard to clients, a crappy one probably doesn’t trust you to do your job. They won’t consider your ideas and recommendations outside of theirs. Likely, they’ll micro-manage your work and make unreasonable demands for the project. Those clients just suck, don’t they? We start to call them bad names and think that their companies are full of morons. They just don’t get it. Obviously they won’t listen to us, so we’re left with putting quotes from these cretins on http://clientsfromhell.net/. At least our other designer super-friends can get a laugh out of our misfortune until we get a good client. Yea, that’ll teach’em.
My friend and I agreed we had a chance to work on some incredible projects with amazing clients. We’d poured over what made the projects that awesome but what we came up with were the clients. So here we are, full circle. If a good client is the most decisive factor in a kick ass project, how do we find more of them?
Here’s some real talk, good clients don’t just show up, they’re made. What makes a client good? You do. I do. We all do. If your client sucks, you probably suck. This is a little Roosevelt tough love, man. That website should change its name to “designers from hell”. Sure, some of the things clients say is ridiculous. Some requests we get are probably outlandish, but nobody would ask for that stuff if they knew what we knew. We need to teach them! Great client relationships are all about setting clear expectations and being transparent and informative in your communication. That, in turn, sets the stage for a pretty sweet project.
When that mechanic simply tells you that you need $3000 worth of work done to your car without explaining why, it sucks. I know it gets me angry if someone tells me something has to be a certain way with no explanation. We are very guilty of this and when we think critically on it, it is absurd to expect anyone to engage with us and blindly follow our recommendations without explanation. These folks are likely paying good money for our services and they deserve to know the rationale behind our decisions, but even further, to feel part of making those decisions.
As I’d reflected on some of my best client relationships and projects, they are ones where not only did the stakeholder(s) have a part in making decisions for the designs, but I wanted them to! They were partnerships, ones where I truly valued their input and knew it would lead to greater success for the project. Jon Kolko’s article over at UX Mag has a lot of great suggestions for how to get to that level of trust in a client relationship.
If we were teachers, would we just tell students they were stupid because they weren’t learning the material we taught? No way. The chef at your favorite restaurant doesn’t stay in business for long if they tell you that you don’t like the dish because your palette is unrefined. The best professionals in any industry don’t compromise their approach or quality, but rather find a way to educate the people they serve on why their service is the highest value. They don’t just expect trust, they earn it.
A Rose By Any Other Name
So here’s the thing, even those clients and projects that weren’t on my “coolest” list were still pretty damn good. One thing I know for sure, is that if we didn’t work to make them even “just ok” relationships and projects, they probably would have been a drag. People are who they are. We can do a lot to bring the best client out of them. One of the most interesting things my friend and I realized is that even though there were many great projects and clients, none of them were the same. No two clients were great clients for the same reasons. Every single time, we worked to carefully educate and partner with those people in order to make the relationship and project a success given the situation at hand. Arguably, there is a common thread in every partnership and awesome project outcome. Trust. It’s true, that clients who trust us are typically regarded as the best clients, but there’s more than one way to earn trust. Trust also comes in many forms. Some clients trust us, but push back enough to make our work even better. Others have faith in our work and allow us full freedom to work within the agreed upon constraints and everything in between.
If you find yourself in a lousy client relationship, don’t jump to the conclusion that the client sucks. Think first on how you could be communicating better. Ask yourself if you’re being as clear as possible about the project, where it’s going and why. Check yourself and evaluate whether or not you’ve set or are setting clear expectations. Let’s work harder. Let’s be better. We make better clients that way.
There’s been a lot of talk over the last few years on “defining UX” and what our process is. We’ve asked ourselves questions about what the difference between UX and UI is, where Content Strategy fits into UX and how “lean” we can get. I can’t say that I’ve read all of this without shaking my head. With as much discussion as we’ve had around these topics, we’ve still left many people in the dark about what it actually is that we do. As we move to position what we do at a higher level in business and organizations we work for, it serves us well to align the message and value of UX in a broader sense in order to evolve our offering. Further, it’s incredibly important that we bring clarity to what we already do.
First Let’s Be Clear, We’re Talking About Screens
One of the biggest clarifications I feel needs to be made in this kind of discussion is that most of the time, we’re talking about an experience that has a screen. Typically, we refer to that as an interface, which can have a much more transcendent meaning. The majority of the time we have this discussion, however, we’re doing so in the context of designing something with a screen. That’s perfectly fine. The distinction is important, for me anyway, due to the very broad definition I apply to experience design in general which is: designing any set of parameters or influencers to allow for a group of people to have a certain experience as it was intended by another set of people.
That’s super broad, but in essence, that’s what we do, we just happen to do it mostly for screens (for now). We take information and understanding from one group of folks (most often a company or organization with the intent to generate profit) and design (services, interfaces, products, environments) to allow for that experience to take place for the identified customers/users/members of previously said organization. To that end, it’s important to call out that there are many forms an experience can take, and a screen is but one of them.
What’s In, What’s Out
My view of experience design is colored by the approach we follow at The Nerdery. For the UX team there, we subscribe to the idea that all of the following disciplines or practice areas fall under the umbrella of “UX at The Nerdery”:
Discovery and definition
Front end development (to a more limited degree)
That may seem like a long list of “stuff” to claim in the UX camp and there are a few key points to make. First, is that we don’t expect, nor do we have, anyone to practice all of those areas to proficiency. Second, not every part of that approach is employed in full effect for every project. We’re structured this way with desire to be efficient with breadth of in house talent we have while producing the highest quality of work possible. I’ve heard variation in how many UX practitioners define each practice mentioned, so my own definition for each is useful for clarity.
Discovery and Definition
Here, we’re trying to learn about the business, it’s goals and the problem they’re trying to solve. Defining the problem and the people we’re hoping to solve it for are the primary goals in this practice. Often, this takes the form of stakeholder interviews, client workshops and related activities.
Once we’ve more thoroughly defined the problem we’re trying to solve and a target audience, we’ll aim to learn about that audience more. Specifically, the behavior (current and past), expectations and even cultural values are main areas we hope to learn more about. Later, we’ll reconcile those with the identified goals and needs of the business to make informed design decisions.
Establishing the primary goals for the content and messaging is critical. Content strategy as a practice allows us time devoted to determine the proper tone, delivery and channels to deliver the message of the intended design. Additionally, it often helps clients think about who owns, updates, manages and governs content curation and creation.
A critical element of providing a sound experience on a screen (or anywhere) is the ability for people to easily recognize labels, access and use of the information your design provides. Information architecture (IA) is a practice that aims to organize, prioritize, label and structure the information and content of a given design. Commonly used tools here are sitemaps, content inventories, taxonomies and the like.
Once interaction design (IxD) is underway, the focus turns to defining all of the ways a person can access, manipulate and consume information. Also, IxD creates the means by which people using a design can accomplish tasks and goals with a design in the easiest way possible. We often see prototypes, wireframes, process flow documents and pattern libraries (buttons, layout schemes, process steps, navigation, etc.) come out of the IxD effort.
Almost always, an experience we create for a screen or interface has a brand behind it. The visual design effort is where we work to incorporate those brand standards, visual language and aesthetic into the experience. More importantly, visual design is tasked with bringing rich fidelity to defined interactions and content in such a way that really engages the people using the design, through use of carefully applied color theory, typography and other fine art principles.
Front End Development
A critical point to mention, is that our approach is largely unique for each project (read: problem) we’re tasked with solving. Again, each of these disciplines are not applied to the fullest for every project, nor should they be.
Making the Cut
Determining how much or how little we apply all of the previously mentioned practices to a given project is somewhat of an art. We often make that decision on the fly. Sometimes, we simply don’t know enough before the project starts to accurately make that call. In short, we change our plan once we learn more.
Our approach considers each discipline mentioned for every project. The catch is being able to ascertain where the majority of effort is needed. Discovery and user research are the best ways for us to do so. Those disciplines are ever paramount for defining the problem, which leads us to a stronger grasp for how we can solve that problem. We cannot hope to effectively solve a problem we have not fully defined. It would also be somewhat arrogant to think that we know enough about the people we’re trying to design for without actually talking to them. It should be repeated, that we too should not assume we know enough about the business or organization we are working for. Therefore, we begin with a strong focus on learning their goals and how solving a particular design problem aids in their efforts.
Applying the appropriate amount of effort of other disciplines within UX on any given project is often determined through a combination of what we’ve learned in research and discovery, as well as project constraints like budget and timeline. Once we’ve painted a clearer picture of the design problem we’re solving, we can choose our tools (read: disciplines) more strategically to meet the expectations of people and the goals of the organization. Most often, we discover a priority in either content/information, usability, utility or efficiency is needed. In which case, we choose our tools to deploy against them accordingly.
Apply the Right Pressure
Designing an experience for a screen frequently calls for a focused interaction design and information architecture endeavor. Those activities, however, are the output of effort put forth in user research and content strategy phases. A “deliverable focused” UX practice is something I strongly discourage, but it is important to note that IxD and IA disciplines typically require such documentation to communicate ideas. In short, you’re probably always going to do sketches or wireframes. Timeline, budget and comfort level of the client can help navigate a leaner approach to those activities, but when choosing where to spend other effort, there are simple questions to ask yourself. For instance, if the project is an entirely new product, it may require more comprehensive user research activities to define the audience and their expectations with the product in question. If the product or design primarily provides value to its audience through content consumption, we’ll need a concentrated content strategy and IA approach. You get the idea. The possibilities in constructing your approach to experience design are nearly endless. Each element should be a consideration, but not a step in the process. We’re capable of doing research and design at the same time, for example. Research or content strategy activities can also happen later in the process for a project. Be flexible. The end goal is such that we take steps, in succession, that inform each other in a tumbler effect to arrive at the optimal experience. There are myriad ways that can happen.
Solve A Problem
Forget about formal project methodologies and whether or not you should be Agile or Waterfall. Ultimately, there is no “one size fits all” project framework that will provide you the right approach for every project. Design is a means to solve problems. That philosophy that can help us navigate any problem space. Define the problem you’re solving (discovery and definition), understand why it’s a problem (user research) and create a solution to that problem (content strategy, IA, IxD, Visual Design). In the end, thinking in this way has helped me determine the best project process for hundreds of unique design challenges spanning all sizes, complexity and industries.
“7 Habits of Highly Effective People” is a highly acclaimed book written for business leaders by Stephen Covey. In the book, Covey discusses what he calls a principle-centered approach to becoming an effective business leader or person in general. Covey’s principle-centered approach is comprised of seven habits which identify personal principles displayed by successful and effective individuals throughout the world. Today, his book still stands as one of the top go-to guides for business leadership.
I first read this book about three years ago. At the time I had no intentions on becoming a business leader, but rather seeking another resource to read about how I could get better in everything that I do at work and at home. It wasn’t til late last year that I was home one evening and had glanced at the book while checking up on work email or the like. Then, it hit me that the concept of creating a successful experience for a “user” requires a nearly direct translation of those seven habits, among other things. Further, being an effective designer in my opinion, is also to demonstrate the very habits Covey talks about in his book.
The first habit in the 7 Habits, is Be Proactive. What does it mean to be proactive? The definition of proactive itself is:
Creating or controlling a situation by causing something to happen rather than responding to it after it has happened.
By that definition we are, as designers, charged with taking the initiative to learn, meet and exceed the needs and expectations of those we design for. The nature of user-centered design aims to create a proactive experience. A good experience will meet the needs and expectations of the person having that experience. A GREAT experience will meet and exceed those expectations by not only allowing that person to have the experience they anticipated, but introducing something easier or more delightful than they would have imagined. For an experience to be effective, it’s no longer enough to deliver “me too” design, which is to copy other established conventions and/or competitors.
Being a proactive designer and person follows the definition above. In his book, Covey talks about proactivity as not simply taking initiative and avoiding reactive thinking, but responsibility. Covey, however, breaks responsibility down.
Covey’s definition of response-ability is making choices based on self and shared values rather than the person’s conditions and surroundings. We have the ability to respond. In the world of knowledge work and design, we have ability to influence our surroundings and conditions, rather than them controlling our work. Our roles as designers are often accompanied by a set of expectations and unspoken boundaries by others in the companies we work for. Proactive designers know don’t allow those unspoken boundaries to affect their circle of influence (as Covey would put it) as they aren’t making decisions affected by the outside stimuli and rather self and shared values. Ultimately, designers have the ability to respond to other forces and make decisions based on what’s best for the company’s values, the experience and most importantly the users’ needs. Realizing that we have the ability to respond to outside requests, as well as taking the responsibility to do so is what makes one an effective designer.
I recently read Storytelling for User Experience by Whitney Quesenbery & Kevin Brooks. While I enjoyed the book, it’s focus was primarily on how one uses the art of storytelling to communicate research findings, promote empathy and even sell design ideas to stakeholders. There was however, a great deal of focus within the book on how to listen. Seems simple enough right? You listen to things and people all day, every day. In actuality, active listening is hard work, it takes thought…and genuine consideration for the person you’re listening to. I was quickly convinced that listening is the most valuable tool you have in your arsenal for research.
As I continued through that book, I began to think of practical applications of storytelling while conducting research. This seems fairly obvious when thinking of interviews and the like, but being in a start-up environment, I very often “piggy-back” methods to optimize my already tight time-line and budget. I felt like storytelling can be applied in one on one research activities and also, promoting participants to tell stories themselves.
For context sake, I’ll briefly cover my most common research activity, usability testing “piggy-backed” with non-directed interviews. The way in which we run these research sessions starts very much as you’d expect with defining the goals of the research. What do we want to find? I’ll cover that with our CEO and begin writing a short questionnaire to allow for appropriate screening of participants who respond to our ad(s). Once we choose the folks that we think are a good fit for the research, we ask them to come in, generally for about an hour. During that hour, we ask people to take a look at our website and have a casual discussion either before or after.
How I used storytelling to improve our research
Historically, we would run the usability test first. That process was predictable for the most part, to anyone who’s participated in or conducted such research. Afterward, we would have a discussion about what they saw, liked and didn’t like. I’d ask questions about how they made certain decisions on and offline and allow for my observer to take the opportunity to ask any questions regarding what they saw during the usability session.
In the last case in particular, I encouraged (subtly influenced?) people to tell me stories. Being that it was shortly after the holidays, many of these stories were fresh in their mind. The main change to my research format was that I held the interview before the actual usability session, where they would take a look at the website. Having people tell stories about their past (and hopefully relatively recent) experiences with doing similar tasks, allowed me the opportunity to make note of “flags” for parts of their story that I could use to place them in context of completing a task on our website.
How holding an interview before the usability test made a difference
During the interview this time, I really encouraged people to tell me about their experiences for making decisions online (in this case, decisions regarding their holiday season). I had to work hard to just listen, but when I did, as they told stories I was able to gather mental notes about particular things and dig for further detail. Now, so far that isn’t anything new for a non-directed interview, but this case, I was able to rely on the context(s) in which people recalled making decisions. This was the biggest advantage over how I was conducting research sessions of this kind previously. For instance, before, we’d have a list of tasks we would want to see people complete. Often, we would have to ask someone to complete a task that wasn’t in the natural flow of how they’d visit the website.
Task: see if people can successfully compare items
Me: “…ok, now I’d like you to try and compare ‘item x’ and ‘item y’…”
This time, however, even if we weren’t close to a task we’d want to see next, I would be able to place them in a real, past context of their story instead of “make believe” for a task. In almost every situation, the person would pick up the story they were telling and without prompt begin to dive in even deeper as to how they completed it before while also showing us how they would do so for our website.
Task: see if people can successfully compare items
Me: “So, you were telling me about how you were looking for a new TV a few months ago, and you did some comparison shopping - could you show me how you would do that here?”
In the end, we gathered much richer qualitative feedback than previous sessions since we had people tell us stories about their real past experiences, while at the same time demonstrating how they would attempt to reach their goal with the website being tested. Ultimately, this exponentially enhanced the depth of the “data points” we would get from the think-aloud activity during usability tests.
Jon Kolko recently wrote a series of three posts for Fast Company Design all discussing how to embrace design synthesis in your organization. They’re all a great read and I highly recommend taking the time to read them in succession.
Embrace Dynamic Constraints - acknowledging and allowing the designer to create new constraints and, at times, ignore restraints entirely.
Provide a Runway to Explore Deviant Ideas - providing designers with time, resources and permission to explore “outlandish” ideas leads to innovation.
Support and Encourage Flow and Autonomous Decision Making - providing space and ability to enter a “flow” state where the designer(s) are without distraction, making decisions freely and are empowered to do so.
The final article in this series, When Trying to Invent, Being Objective Can Cripple Your Process, promotes an interesting point of view on whether or not teams should approach design solutions in an objective or subjective way. Ultimately, the article declares that all people and moreover, designers, have unique perspectives that they apply to the data, thus creating something new from that understanding.
This past Saturday I had the opportunity to drive down to DC and participate in this years UX Camp DC 2011. This was my first time attending a barcamp and also a first for attending this particular conference. Overall, I was very happy to have been a part of this event and was impressed with the content and energy of everyone in attendance.
The day started off with the creation of the topics and schedule. Now, this isn’t the typical conference in that you have a predetermined schedule and time slots of topics. Instead, everyone arrives at the venue that morning and writes on a whiteboard a topic and time they’d like to present. It is important to note that there were a few participants that were invited to attend (as opposed to simply registering and arriving that day). You can see the full schedule here.
I showed up that morning with no intention of speaking, but alas, there was an empty space once the dust settled. As I mentioned at the beginning of my talk, I like whitespace as much as anyone else, but I just couldn’t resist the urge. I ended up proposing a discussion about UX and Startups, but more on that later.
My particular experience started by attending Steven Fisher’s talk - Architecting Social Experiences. You can view the video of his session here (part 1) and here (part 2).
After that, there was a different discussion suggested by a local entrepreneur and startup owner discussing - Facebook, twitter, 4sq and Groupon: Why call them tech companies and not IXD companies? He suggested that these new and successful “tech companies” were not necessarily technology innovations but rather innovations and successes based on quality experience and interaction design. His topic raised some debate with the participants but I personally saw his point and agreed with much of his stance on these companies mentioned.
Next, I decided to sit in on Thom Haller presenting - Framework for making complex clear, in which you can see the video of here. He spoke about concepts not unfamiliar to us as UX designers but I appreciated his somewhat unique approach to the content. Thom went further into detail how he uses his “triangle” of audience, context and purpose. We heard about ways in which Thom has created quick and dirty personas from his method of holding the “triangle” up to gain perspective that not everyone is our audience and that we should focus the lens, so to speak. Thom’s website has more information.
After a break for lunch, it was time for me to lead a discussion about UX and Startups. Since I wasn’t anticipating leading a topic that day, there were no slides for this particular talk. Instead, I allowed it to be an informal discussion about some of the challenges presented to UX designers within a startup atmosphere.
I was lucky enough to have folks attend my session with different perspectives, both as consultants and large enterprise designers who faced similar challenges in their respective environment. During the session, I told stories of challenges I had faced during my time working for startups as well as offering advice for overcoming some of the obstacles that others had encountered as outside consultants.
After my session, the same room had Dana Chisnell leading a discussion about Rethinking User Research for Social. You can view the video of this talk here (the video is quite dark). Dana pointed out some common pitfalls of usability testing in general, but also how “traditional” means of usability testing don’t accurately account for the context of the social web. It was an interesting topic that was a tough nut to crack. Dana also shared a few case studies of social web gone wrong, even when thoroughly tested and researched (see: Google Buzz). Ultimately, the group felt that setting up scenarios with real people and content was paramount to properly researching the social web.
I ended my day by attending the talk given by Dan Willis - This is your brain, this is your brain on UX. You can view the video of this lively session here. I appreciated much of Dan’s content as he often cited the book (that I very much enjoyed) “Brain Rules”. He used the biological processes of the brain to point out new and interesting considerations to make when designing experiences. Most notably was the reference that we are exposed to roughly 11 million data points every second, yet our prefrontal cortex only absorbs about 40! Dan also used participants to act out parts of the brain to demonstrate the way humans understand and process new information.
All in all it was a great time. I really appreciate those who attended my session and would highly recommend anyone considering attending to do so in the future.