Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

August 08 2013

13:30

Where UX Comes From

Earlier this week, we interviewed Leah Buley, author of the new book UX Team of One. Leah talked about her own experiences as a UX team of one, and how her approach has changed over time. Now we are very excited to present an excerpt from the book itself.

As a team of one, knowing the history of user experience helps you reassure people that it’s not just something that you dreamed up in your cubicle. If I were to sum up the history of UX in a few short sentences, it might go something like this: villains of industry seek to deprive us of our humanity. Scientists, scholars, and designers prevail, and a new profession flourishes, turning man’s submission to technology into technology’s submission to man. Pretty exciting stuff.

UX has a long and storied history that intersects with other business, design, and technology developments that your colleagues may be familiar with.

Now here’s the longer version. User experience is a modern field, but it’s been in the making for about a century. To see its beginnings, you can look all the way back to the machine age of the late 19th and early 20th centuries. At that time, corporations were growing, skilled labor was declining, and advances in machine technology were inspiring industry to push the boundaries of what human labor could make possible.

The machine age philosophy was best exemplified by people like Frederick Winslow Taylor and Henry Ford, who both pioneered ways to make human labor more efficient, productive, and routinized. But they were criticized for dehumanizing workers in the process and treating people like cogs in a machine. Still Taylor’s research into the efficiency of interactions between workers and their tools was an early precursor to much of what UX professionals think about today.

Frederick Winslow Taylor, the father of Scientific Management, pejoratively known as Taylorism.

The first half of the 20th century also saw an emerging body of research into what later became the fields of human factors and ergonomics. Motivated by research into aeromedics in World War I and World War II, human factors focused on the design of equipment and devices to best align with human capabilities.

By the mid 20th century, industrial efficiency and human ingenuity were striking a more harmonious relationship at places like Toyota, where the Toyota Production System continued to value efficiency, but treated workers as key contributors to a continually improving process. One of the core tenets of the Toyota philosophy was “respect for people,” and it resulted in involving workers in troubleshooting and optimizing the processes that they were a part of. As one example, workers at Toyota factories could pull a rope called the Andon Cord to stop the assembly line and give feedback if they saw a defect or a way to improve the process.

Around the same time, industrial designer Henry Dreyfuss wrote Designing for People, a classic design text that, like the Toyota system, put people first. In it, Dreyfuss described many of the methods that UX designers employ today to understand and design for user needs, as shown below. In Designing for People, Henry Dreyfuss writes “when the point of contact between the product and the people becomes a point of friction, then the [designer] has failed. On the other hand, if people are made safer, more comfortable, more eager to purchase, more efficient—or just plain happier—by contact with the product, then the designer has succeeded.”

At the same time, some interesting parallel movements were taking shape. A small handful of academics were doing research into what we now describe as cognitive science. As a discipline, cognitive science combined an interest in human cognition (especially human capacity for short-term memory) with concepts such as artificial and machine intelligence. These cognitive scientists were interested in the potential of computers to serve as a tool to augment human mental capacities.

Dreyfuss created Joe (and a companion diagram, Josephine) to remind us that everything we design is for people.

Many early wins in the design of computers for human use came from PARC, a Xerox research center founded in the early 1970s to explore innovations in workplace technology. PARC’s work in the mid-70s produced many user interface conventions that are still used today—the graphical user interface, the mouse, and computer-generated bitmap graphics. For example, PARC’s work greatly influenced the first commercially available graphical user interface: the Apple Macintosh. The term user experience probably originated in the early 1990s at Apple when cognitive psychologist Donald Norman joined the staff. Various accounts from people who were there at the time say that Norman introduced user experience to encompass what had theretofore been described as human interface research. He held the title User Experience Architect, possibly the first person to ever have UX on his business card. Norman actually started out in cognitive psychology, but his writing on the cognitive experience of products, including technological products, made him a strong voice to lead and inspire a growing field. According to Don Norman, “I invented the term because I thought Human Interface and usability were too narrow: I wanted to cover all aspects of the person’s experience with a system, including industrial design, graphics, the interface, the physical interaction, and the manual.”

