Presenter(s):  Cindy Alvarez

Date-Time:  August 15, 2019 @ 10:20 AM

Key Takeaways

Enhance PM-UX collaboration by focusing on a mutual understanding of the customer problem and desired outcomes.  Bring customers into the design process early, develop a shared language, and encourage open, honest dialog to achieve the best results.

Notes

Cindy Alvarez works at Microsoft and brings both PM and designer experience and perspectives to her presentation.  She opened the subject of her talk by recalling the number one thing that often holds us back:  people talking past each other.  She framed this observation with the “Curse of Knowledge,” that in communicating it is hard for us to remember/realize that others don’t have the same background knowledge, which makes it hard to see why they do not understand our ideas.  This is a cognitive default for everyone and not a reflection of bad intentions.  Because this is a default for us all, we all need to think about how we explain [our ideas] and the information we have without being condescending.  Regardless of our role, this is about getting the best out of the people we work with every day in creating great products.

Fundamentally, we all have different ideas in our head – even toward things we may be working together on for extended periods.  And our coworkers do not always comprehend our ideas in the same way we believe we’re expressing them.

Alvarez offers some examples of this dynamic and techniques to enhance communication.

Alvarez mentions what is probably the #1 pet peeve of just about every designer she has managed:  a PM offers to sketch out what they are thinking and asks the design team to just make it pretty.  What a designer hears is the PM does not trust them to problem solve and so does all the “hard work,” relegating the design team to visual polish.  From the PM’s perspective, they may not know how to articulate what they view as a complicated problem and resort to products or things they have seen elsewhere to convey what they want.  Both sides are annoyed in the exchange.  As a designer in this case, the best response is to allow the PM to sketch it out, then have a conversation about “why” that is what they are thinking.  For example, “I see you put something in a big area over here… why is it in that place of prominence?  How important of an action is that?  What do you want users to do here?  This looks like what Facebook is doing …what is it about what Facebook is doing that seems like it will work for our process as well?

Alvarez encourages PM’s to focus on articulating the problem they want to solve rather than wading into design specifics.

She also notes that from a designer’s perspective, it is tempting to share the thoughts behind a concept, such as the idea board used or color theory that went into color palette decisions.  These are often unimportant, or make no difference, to the PM.

Alvarez encourages designers to bring the PM into the design process early to achieve a better result.  Explain to the PM why this will yield better results.  Ask the PM for the best time to bring them in on the project.   For example, the designer might say to the PM, “Think about the last time we worked together and the information we provided at the start… how useful was that?  What research are you doing?  Are there activities we can/should do together (i.e., website research)?”

A PM’s focus on specific design elements often signals underlying concerns.   For example, “Please make the button bigger” can signal a deeper concern for the PM who wants a desired action from the user.  Ask why the button needs to be bigger to understand their underlying concerns.

For PM-designer disputes, remember the customer is right and the real arbiter of which designs work best.

Designers notice minor details, like a misalignment or poor color combination in a design.  They tend to use time-tested (and usability-tested) tools and practices they know work, like style guides and modular designs and design libraries.  Conversely, PM’s are not concerned with, or may not notice, these considerations or processes.  Whenever a PM suggests a modification to workflow, it risks breaking the normal pattern.  In this case, inform the PM you have something (i.e., a time-tested or proven process) that works, that they are asking the design team to add risk to the project, and look to understand “why” – i.e., what is the PM’s concern?  Sometimes it is okay to take on risk.  At other times, doing so may be inappropriate if your team is in a hurry or they are already stressed out.  Think about what taking on risk will cost us and what you stand to gain.

Alvarez discussed pitfalls in design review/critique and their correlating solutions.

During design review, it is easy to diminish meeting value by focusing on tiny adjustments to mock ups.  People do not always know what to critique and tend to jump on the obvious or the easiest things to think about, mentally setting aside more difficult but important considerations.  This can derail the conversation, sending it down the wrong path.  If this happens, realign expectations.  Acknowledge imperfections in design and refocus attention on desired outcomes with the product.

In design review, the most important thing a PM can give a designer is, “This is the outcome I am hoping for …and this is the likelihood it [a user action] will happen.”   Walk me (PM) through how you (the designer) see that outcome happening… then let’s compare notes on how likely we think we are to get the desired outcome.

As a PM, a useful default response to a design that does not meet expectations (especially when looking for things to talk about) is ask, “How can I give you the most helpful feedback?”  When experiencing poor expectation alignment – a design that is “way off” from expectations – as a PM, ask “How can I best help you?” “What’s the best way I can give feedback?” “What will help you the most?”

As designers, generate useful feedback by focusing the conversation.  For example, “On this page, what is the one thing you are concerned about, and how do we make that one thing more obvious and attractive in a way that will achieve the desired effect?”

Every design team wants to continue designing – this isn’t good enough yet.  On the other hand, the business is working on a deadline – we don’t have more time.  Focus on ROI.  What will making a design change do to bring about a desired outcome?  Can you articulate how a change will enhance the user experience?  Will a change make it “10% better,” or is there some fundamental flaw in which it is difficult to articulate that a design just will not work?  From her experience hiring full-time copy writers, Alvarez notes that bringing the copy writers in early solved a ton of interaction flow problems down the line.

When working in the problem space, expect some level of healthy conflict.  When everyone is nodding politely, you are going to have mediocre products.  To enhance open, honest dialog she suggests creating a shared language – words or short phrases that everyone understands.  Shared language offers a frame of reference for navigating thornier discussions.

She suggests writing these questions on a white board to facilitate open, direct dialog in a meeting:  The customer needs to solve _______;  the customer is likely in this state of mind: _______; if the customer only does ONE thing, we hope it is _______; and what else is competing for their attention?  What do we most want the customer to do here?  Participants can then point to something – a key word or desired outcome (shared language) – to make a point or tactfully address a sensitive subject.

Alvarez reminds us again the customer problem comes first.

She emphasized the importance of direct and honest feedback during design review and advocated empowering people to feel unafraid about speaking up.  She cited Japanese car production as an example, where anyone on the assembly line can “pull the cord” (halt production) if they see a problem.  It is our duty as designers to pull the cord if we see something wrong.  Empower your people to do so.

Alvarez discussed the 30/90 concept in design review.

In a 30 percent feedback review, you still have time to adjust.  As designers, set the expectation up front that the focus is on broad concepts and core use cases – not fonts or color choices (which can be changed anytime).  It is not too late to scrap the whole thing if there are fundamental flaws or the concept is not working.  This is a valuable time to bring in an engineer for feedback on engineering and workflow issues.  This is not the right time for upper management participation in design review.

In a 90 percent review, focus feedback on details, visual polish, copy, and consistency.  It is too late for major changes.  This is not the time for significant course changes.

Listen and think it over before responding to critical feedback.  Repeat a customer’s comments/concerns back to them.  While this may feel condescending, it is really okay.  If you are misaligned on expectations, take some time to think about the feedback rather than attempting mock ups on the fly.  Most people do not do their best on the spot.  Even 15 or 30 minutes can be enough time to step away, consider feedback, and reconvene.  One best practice:  gather feedback, go to lunch, then reconvene to discuss.

Misalignment of expectations in design ideas often comes down to different understandings of the problem.

The answer is not always in the room.  If necessary, call a colleague to get another opinion or perspective.  And you do not always need extensive usability testing to gain important insights.   Sometimes usability testing with a coworker or two is enough.