The User Experience Team of One
Page 5
What you also see in this job description is a common challenge that UX teams of one face—employers are often confused about the relationship between visual design and user experience design. This may point to a lack of awareness about the processes and people involved in user experience work. Some user experience professionals do include graphic design in their arsenal of tools, but many do not. You can still be a user experience designer even if you just stop at wireframes, but user experience generalists—which most teams of one are—are sometimes called upon to do a bit of visual design as well. To get a sense of what your colleagues do and don’t know about user experience, take them out to lunch and have a casual conversation. Consider a “Bathroom UX” campaign (also in Chapter 9, “Evangelism Methods”) to promote a broader understanding of the roles and functions of user experience.
Employers expect UX practitioners to be able to back up their recommendations and show their work. Employers also might expect the user experience practitioner to challenge and persuade others in the organization to adopt new approaches. UX teams of one sometimes have to be diplomatic, informed, and well-meaning meddlers.
PHOTO BY MTNEER_MAN WWW.FLICKR.COM/PHOTOS/MTNEER_MAN
CHAPTER 3
Building Support for Your Work
Principles over Process
Dealing with People Issues
Dealing with Organizational Issues
Responses to Common Objections
If You Only Do One Thing...
Dedicated as you are, it can still be difficult to get others to stand behind the UX approach, particularly when it butts up against executive fiat or the very real constraints of time and budget. It’s not that people are hostile or unsupportive of the idea of a well-designed product that meets users’ needs. But UX sometimes doesn’t have a lot of muscle in the face of other challenges, like an unhappy VP, or a constrained project schedule. Organizations that are new to UX can show a kind of ebbing and flowing commitment that can leave teams of one with sometimes more support, sometimes less. The constant tug and pull of trying to help others understand and care about user experience can put you at times in conversations that feel like battles (and at worst, losing battles). But they don’t have to feel this way if you’re willing to be creative and a little bit strategic about how you overcome obstacles to UX. You can do this by building trust, setting expectations, and then showing progress against them. This chapter will tackle the squishier side of life as a team of one: how to deal with the inevitable people and organizational issues that can influence how successful your work ultimately is.
Principles over Process
One team of one I spoke with said, “We don’t have the process in place that we need to have. In the next year, I’m going to push for that.” This desire for more process is common. But too much emphasis on process can be a distraction that takes your energy and attention away from relationships, which are more important—particularly when UX is still trying to establish itself in an organization and as a field. You can have all the processes in the world, but if people don’t participate or support them, they’re a fruitless exercise. And processes may need to change—often right in the middle of them—but principles can keep the work anchored. Principles are deceptively simple; they’re just statements, really. They are a way for you to articulate a vision for what your user-centered approach should ultimately entail. Principles can apply to not just what you make, but also how you work. Think of the following principles as core tenets for how to work as a team of one. With startling consistency, the most happy and successful teams of one explain that it’s their mindset, not just their methods, that keep them going. This mindset is embodied by the following principles of engagement.
#1 Invite People In
Overworked teams of one can sometimes spend more time at their desks than in conversations with colleagues. You think you’re getting lots of work done and surely people will recognize and applaud your efforts, but it can have the unintended effect of making you seem inaccessible and unfriendly. In bringing people over to your cause, openness and friendliness can go a long way. Every day is an opportunity to invite your non-UX colleagues into the world of UX (see Figure 3.1). In fact, your coworkers may already think of themselves as savvy UX supporters. Even though you may see missed opportunities or on-again/off-again support, you can still cultivate advocates for UX. Invite them into the conversation and the community, and treat them as partners in the ongoing project of making your products as user-friendly as possible.
FIGURE 3.1
The more you can facilitate a cross-functional team, the more you will empower others to feel ownership and involvement in the process.
#2 Make Things Together
User experience work (and who are we kidding, work in general) can often be adversarial. Even though everyone on the team is presumably working toward the same goal, often how to accomplish that goal can become a battlefield of differing opinions, each informed by the professional experience and expertise of their owners. Meetings are one culprit here. Unstructured conversations are another. The two in conjunction create fertile soil for endless discussions back and forth that can get mired in all the bad habits of interpersonal communication.
But you don’t want that. And odds are good that your colleagues don’t want it either. Happily, you have a very important tool at your disposal: the ability to make ideas tangible, and then to use that tangibility as a tool for further discussing and refining those ideas. Simply put, if you can quickly make examples of what you and your colleagues are talking about (even the sketchiest, most rudimentary examples), you can break the conversational cycle and instead help foster a constructive evolution of shared vision. How do you do this? Take a look at Figure 3.2. Model good behaviors like sketching, white boarding, and in-the-moment willingness to say “Can we draw that out?”
FIGURE 3.2
Simply sketching out things is a great starting point. You can get even more creative and have a cross-functional team participate in collaborative design exercises, which are great for loosening people up and getting the ideas rolling.
#3 Truly Listen
Closely related to the previous principle, happy teams of one have learned to see themselves as facilitators and conduits of ideas held by an entire cross-functional team. Their job, once all the information and viewpoints are understood, is to create a design solution that cleverly reconciles those tensions and produces a satisfying experience for users. But to play this role of facilitator, you have to be truly interested in other people’s viewpoints and actively engaged to understand where they’re coming from, question what you believe must be questioned, and make a good faith commitment toward achieving the right balance in the end (see Figure 3.3).
FIGURE 3.3
Following this principle often means letting the other guy do more of the talking and asking “why” whenever the opportunity presents itself.
#4 Know When It’s Good Enough
Finishing a UX project is like sweeping a floor. You get the big pile fairly easily, but those last few specks of dust are impossible to ever really clean up. You just keep cutting the dirt pile in half until finally you’re left with an acceptable amount of grime to put the broom away and get on with the next thing. Suffice it to say, the work is never really done. Having an ongoing conversation with your non-UX colleagues about what’s most important to get right and taking a “let’s show the sausage being made” attitude can turn that problem into a compelling way to get others involved. By committing yourself to the idea that it will be imperfect and that others will have good ideas for how to improve it, you start to get a feel for what “good enough” looks like (see Figure 3.4). Good enough to convey the basic idea. Good enough to have a conversation about it. Good enough to get started writing code
You will see all four of these principles in action in the two main challenges that are addressed next: dealing with people issues and dealing with organizational issues. Finally, we’ll cl
ose this chapter with a deep dive into common objections and questions you might expect to encounter, and some ways to respond to them.
FIGURE 3.4
Wise words.
Dealing with People Issues
Relationships are one of the most important means by which you can establish a foundation for UX. And yet, in a complex organization, it can sometimes be difficult to engage without getting sucked into interpersonal politics. Those people whom I’ve known to be most successful in this area seem to make themselves present and available, but without soiling their reputations or impartiality. They seem to assume that everyone has good intentions, and they try to see the situation from other people’s perspectives, rather than just their own. That may sound warm and squishy, but it speaks to one of the supreme paradoxes of our work: it’s frustrating when our efforts are impeded by others, but it’s only by working with others that we build unofficial and official support for UX. Here are some techniques that will help.
• Interview the team about how they want to engage with UX. One thing I learned in consulting is that you must work with the resources that are available. People are resources, too. You can assess what sort of environment you’re stepping into with a “Listening Tour” (Chapter 5, “Planning and Discovery Methods”). These “tours” involve one-on-one meetings with key people that quickly educate you as to their perspectives on the project, organizational norms, how they like to work, and how receptive they are to the idea of your involvement.
• Build an informal UX network. In larger organizations, it’s actually possible that there are a lot of other people who also think of themselves as user-savvy advocates. Develop communities of practice or lunchtime brown bags to pull the UX enthusiasts out of the woodwork and promote broader UX uptake within the company. Create a “Peer-to-Peer Learning Community” (see Chapter 9, “Evangelism Methods”) to create an informal community of support for UX and to educate others.
• Ask others to participate. Fluctuating support suggests that managers and colleagues need to better understand the value of UX. Invite them into your process and yourself into theirs so they get a better sense of what UX means and what value it provides. When conducting user research, invite your non-UX colleagues to come along. Offer to facilitate a “Strategy Workshop” (Chapter 5), where a cross-functional team can openly discuss opportunities to improve the user experience of your products. Also, hone your sketching skills so you can turn any meeting into a design session (see Chapter 7, “Design Methods”) and invite your colleagues to sketch as well. People love it when ideas start to become tangible, and it’s a way for you to demonstrate your leadership and help guide a conversation if it seems to be spinning. Host “Sketchboard” sessions (Chapter 7). These are generative design workshops that give your non-designer colleagues an opportunity to contribute to the design process.
• Arrange pre-meetings to avoid the “big reveal.” I was on a project once with a manager who set up pre-meetings with all of her senior executives prior to formal share-out of proposed designs. At the time, it seemed to me like a lot of unnecessary conversations, but it had a magical effect on the big meeting. When we pulled out the designs and started explaining our logic, the senior execs smiled knowingly and nodded their heads in the affirmative. There were none of the puzzled “I’m thinking about it” expressions that I was used to in such presentations. Pre-meetings help you get people to commit their support for your approach prior to going in for the big reveal, and they give your colleagues a very important gift: the time and space to really think about proposed designs and establish their own point of view.
• Use relatable language. UX is rife with jargon that can be off-putting to people from other fields. Find plain-English ways to describe what you’re attempting to do, and speak to the outcome, not just the process.
Dealing with Organizational Issues
User experience practitioners, due to their focus on both user needs and business needs, can provide a holistic view that can actually be rare within an organization. That’s particularly true if your business is siloed or heavily segmented by department. If you find that your vantage point is restricting you from looking beyond one piece of the system or process, you are ultimately hampered in your ability to consider and design for user experiences that are fluid. You may need to find novel ways to gain access and visibility across departments, deal with conflicting priorities, and make the most of insufficient or unclear resources. Here are some ideas.
• Offer to visualize requirements. Early on in the process, offer to be the design hands to help others visually convey what they have in mind and tease out their ideas. If you know that preliminary product strategy conversations are taking place, or that use cases and requirements are being written prior to UX involvement, this is the perfect moment to offer your services and suggest in a friendly fashion that the user experience of the product often benefits down the road from having UX involved in early stage efforts. By offering yourself in the capacity of early stage visualizer and prototypist, you can make a place for yourself in strategic conversations that establish the fundamentals of the product or service.
• Help others see how UX impacts the process. Make it clear how UX changes the established process. Show a “UX Project Plan” (Chapter 5) to give everyone (including yourself) a realistic understanding of the time and resources needed to work UX into the process. It can also give you a better idea of the resources and support you’ll need to do your work well. To address concerns about the amount of time or effort that may be required, create one version that shows the project timeline with UX, and one that shows it without. This also gives you a tangible way to talk about trade-offs and compromises: where you could shorten your process, where there are dependencies, and what the team will be giving up if UX is not involved.
• Play nicely with vendors. You may find yourself having to work with vendors or outside agencies from time to time. These can be analytics vendors or development vendors or, really, any kind of vendors. When it’s UX vendors, it hurts a little. If you’ve been struggling to establish a robust UX practice, having someone from outside the organization come in with the freedom and the support to do all the most interesting work can be a little frustrating. But this is a great opportunity, actually, and you don’t want to waste it sucking on sour grapes. Here are a few tips:
• Get invited to their meetings. Position yourself as someone who can share internal knowledge and bring the work they generate back in-house.
• See it as an opportunity to learn. They might have some tricks/techniques you can add to your own arsenal.
• Work with them rather than against them. A positive attitude will reflect well on you, and it shows maturity and understanding of the organization.
• Know that outside vendors never really do all the work. Often, they set a direction, but due to a limited statement of work, much work will remain to be done to extend that vision through the product. Stay actively involved so you can own and direct how the work gets executed.
• Turn the rubber stamp into an opportunity. One common problem for teams of one is getting called in only near the end of development to do a quick usability review—in others words, to rubber stamp a product. This can be frustrating and makes it very hard to suggest anything beyond the most surface changes. But you can treat this as a teachable moment to expose others to what user-centered design really entails. Do “Guerilla User Research” (see Chapter 6, “Research Methods”) to give the team an understanding of what needs to be improved that is based on first-hand observation.
• Develop case studies. Often, people don’t really know what you do, even after you’ve done it. Wrap up past projects into a tidy story. People love stories. Instead of talking about the deliverables that you produce or UX concepts in the abstract, case studies and stories give people a memorable narrative that they can envision themselves in. This is also good because it makes it easier for you to remember what you did, so you can
tell your stories confidently and on the fly. Develop a collection of “Mini-Case Studies” (Chapter 9) that you can call on or conjure up whenever you have an opportunity.
• Break bread. Turn lunch into relationship building time. Shared experiences (even minor ones) turn co-workers into allies. Getting out of the office and trying to relate on a personal level can change the dynamics of your relationship for the better.
A Success Story
James Goldsworthy is a UK-based team of one. He shares this story of the success that he’s experienced from offering to visualize requirements:
I can’t state strongly enough that I truly believe, and have success to prove, that “guided inclusion” or “guided participation” is one of the simplest and most useful tools in your armory as a UX team of one. In a nutshell, this plays on the strengths of all of the people involved. Firstly you, as the designer, get to use your skills in UX to understand and balance the user goals with business aims and requirements. For this, you will get to prove your chops as “the User Experience expert” or more succinctly “the person who makes things easy.”