The User Experience Team of One. Leah Buley

Чтение книги онлайн.

Читать онлайн книгу The User Experience Team of One - Leah Buley страница 14

The User Experience Team of One - Leah Buley

Скачать книгу

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.

      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.

Image

       #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?”

Image

       #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).

Image

       #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 close this chapter with a deep dive into common objections and questions you might expect to encounter, and some ways to respond to them.

Image

Скачать книгу