​By Patrick Neeman, Director of Product Design at Apptio in Seattle

Pragmatic Marketing was gracious enough to allow my presence in their print magazine (print!) after I did this presentation at ProductCamp Seattle. Here’s the original article in PDF format and HTML format. It was done in the theme of the UX Drinking Game, but there’s some very valuable tips. Drink on!

Being a user-experience designer can get frustrating—enough to drive a person to drink.

In 2011, I decided to share some of my frustrations with the role by creating a website, UX Drinking Game. People soon began submitting their own frustrations, and the site currently has a list of more than 1,000 of them–most of which are funny, but also sadly true.

Having worked in both product management and UX design myself, I found it interesting that so many pertain to the struggles of the two roles working together. This article is devoted to five of those reasons, and how we can work together more effectively and stay sober.

If someone says the project is so important that we aren’t following process, drink.

Understanding the user experience is a process that should be practiced when any product is built. Whether it is practiced well is another issue. When I explain the process to people, I call it “see ball, hit ball, run.”We follow a number of defined steps that allow us to succeed.

UX designers need to understand who the users are, and the resulting personas, user journeys and user stories. Then we take that research and build a design around it. After that, we build prototypes so we can set what we’re building in front of people. Then we do usability testing. And we repeat that process every two weeks.

Tip: Product management should ask UX designers to explain their process. In addition to helping determine if the designers know what they’re talking about, you can incorporate those processes into the larger product management process. Most designers will be glad to explain, and it builds trust—a key component to understanding each other.

If someone tells you that the target audience is everyone, drink.

There is no possible way to design for everybody. Understanding users is very important, and knowing who you are designing for should be the first step of every project.

For example, there’s a perception that Apple designs for everybody, but it actually designs for a very-targeted audience: people who aren’t necessarily early adopters, enjoy clean-looking products and value ease of use. The company even hires people that fit that audience, so they really understand the user and incorporate internal focus groups and usability testing.

In one of my previous roles, our target audience was recruiters and we went to great lengths to understand them.

We visited many of the company’s customers and looked at their desks. We saw them printing resumes and putting Post-it notes on the resumes to keep track of and highlight areas about candidates. We were able to design a user experience that mimicked the notes, but without the mess or potential for getting lost. That would never have happened if product management or UX wasn’t able to see the customers in their environment.

Tip: Sit down with the designer and explain who they’re designing for. Develop concise personas to force constraints that really narrow the audience. Want bonus points? Bring the designer on customer visits.

If someone says buttons should be orange and green because they test the best, drink.

One of the absolutes about UX is that there are no absolutes. Things that test well for one audience don’t test well for another. For example, everyone talks about how you should have information “above the fold” on your website. However, an entertainment company increased traffic when it forced users below the fold. So you need to test everything—and then always be testing.

In addition to more formal testing, I do a lot of guerrilla testing on people that fit the target audience within my company. I ask them what they think of a product and then follow up with questions about what works. This provides good, quick feedback without leaving the building.

You can also do guerrilla testing externally. For one usability test, we set up camp in a coffee shop with a “free coffee” sign. People were attracted by the free coffee and most of them matched the specific target audience we were trying to reach. In return for the coffee, they spent 15 minutes giving us incredible feedback. LinkedIn is another source. Look through your contacts to match personas, and then set up short Skype interviews with them.

Tip: Test early, test often and always be testing. Words, interactions and product direction all need to be shown to customers as early and often as possible, because customer feedback is king. The more you test, the more you can course correct to build a better product.

If someone says requirements aren’t needed to do wireframes, drink.

(Or, if product management asks you to write requirements, drink.) UX designers often get hired into environments where they don’t understand the domain at all. They look to product management to be the domain experts and provide answers toward understanding the user. If product management doesn’t understand the market, then it presents a hurdle for designing the application.

Product management might start with a user story that says something like “user must be able to log in.” But there are so many other variables involved. How do they want to log in? Did they want to save a login? How long does that take to expire? Each of those requirements is something that should be discussed to add more detail to the user story and ensure everyone is on the same page. I once worked for an ecommerce site, where one of the personas was a grandparent who used it only once a year—making it difficult to remember the password. So that was an important consideration in developing requirements.

For another product I managed, I knew that 40 percent of my audience wasn’t based in the United States. We didn’t have a resource to localize the application, so that requirement helped us determine that the whole application should be text based so users could copy and paste into a translator. Having that market knowledge in all of those situations changed the whole experience, because we were able to support those users.

As a UX designer, I interview product management like I would a user in that domain to better understand what they need.

Tip: Explain the requirement and the market opportunity to the designer. And write in user stories, because they’re concise and easy to prioritize. Focus on the “why” the user needs something as opposed to “what” they need, and let the UX designers focus on “what” and “how.”

If product management is doing wireframes, drink.

The product management role changes drastically from company to company. But you usually don’t manage anybody; you manage a product. So the job is to evangelize, sell and lead by delegating tasks to people with the expertise to do it. For example, do most organizations think it’s okay to let product managers code?

If you have a designer, let them design. That’s what they do best. Designers aren’t thinking of just that feature, but also how it fits within the system and that is more than the product manager may be aware of. Designers can take the design to the 80-percent level and collaborate over the final 20 percent, which is what really matters.

Tip: With 40 to 50 hours a week to work on a product, it comes down to prioritization. Doing wireframes means less time talking to customers and figuring out market opportunities. Product managers should be able to ideate, but also understand where their time is best spent.

Build trust and collaborate

The disconnect between product management and UX designers works both ways, and it all comes down to understanding the customer. The core competency of product managers should be understanding the audience and being able to communicate about them. Without that, it can be difficult for UX designers to trust that they’re going to communicate the right product to build.

Likewise, if a UX designer doesn’t work to understand the user, how can product management trust them?