There are two unicorns in UX.

Or maybe one Two-nicorn. The Two-nicorn

We all know and love the discussions about the interaction+visual design+front-end coder. As I’m looking for new work, I’m coming across a number of position descriptions for Product Manager with requirements such as:

  • Capable of constructing detailed wireframes that optimize user experience
  • Significant experience with user testing
  • Use web analytics, user surveys and UX best practices to identify improvements
  • Build product prototypes and mock-ups

Now I know this isn’t a new thing, see the references at the bottom. But what got me thinking about it again was a recent article Alan Cooper wrote for FastCompany, about the “Much Rumored Death of the Design Firm”. He’s talking about the trend of corporations bringing design in house; most notably Capital One buying Adaptive Path. He argues that this might be more efficient, but it loses the outside perspective (of course Cooper is one of the biggest design consultancies out there, what else would he say?).  But the key nugget I got was this:

And yet corporate behemoths still confuse what designers make with what designers do. Twenty-five years ago, we realized that wireframes and prototypes were actually far down the line, in value. The hard problem wasn’t figuring out how screens should behave. The hard problem was figuring out what problem is worth solving—then making sure everyone is on the same page. Put another way, if you have hundreds or even thousands of employees, the only way to get them to work together coherently is a single, unifying vision. That’s exactly what interaction designers do. Today, user experience designers, gifted with an impartial perspective, can readily provide critical strategic insights in every stage of the product development process.

I can’t agree more, I’ve always felt that design is problem solving, and have taught that human centered design gives us the tools to innovate. But when it comes down to who defines the problem, I think the newly in-house designers will meet resistance on which role owns the product requirements.  Alan’s probably more correct that product advice from an outside party, particularly one you’re paying a bunch of money to, is received better than coming from internal designers. That has been my experience every time a company I worked for engaged with a consultant–they end up working with us (the UX team) and then presented our ideas back to our managers on their letterhead…and got rave reviews.

In my last two roles, I was brought in as the first UX professional. So before I got there, product design was being done by some mixture of the product manager and software engineer. Some PMs were happy to drop the design part, others held on.  Same thing with the engineers. This is where the UX designer’s collaboration and negotiation soft skills, plus ego-less humility, earn their paycheck.

I’ve worked with requirements gathering throughout my career; as a project manager, working with business analysts (who work mostly internal projects, vs. customer facing), working with project marketing managers.  Whoever owns the requirements owns the product. The way I worked with PMs was to help them visualize and refine their requirements, run them through the persona lens and prioritize in terms of task flows (if they can’t do X, don’t worry about giving them Y).  And the best way to get buy in is to collaborate with both PM and Dev at the same whiteboard sessions; otherwise you’re just going to be running back and forth between them.

Cooper is only the most recent to advise that UX is less about making screens than defining the problem space. There has been a trend to push UX more into business strategy, which makes sense because of UX’s deep understanding of the user — though maybe not customer…sales still wants to talk to marketing and not UX (and development when the customer can’t get the product installed and working).

I’m going to explore more of how UX and Product Marketing work together, but for now here’s a reading list:

Leave a Reply

Your email address will not be published. Required fields are marked *