Norman’s book The Design of Everyday Things is a popular text that deconstructs many of the elements that contribute to a positive or negative user experience. It’s still pretty much required reading for anyone who is interested in UX.

With the rise of personal computing in the 1980s and then the Web in the 1990s, many of these trends converged on each other. Graphical user interfaces, cognitive science, and designing for and with people became the foundation for the field of human-computer interaction (HCI). Suddenly, more people had access to computers and, along with it, a greater need to understand and optimize their use of them. HCI popularized concepts like usability and interaction design, both of which are important forebears to user experience. In the Internet bubble of the mid and late-1990s, new jobs with titles like “Web designer,” “interaction designer,” and “information architect” began cropping up. As people became more experienced in these roles, a deeper and more nuanced understanding of the field of user experience began to develop. Today, user experience is a rapidly growing field, with undergraduate and graduate level programs being developed to train future generations of professionals to design products for the people who use them.


Enjoy this? Get the full book at Rosenfeld Media and use code UXBOOTH for 20% off!


The post Where UX Comes From appeared first on UX Booth.

August 06 2013

13:30

One to Many: An Interview with Leah Buley

Everyone’s been there: “going it alone.” Learning, prodding, and making sense of a problem – all in complete isolation. Sometimes the hardest thing in that situation is knowing that, regardless of whether or not we succeed or fail, we’ll have no one to share that outcome with. And that’s exactly what makes Leah Buley’s story so compelling. In her latest book, UX Team of One, Leah explains how we can beat the odds and feel that sense of camaraderie even when we’re the only person ensuring that our organization practices design in a user-centered way.

I first heard of Leah Buley from her presentation at UX Week 2008 titled, not surprisingly, UX Team of One. And at that time I could certainly empathize: I worked as the sole – and therefore “lead” – interaction designer at an agile development consultancy. By the end of the presentation I couldn’t help but share it with my colleagues and friends.

You likely saw something about it on UX Booth’s Twitter feed. Shortly thereafter, Leah received a book deal with Rosenfeld Media, giving her a platform to bring her message to the masses (well, the print-based masses).

Recently published by the gang over at Rosenfeld (PS: use code UXBOOTH if you decide to purchase a copy), I didn’t hesitate to reach out and ask Leah what I felt to be pertinent questions. Namely, it’s been four years since her presentation. That’s quite a while in terms of our industry. And not only that, but Leah’s made quite a transition herself in that time – from being a team of one to being an in-house designer at Intuit. Read on to hear Leah’s thoughts on her transition as well as a chance to win a copy of your own!

Congratulations on the book, Leah! To even begin to codify user experience design is an incredible feat. Now that you’re done, will you ever look at our craft the same way?

Thanks so much, Andrew! It’s pretty thrilling to have a book out and alive in the world. Truthfully, it took me so long to write it that I was secretly worried that its time might have passed. But the feedback has been really heartwarming, and it would seem that there are still lots of “UX teams of one’ in the world. So, phew! Thank heavens for that.

As for our craft, I don’t know. I feel like the more I learn, the less I know. When I look at the book, I realize how much is not included in it: responsive design, service design, lean UX, augmented reality, big data, flat design, the internet of things, retrofuturism, flying cars (well, self-driving, at least). There are so many new approaches and methods and possibilities emerging all the time. (Thankfully! That’s what keeps it interesting.) that I wince a little when I think about everything that’s not included. But it’s ok. When that happens, I take a deep breath and pour myself a glass of wine and reassure myself that my goal wasn’t to be comprehensive but rather to capture a mindset that can help user experience professionals win support and influence better work. I hope I’ve accomplished that.

You’ve made quite the transition since your initial presentation, switching companies as well as roles. How has your approach changed over the years?

When I started doing UX work I was full of misdirected bravado. I had this idea that UX designers should be able to fight for what’s right for users. I believed my job was to come in with guns blazing and challenge teams to reinvent their products.

