By Heather Searl
Dear Product Manager,
Here we are at the start of another project and, while I love working with you, there are a few things I’d like you to see from my point of view.
First off (and this is a biggie), you are NOT the target user.
I know you know our domain inside out, and the presentations you give about the technology are impressive. I know you are passionate about our product and that you live and breathe everything related to our domain.
The problem is you know, and care, too much. Most of our users are not as passionate about our products as you are. Yes, I know there are some and I know they sought you out at the last user forum to share their ideas with you.
But most of our users aren’t like that. They use our product to accomplish a goal so they can move on to the next thing. They don’t understand all the industry jargon that rolls off your tongue with ease, and they don’t care about all the flash and wiz-bang of the latest and greatest technology advances.
My point is that we can’t design a product that is perfect for you. We need to design a product for the typical user.
Secondly, you can’t do it all.
Yes, you are ultimately responsible for the success of this project and that’s a lot of pressure. I understand why you want to talk to all of the customers, document all of those discussions, analyse the results, and decide what tasks to use in usability testing. I get that you want to make sure everything is done right, but you can’t do it all.
You have too many budget meetings to sit through, sales projections to compile, stakeholder suck-up lunches to attend, and a million other things that have to be done as part of your day.
Let me help. I know that it takes as long to write up the summary of a customer interview as it does to do the interview. I’ve done it many times. I also know that if it isn’t done that information will be lost.
I’m not suggesting you hand over all of the customer insight activities to me. Oh no. You HAVE to be part of that. It’s crucial that you understand our users inside and out. Which kinda’ brings me to my next point.
Third, you and I shouldn’t be the only user experts on the team.
I know it’s in your job description and mine that we talk to end users and understand their needs. But the developers, QA testers, tech writers and everyone else will make better decisions if they fully understand the user’s needs as well. Let’s take some of them along with us on our next customer visits, and after that, let’s put together some lunch and learn sessions to share what we learned with everyone else.
Yah, I know we’ll have to drag some of them (especially the developers) with us kicking and screaming. But I promise they’ll come up with some great ideas when they are working with firsthand knowledge of our end users instead of making decisions by guessing at what end users do and don’t do with our product.
And lastly, please, oh please, focus on the WHAT and not the HOW.
For example, don’t create full wireframes for your concept and requirements documents. These documents should tell us what to build, not how to build it. When you put too much detail about how things should look and work into these documents you lock us into a design direction when the project has barely started.
Put together some high-level sketches so everyone can visualize the product – but don’t go too far. Some of our teammates are pretty literal, and they are going to fight against every change to your original idea no matter how much sense those changes make.
If you are worried that I or the rest of the team will go off on a tangent with the design, don’t be. We WANT you involved in our brainstorming sessions and we WILL get your approval on all designs.
Speaking for myself, if I don’t do detailed design reviews with you or I don’t give you time to think about the workflows and interactions that I’ve put together, call me on it. This is a collaborative project after all.
Please understand that I’m not pointing these things out just to make my job easier (although that is part of it). It’s more about working as a team. The more in-sync we are about what our users need, and the more we understand where each of us is coming from, the stronger the end product will be.
Let’s talk. In fact let’s make sure we are talking a lot more than we are now.
Your UX Expert
Tweet this: Dear Product Manager – 4 things your UX expert wants you to know http://wp.me/pXBON-40D #prodmgmt #ux
Heather is a user experience consultant and writer who believes in doing everything from a user-centric point of view. She has more than 20 years working in high tech and is well-versed in helping product management and development teams get to know their customers, understand usability issues and turn these insights into design ideas and innovations. Heather can be reached at www.commconsulting.com or on Twitter as HeatherSearl.
Photo courtesy of Jeanne Menj via Flickr