In my two years in the enterprise UX space, I’ve gained a number of soft skills that they didn’t prepare me for in college. At no point in my undergrad or masters programs did my instructors tell me that I’d have to tell people no. Learning that lesson took real on-the-job experience. Today, I’d like to talk about the relationship between product managers and UX designers.

The Relationship

During my time as a Senior User Experience Designer, I’ve worked closely with several key stakeholders for each of my projects. Typically, I work with one to two product managers per project. The way that exchange happens looks like this.

  1. Product brings new feature to UX.
  2. UX examines feature and decides how to implement it.
  3. UX designs the feature and takes it through various governance reviews (accessibility, legal, design, etc).
  4. UX delivers to Product.
  5. Product takes the flow and designs to dev to be built.
  6. Dev builds the feature.
  7. Dev demonstrates the feature to UX for final approval.
  8. Feature is pushed to production.

This process works like a well-oiled machine when product brings a well-organized plan to UX for collaboration. In an ideal world, every feature would involve UX in the very early stages of the product development life cycle. Unfortunately, this doesn’t always happen the way we want it to. In my experience, the trouble happens between steps 1 and 2 in the above list.

The Problem

I find that my team often does pretty mediocre work when product is prescriptive rather than descriptive. Unfortunately, some of my product partners think of UX as a “screen factory.” In their mind, they’ve already decided what the feature is going to look like. They just need UX to make a click-through prototype to send to dev. Easy peasy, right? Not really. Typically, this creates a lot of friction between product and UX. I’d like to examine a great example that happened to me this year.

Product wanted to add a feature to an admin dashboard. They wanted a temporary warning to alert the administrator that any changes made to a certain field would not be realized because of the special state that was currently affecting the user. In simple terms, two users may accidentally have the same compound identifier and therefor changing one of their data points would change the other’s as well. Product said that, to implement this feature, they wanted an error message to display on the data field in the edit flow. I pushed back saying that we only use error messages to indicate that the user has made an invalid entry and cannot continue until that entry is resolved. The problem is that product insisted that this was the only way it could be done. They said they only had enough capacity in the upcoming sprint to perform this implementation. We went back and forth on this for nearly a week until I told them that they would need to go to my director to get this approved. The deviation from the style guide was so dramatic that I didn’t feel comfortable putting my name on it - even with product’s signature on the design. Another week later, product came back and folded. We had to get the product manager’s manager involved to get the feature updated. It took over two weeks longer than it needed to as a result.

The Solution

My team does our best work when product brings us in early. And I don’t necessarily mean early from a time perspective (though that’s greatly appreciated too). UX truly shines when product involves us from the feature elaboration stage. Ultimately, there shouldn’t be an adversarial relationship between UX and product. Rather, it should be a partnership. We’re truly able to perform when we both play to our strengths. Ideation and interaction design aren’t product’s strengths anymore than Gantt charts and understanding technical implementations are UX’s. As an example of when things go right, I’d like to reflect on developing the feature that fixed the need for the warning from the last example.

To solve this compound key entanglement issue, we built a new compound key that uses unique identifiers. The challenge for product and UX was that the old accounts without the new key would still be in the system. Product explained to us that, due to a technical limitation in the database, we wouldn’t be able to just lift and shift the existing users into the new system. They’d effectively have to get phased out when their accounts close over the next year or so. But in the meantime, we’d need to solve for users that mistype their ID during the sign-up phase. Product suggested that we have users enter their ID up three times depending on various factors. Obviously having a user enter the same piece of hard-to-remember information on three separate pages is a no-go, so we explored alternative options. Our resolution was to have the user enter their ID twice on a single page to prevent mistypes. We wanted to make a decision founded in data, but product reported that they didn’t have a number for how frequently ID mistypes occur (an article for another day), so we did some math. We found that the likelihood of a user entering their ID wrong such that it matches another user’s ID while the two user’s have the same secondary key is so exceptionally small, that it’s effectively zero. 2^-9 % of the time. 0.000000002% of entries would be collisions if every entry is a mistype. We found it was safe to say this was basically zero. As such, we pitched our case to risk and got the green light to proceed. As a result, we made a more delightful experience for hundreds of thousands of people. This would not have been possible if product built their engineering solution around the multiple entries method.

In summary, UX and product should be partners, not adversaries. We’re two halves of the same whole.