2. AGENDA
About Me
Activity #1 – UX Kickoff Document
Show & Tell
– About UX @ AppNexus
– Activity #2 – Using the UX Toolkit
– How to be a PM that great UXers dread working with
– How to be a PM that great UXers love working with
– Random Tips from a UXer
– #1 Asset for a PM
Q&A time
3. ABOUT ME
Wanted to study Graphic Design at DAAP. Got into Digital Design program
instead.
Started professional career doing package design / branding
Have freelanced (thought I would love it; hated it)
Have worked at agencies (LPK, Resource Interactive, Blue Diesel)
Have worked at enterprise companies (LexisNexis, Fifth Third Bank)
Currently Assoc. Director of UX @ AppNexus
Now I really like focusing on designing complex UI applications and leading a
team of UXers
5. ACTIVITY #1 – UX KICKOFF
Using your project for this class…
Pretend you have been working on your project idea at work, where you are a
PM.
After your company’s recent prioritization process, you learn your idea made
the cut for Q3 prioritization
You have just been allocated a UX resource and need to get this person up to
speed so they can get started on your project
6. COMMON TYPES OF UX’ERS
User Experience Designers
– Specialty is designing workflows and interactions to support business
goals
User Experience Researchers
– Specialty is understanding users (field visits, user testing, etc)
Visual Designers
– Specialty is the look and feel (typography, icons, colors, etc)
Information Architects
– Specialty is structure and hierarchy (navigation, naming, etc)
7. UX @ APPNEXUS
4 Designers (each embedded in a project team/scrum team)
– Various levels of experience; different interests and strength areas
2 Researchers (shared resources amongst designers and project teams)
– 1 Researcher focuses on early-stage, ethnographic research
She answers fuzzy questions like “How do users think about “premium inventory”
Sometimes in the field, sometimes not
– 1 Researcher focuses on design validation
He runs the AppNexus Allies program (3 users per week, every Thursday)
Usually remote testing via GoToMeeting
1 Visual Designer (contractor)
What about Information Architecture? We share it!
8. MY TEAM’S MISSION STATEMENT
Understand user motivations
so that we can influence user behavior
to achieve and inspire business goals
(unofficial mission statement = use as many gifs as possible)
9. MY TEAM’S MISSION STATEMENT
Understand user motivations
so that we can influence user behavior
to achieve and inspire business goals
User Research
10. MY TEAM’S MISSION STATEMENT
Understand user motivations
so that we can influence user behavior
to achieve and inspire business goals
UX Design
11. MY TEAM’S MISSION STATEMENT
Understand user motivations
so that we can influence user behavior
to achieve and inspire business goals
Metrics and Analysis
(we are working on this)
12. MY TEAM’S MISSION STATEMENT
Understand user motivations
so that we can influence user behavior
to achieve and inspire business goals
UX Strategy
(we are working on this too!)
13. THE UX TOOLKIT
The goal of this toolkit is to develop a
shared language around UX
deliverables and tools.
We want to help you determine the
lightest-weight deliverable that you
need in order to accomplish your goals.
UX is in the problem-solving business,
and you don’t solve problems with
design documentation.
27. ACTIVITY #2
Look back at the kickoff document you created earlier
Using that information, use the UX toolkit to create a plan for your project
– You can cut it out into cards or you can just write it down
Remember to consider your timeframe, areas of uncertainty, etc.
28.
29. THE TRIFECTA
Product Owner
– Responsible for backlog, prioritization and
resource allocation
– Should be the expert on business value and
the decision maker client’s goals and
motivations
UX Lead
– Responsible for experience across the entire
“offering”
– Expert on user value and user’s goals and
motivations
Tech Lead
– Responsible for providing estimations
– Expert on our technology & capabilities
PM
UX ENG
PM
UX
ENG
LESS WATERFALL…
MORE TRIFECTA!
30. HOW TO BE THE PM THAT GREAT
UX’ERS DREAD WORKING WITH
31. HOW TO BE THE PM THAT GREAT
UX’ERS DREAD WORKING WITH
Contact UX when the project is 85% finished and ask them
to “pretty it up” before release
32. HOW TO BE THE PM THAT GREAT
UX’ERS DREAD WORKING WITH
Require detailed mocks for everything no matter what
33. HOW TO BE THE PM THAT GREAT
UX’ERS DREAD WORKING WITH
Think only about the changes you are making and not how it may impact
other parts of the user’s workflow
34. HOW TO BE THE PM THAT GREAT
UX’ERS DREAD WORKING WITH
Commit to deadlines based on your own estimate for how long it should take
UX to design “just a few changes” (Same goes for Eng.)
35. HOW TO BE THE PM THAT GREAT
UX’ERS DREAD WORKING WITH
Take the mocks and run. Don’t involve the UX person in the implementation
or validation stages
36. HOW TO BE THE PM THAT GREAT
UX’ERS DREAD WORKING WITH
Restrict access to users and don’t share what you learn from them
37. HOW TO BE THE PM THAT GREAT
UX’ERS DREAD WORKING WITH
Assume you know what users need better than they do, and ignore what they
say they want. You know best!
38. HOW TO BE THE PM THAT GREAT
UX’ERS DREAD WORKING WITH
Consider the project done when it matches the vision in your head
40. HOW TO BE THE PM THAT GREAT
UX’ERS ♥ TO WORK WITH
Respect the Trifecta (don’t forget the Tech Lead either)
41. HOW TO BE THE PM THAT GREAT
UX’ERS ♥ TO WORK WITH
Factor in User Value, not just Business Value, when prioritizing
42. HOW TO BE THE PM THAT GREAT
UX’ERS ♥ TO WORK WITH
Hold a kickoff and communicate expectations early and often
43. HOW TO BE THE PM THAT GREAT
UX’ERS ♥ TO WORK WITH
Choose the most lightweight way to accomplish what you need
44. HOW TO BE THE PM THAT GREAT
UX’ERS ♥ TO WORK WITH
Define success metrics at the beginning of the project (and
track them)
45. HOW TO BE THE PM THAT GREAT
UX’ERS ♥ TO WORK WITH
Actively participate in the design process
46. HOW TO BE THE PM THAT GREAT
UX’ERS ♥ TO WORK WITH
Know (or find out) your target users’ goals and motivations and what their
lives are like
47. HOW TO BE THE PM THAT GREAT
UX’ERS ♥ TO WORK WITH
Leave room in the process for revisions
– (Avoid the Malkovich bias, which means assuming that everyone
else uses technology in the same way you do”)
48. HOW TO BE THE PM THAT GREAT
UX’ERS ♥ TO WORK WITH
Leave room in the process for UX review/signoff
49. HOW TO BE THE PM THAT GREAT
UX’ERS ♥ TO WORK WITH
Encourage the whole team to focus on the end user
50. FINDING A GREAT UX DESIGNER
They should:
– Understand the business
– Always ask for context
– Think macro, not micro
– Design in a collaborative way
Including with non-designers!
– Be willing to abandon dead ends
– Crave contact with users
– Know what they don’t know
51. AWESOME UX TOOLS THAT YOU CAN
USE TOO!
ZURB Solidify
– Quick way to build prototypes from mocks
ZURB Verify
– Collect user feedback on A/B variations
Optimal Sort
– Online cardsorting tool with great analytics
Survey Monkey
– Surveys, obviously
ScreenHero
– Collaborative screensharing / pair designing
Silverback
– Record usability tests
52. A NOTE ON CONSISTENCY
Barriers to consistency:
– Myth that Designers hate consistency because they are “creative”
– A huge focus on being “innovative” even when what we have works fine
– Most early-stage companies have processes that make it easier to NOT be
consistent
Why consistency is worth it:
– Less design and tech debt
– More time spent on higher-impact issues
– A more consistent experience for users
53. BIGGEST ASSET AS A PM: TRUST
Your stakeholders need to trust that you will do what you say you will do
The WHY is more important than the HOW. If the team agrees with your WHY,
they will work with you to figure out the HOW
If trust is not established, or is damaged:
– They will find ways to work around you
– They will hedge their bets/estimates/recommendations to achieve their own goals
– Collaboration will not be the default mode
– The quality of the end product will suffer
Not uncommon for Uxers to be from a variety of background, much like PMs.
We get everyone from designers, to library science / research, we have engineers who come to UX, we have on my team a recent transfer from the documentation team, ets
Have any of you worked with a UX designer before in a real life example? Can you tell me how you got the designer up to speed on your project?
I often use this by having each stakeholder fill it out individually, and then we compare and see where they gaps are.
Those who have worked with UX designers before, would something like this have been helpful?
Did you learn anything new about your project by thinking about it in this way?
Am I missing anything that PMs would want UX to know?
Are there any questions where you are wondering why I asked that?
– There are other specialties but I believe these are most common
– Most of this talk will focus on working with a designer (most common in my experience)
Real World Example
AppNexus is a B2B platform that enables the buying and selling of online advertising. We design tools for buyers and sellers to participate in this marketplace.
Most of it is RTB (Real Time Bid) which means that advertisers bid on impressions in real time, i.e. when the user loads the website in their browser
Context switching is expensive
Ethnography is studying people and cultures from their own point of view
Growing field of “UX Strategy”
How to we maintain a seat at the table
Why we created the toolkit aka deliverable for humanity – we were being asked for deliverables that were unnecessarily time consuming. Our other skills and services were being underutilized.
When people ask for UX process, they tend to expect me to give them a chart with boxes and arrows on it. Well guess what, those charts are a stupid waste of everyone’s time. Every project is different. Your approach should not be one size fits all. I recommend going more modular.
This is a representation of services my team already offers
We are actively adding to it. For example, personas, querying database to identify interesting users for testing, and data analysis are new skills we are working on
Didn’t do a lower fidelity because visual design was a part of the recommendation, and also I was in a hurry and am quick at using full design tools
Shared with UX team and 1-2 PMs
We needed to cast a wide net to receive feedback because it was a big change
Narrowed it down to one concept but now wanted to show some real users
Afterwards:
Did anyone end up adding in a tool or process they were previously unfamiliar with?
Are there any other tools in the deck here that you would like to know more about?
Did anyone find that they could actually get away with a lower-fidelity deliverable than you previously thought when you made the kickoff document?
Afterwards:
Did anyone end up adding in a tool or process they were previously unfamiliar with?
Are there any other tools in the deck here that you would like to know more about?
Did anyone find that they could actually get away with a lower-fidelity deliverable than you previously thought when you made the kickoff document?
We are organized in Offering teams which are scrum teams
Annotations are also really heavy to deal with, through multiple rounds of changes. Just something to keep in mind. The more detailed you get, the more maintenance it requires.
So we know that our users do a lot of work in excel, despite the fact we have the same data in tables in our UI.
One theory was that conditional formatting was a feature our data tables lacked. We could have spent 2 months just adding in conditional formatting, but that would have been a waste.
User testing told us that they used Excel as a collaborative document where they wrote notes to each other and the file was saved on a shared server. So if we really wanted to tackle this “excel” issue, the real area of focus should have been collaborative tools
Changes often introduce unintended complications and dependencies that take extra thought. Discuss the changes with the UX designer, communicate deadlines you are working against, and let them set a realistic deadline for themselves
There is some truth to product intuition, and that’s important and I get it
But don’t act like you know your users better than they know themselves. You spend 40+ hours a week as a PM. I spend 40+ hours a week as a UX designer. You don’t have time to live through both experiences.
Acting like your users are stupid is a huge issue for me.
Where are those KPIs???
You may not always get to pick your team. But let’s be honest, over time, people find their way into working with the people they respect and enjoy.
You are either committed to the idea that a larger pool of ideas between talented people yields a better result or not. If you aren’t you’re going to have a tough time in a scrum environment.
My team discusses “UX friendlies” and “UX foes”. We know who they are.
In early stage companies, there are way way more investment areas than resources. So the biggest items always win. But that makes it really really hard to advocate for the benefits of critical features that are hard to put a $ amount on (notifications center).
One way to do this is to figure out a comfortable story ratio to pull into each sprint (3:1, etc),or do a ratio’ed value rating, or ensure your organization has a place for things like this to live. I’m currently working through this stuff at my company. No team wants to pull in usability stories that applies across the board, and are really bard to quanitfy impact wise.
The easiest breakdown is to drop the feedback loop. Don’t just assume the other person is on the same page.
Haven’t heard from them in a while? Check in!
Not what you expected? Let us know!
This one is HUGE. Yes, engineers often feel more comfortable when a mock looks 100% perfect like the end result.
Keep in mind that every second we spend doing that, we are taking time away from other projects that could benefit from more strategic thinking.
Don’t get in the habit of spoonfeeding engineers.
This
If you don’t define them at the beginning and start collecting data along the way, you will have nothing to refer to at the end of the project. Its really important to define what “Done” means, so you know when you can move on, and when you need to go back to the drawing board. As a UX designer, I want to know if we achieved what we set out to achieve.
This may be controversial, but I like to work with PMs and Engineers who aren’t afraid to jump in, pick up the marker and throw around some ideas. Its not uncommon that non-UXers come up with really creative solutions I wouldn’t have arrived at myself. I see my role as facilitating these sessions, and taking next steps from them, but a good designer is not overly protective of their work.
Also, keep in mind that designers are used to an environment of critique. Its ok if something feels off. Speak up!
Use personas if you have them. Go observe your users in their environment.
Are your hypotheses valid? Ask the users!
Is the design on the right track? Ask the users!
Is the solution sufficient for release! Ask the users!
Spoiler Alert: we usually aren’t going to nail it on the first try.
This is a huge painpoint when a waterfall process happens instead of the trifecta.
This is going to be hard to believe, but sometimes engineers put together something that does not match the acceptance critera. If UX can’t review for this stuff, it gets shipped out and then we later have to file a bug, which is unnecessary waste of effort, and provides an avoidable low quality experiences for users
Bringing in the whole team really motivates them and reminds everyone why we are doing what we’re doing
I’ve been in usability testing sessions than engineers attended. After watchign the user stuggle with a painful bug, the engineer left the room and fixed the bug over his lunch break.
It’s a huge motivator.
If you get feedback from users via feedback forms or whatnot, tell everyone.
And don’t paraphrase. Quote them directly. Increases how much people believe it / care 100%
If you have the luxury of choosing who you work with, I would suggest…
Business knowledge - high level is ok, but they should know how you make $$$ and care about making more
Context. Why is the project important?
Who are the intended users the project is targeting?
How will we measure success?
Macro/Micro - about entire workflows, not just changing small elements on the page
No what they don’t know. A myth is that you study UX design and then you become so good at UX that you can just make recommendations and decisions for Uis.
A good UX designer is not afraid to say “I don’t know”. They will said “I don’t know but I have ideas for how we can find out!”
Not every UX designer will agree with this. Some will react by saying “that’s not my job”
If you have the luxury of choosing who you work with, I would suggest…
Business knowledge - high level is ok, but they should know how you make $$$ and care about making more
Context. Why is the project important?
Who are the intended users the project is targeting?
How will we measure success?
Macro/Micro - about entire workflows, not just changing small elements on the page
No what they don’t know. A myth is that you study UX design and then you become so good at UX that you can just make recommendations and decisions for Uis.
A good UX designer is not afraid to say “I don’t know”. They will said “I don’t know but I have ideas for how we can find out!”
Not every UX designer will agree with this. Some will react by saying “that’s not my job”
Pattern Library
Its ok to break patterns, but you should have a really good reason for doing so!
Trust can be anything from trust that we will iterate on the MVP, to trust that you will provide a path for quick wins, etc
This is based on my experience with scrum teams and retrospectives