I think the biggest change to my approach is now I focus less on the fight and more on the process. Consequently, I have less bravado and more innate confidence. I’ve become more confident because I’ve been through the research and design process repeatedly enough to know that it works. I have trust in the process. There seems to be a moment on every project where I feel like the solution is hard and unknowable, and I can’t possibly imagine how we’re going to figure out what to do. But I just let myself keep marching forward.

It sounds weird but I liken this to walking off a cliff. I walk off a cliff – into the abyss of the problem – and trust that insights gleaned from observing real people will point the way. And somehow they always do. I used to be afraid to let my colleagues know that I was in the abyss. Now, I try to be transparent about it; I try to help other people get comfortable with being in the abyss, too.

I’m actually leading a really complicated design project right now. The goal is to bring consistency to a user experience that connects a bunch of disconnected products while also bridging brand and product strategy and UX. It’s got, like, four dozen stakeholders. It’s a beast. Some days are really hard. Those are definitely falling-off-the-cliff days. But even on the hard days, I can remind myself that 1) I know how this process works and I just need to keep moving ahead, and 2) in the end we’ll have something markedly better than where we started. And I know this is true because I’ve been through enough messy UX projects to know that the user-centered design process will get me there.

You’re presently a design strategist at Intuit – a company who, I imagine, employs quite a few UX designers! In other words, you’re hardly a team of one anymore. What philosophies and practices mentioned in your book apply “UX teams of many” and what new techniques/practices have you learned?

I have a great job. I get to work on ambiguous design problems that cut horizontally across a large organization with a lot of vertical structures. Sometimes I focus on product-oriented, customer-facing design problems—things that affect our products – and sometimes I focus on process-oriented, internal-facing design problems – things that affect how we work. In both instances, the key to success is (and always will be) people. My job is to find ways to bring everyone along for the ride. In that way, actually, all the philosophies and practices from the book still apply. Intuit has an extremely large user experience community, and yet I still feel like a UX team of one. And that’s not because I’m unsupported, it’s just the nature of working with a cross-disciplinary team, which just about every UX professional does.

I’ve also add a lot of new techniques to my toolkit that I picked up at Intuit. Intuit has this really phenomenal program called the Innovation Catalyst. (Not invented by me, alas. Here, I’m just an eager student.) Basically, they train hundreds of people throughout the company in design thinking skills, and then send those people back into every branch of the organization to act as facilitators and coaches for design. The Innovation Catalyst program teaches loads of methods that run the gamut from customer research to generative design to rapid prototyping and experiments. One of my current favorite methods is this poster-sized canvas called the NEXT tool. Using the NEXT tool, teams answer some really interesting questions about their product vision, their “leap of faith” assumptions, and various hypotheses that they ultimately need to test with users. The NEXT tool is really complementary to the Lean Startup approach.

Another, simpler tool that I learned at Intuit that I really love is called a brainstorm box. If you’re doing a team brainstorm on product ideas, just put a box in the middle of the table with thought starters written out on sticky notes. If you get stalled, pull out a sticky from the box and, voila, brainstorm re-ignited. Some example thought starters: “What if it had to be purely mobile?” “What would be the opposite of our last idea?” “What would get us fired?”

Many people who find themselves as the sole UX professional in a company struggle with how much they need to “teach” the rest of their team. What are the essential principles a UXer should teach his or her team in order to be successful?

First and only principle: go watch some users. Actually, I wouldn’t even call it a principle. Call it a suggestion. “Hey, let’s go watch some users.” All knowledge derives from that. The ability to envision the product from a user’s point of view is like a muscle that can be strengthened. And like a muscle, it responds well to repetition. Jared Spool has written about user exposure hours and the high correlation between the number of hours a team spends watching users and the overall quality of their product. If you can get your team to take the time to actually watch real people in action (whether it be a usability test, exploratory research, or even lean-style rapid experiments) they will be strengthening that muscle. This makes the whole team better informed about user needs. But just as importantly, it will make them more curious and empathetic about users in general, which is how a fan of UX is born.

The second half of the book is comprised entirely of user-centered design activities and methods and serves as a wonderful resource for anyone working in UX. What gave you the idea to structure your book this way?
The structure of The User Experience Team of One was inspired primarily by my deep love for reference books. I covet and collect reference books of all kinds—cook books, dictionaries, craft and activity books. In my first job out of school, when I was still muddling my way through HTML and CSS, a co-worker gave me a copy of O’Reilly’s Javascript: The Definitive Guide. It was like my bible, the first reference book for my professional career. I loved its structure—this highly glanceable, easy-to-peruse manual for making interesting things. Ever since then, I’ve loved and looked for books that have clear, reassuringly repeatable structures. Surprisingly few UX books have that ’cook book’ quality. Two books that do this well are Universal Principles of Design and Universal Methods of Design, both of which contain one utterly complete, bite-sized thought per page.


That’s a wrap, guys! Thanks, again, Leah, for taking the time to share your thoughts with readers.

As for the giveaway, here’s how that works: just follow @uxbooth on twitter and leave a comment on this post answering the question: “What user-centered design technique do you rely on most frequently and why?” Be sure to include your twitter handle in your comment and to leave it before this Thursday at midnight PST. We’ll contact three lucky winners over Twitter. Good luck!


The post One to Many: An Interview with Leah Buley appeared first on UX Booth.

June 11 2013

13:30

A User Experience Business of One

My initial foray into UX frustrated me. Although my job title suggested that I made products easier for end-users, I actually spent a lot of time selling user experience to clients, stakeholders, and colleagues. I knew I needed to broaden my focus, but I didn’t know where to start. And that’s when I discovered The Business Model Canvas.

The story behind what we today know as the Business Model Canvas is an interesting one. Originally created as a conceptual framework for Alexander Osterwalder’s PhD project, it later became the subject of an entire book called Business Model Generation, co-authored with Yves Pigneur. Today, both the book and the canvas allow those of us without business training (including yours truly) to better understand sustainable business practices.

My application of the Business Model Canvas is likely atypical, though. Instead of using the canvas to aid clients, I wondered: what if I looked at my role as a business itself? After all, I need resources to operate (a budget, my supervisors’ time, my colleagues’ expertise); I have customers (people to whom I provide value); I have costs (my time, materials, stress). Could understanding all these things help me design more efficiently?

Introspection

To follow my logic, it’s useful to first understand how the business model canvas is laid out.

Personal Business Model Canvas Worksheet. Source: http://www.businessmodelyou.com

Divided into nine parts, it includes:

  • Key partners – Who supports you?
  • Key activities – What do you do to create value?
  • Key resources – What do you require?
  • Customers – For whom do you create value?
  • Value – What problems do you solve? What needs do you address?
  • Channels – How do you communicate your value?
  • Customer relationships – How you interact with customers?
  • Revenue – What do you get?
  • Costs – What do you give?

Using the original book’s sequel (Business Model You) as a guide, I thought critically about my role within my organization. Rather than rigorously weigh all nine considerations here, though – something for which the book is much better suited – let’s look at three in particular: customers, value provided, and key channels.

Customers: not just the end-user

While it’s relatively easy to assume that our customers are the same as the customers of the company for which we work, this isn’t strictly the case. As the book defines them, customers are anyone for whom we’re creating value, including:

  • Clients and stakeholders, who rely on us for our expertise;
  • End-users, who rely on us to represent their needs;
  • Software developers, who rely on us to clarify interactions and interfaces;
  • Other members of the design team, who rely on us for user research; and, finally,
  • Colleagues in quality assurance, who rely on us for specifications and clarifications.

Notice that end-users are only one item on the list. Notice, also, that colleagues are customers too. Couple this with the fact that we practice user-centered design and it becomes increasingly obvious why it’s part of our job to consider our team and their benefit.

User experience design isn’t limited to human-computer interaction; it includes human-human interaction as well. Before filling out the canvas, I instinctively knew this – that my responsibility did not end with “end users” – however, I didn’t know what I could do to serve them more effectively. That’s when I considered value propositions.

Value: not just deliverables

Just as clients tend to think of our work as deliverables, designers often think of our work as different activities: holding workshops, conducting interviews, writing scenarios, making wireframes. Yet one of the biggest mistakes we can make is to assume that the activities we conduct are the same thing as the value we provide.

When I sat down to determine the value I provided, I was stumped. I could only think of – dare I say it – clichés. Yeesh. “Making things easy to use,” “generating empathy,” etc. I needed to break it down.

My actual first draft of value provided – this describes what value my role provides, irrespective of activities.

To determine the value I provided to others, I started with a list of what I was currently doing at work: conducting user interviews, diagramming mental models, building low-fidelity prototypes, tracing mind maps, putting together personas. Next, I considered my reasoning for each activity. Why did I interview project stakeholders?, for example. Then I asked myself: So what?

Repeatedly. Until I hit something.

This resulted in the following table:

Activity I do this to… So that… User interviews Build empathy for customers We avoid building a product “for everyone” Mental Model Diagram Determine our feature fit Stakeholders can see gaps Low-fidelity prototype Share the vision Everyone can agree to the product direction, sooner

Does interviewing customers before designing reduce the risk of product-market mismatch? Does one particular kind of prototype make it easier to adapt the design vision? You don’t know until you think it through.

Next, I considered the value provided by each of these activities for my customers:

Activity Value to client Value to developers Value to designers Mental Model Diagram Risk reduction. This helps clients see gaps in their offering (where they might lose competitive edge or profit) Convenience. This allows developers to more easily write user stories by providing user motivations. Cost reduction. This provides designers with context so they can more quickly make design decisions.

Notice how the value differs depending upon the customer. Finding the right way to phrase the value we provide for a given audience is, simply put, a user-centered way of thinking. It requires asking the right questions and actually listening to the answers. In this case, we just have to add business constraints, and organizational fit to our list of topics to listen out for.

Communicating this way signals that we have a wide skillset. When I sit down at a meeting, I sometimes sense that a new client considers the role of designer to be analogous to that of an aesthetician: the person responsible for adding “color” to an interface. Communicating my role in terms of value signals that I think broadly. It raises expectations.

Key channels: stop waiting for recognition

The third realization I had when filling out the canvas was that I was often waiting for people to become curious about what I did instead of communicating my own value. Channels are the methods we use to communicate to customers. They afford three things:

  • Awareness of the value we provide. They allow us to spread the word about what we can offer (and listen to others to see where its needed most).
  • The value itself. Channels allow us to deliver the value we promise.
  • Customer support after we’ve delivered our value.

Most importantly, this exercise helped me realize that I needed to start doing things resonated most with each of my customers. To that end, I might:

  • Demo something I did in the company demo meeting and talk about the value to developers
  • Share a usability test recording
  • Make a cheat-sheet of my activities’ benefits for the sales team, or
  • Write articles about our process for the company website so clients could learn more about what UX means for business

Making the sale

To there you have it: the business model of a UX Team of One. Selling UX – especially within an organisation – is a complex topic. Whole books have been written on the subject. The three insights above resulted from reconsidering my value and what I could improve on.

I eventually came to realize I needed a plan for communicating value to different groups of people I work with, and that I had to stop waiting and start doing. I also came to accept that there were areas in which I needed help – such as translating my reasoning for UX activities into business terms. I’m currently working on writing out all these benefits, with the help of an experienced consultant.

The business model canvas hasn’t made my job any easier to do, but it has helped me prioritize. Communicating value is a journey. I recommend filling out the canvas for yourself and seeing which boxes are most difficult to fill (yours might differ from my 3 key learnings) or with which you could use some help. I have no doubt you’ll find the result rewarding.

Related resources

On UX within organizations
On UX benefits
On the Business Model Canvas

The post A User Experience Business of One appeared first on UX Booth.

Older posts are this way If this message doesn't go away, click anywhere on the page to continue loading posts.
Could not load more posts
Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
Just a second, loading more posts...
You've reached the end.
(PRO)
No Soup for you

Don't be the product, buy the product!

close
YES, I want to SOUP ●UP for ...