#37 UX/PM/engineer collaboration — a critical factor for a product’s success

Many UX educations tend to put UX in isolation, and disregard the importance of UX/PM/engineer collaboration. But in reality, a success of a project/product from a UX perspective is more affected by how well a collaboration among these three disciplines is executed, rather than what a UX team or a UX designer alone can do.

When I was younger, I used to think that a UX designer has a tremendous power and influence on a user experience of a product, and thus it’s the quality of UX designer’s design output that ultimately impacts the quality of the final product’s user experience the most.

This still holds true, but only if other critical condition is met successfully.

And that critical condition is, UX/PM/engineer collaboration.

I learned this the hard way through various failures, which I would like to share with you.


Collaboration with PM (product manager)

UX is not the only product value

A product value consists of outcome and experience. Outcome is a functional aspect of a product or a service, what it does. Experience is more about emotional quality, how you feel when using/experiencing a product or a service. UX obviously covers the experience part in full, but it also covers decent part of outcome, the functional aspect of a product. Altogether, UX covers a significant part of a product value.


PM owns a product

While UX plays a very important role in a product team, a UX designer never owns a product. PM owns a product definition, requirements and a roadmap. Naturally, MVP (Minimum Viable Product) — is typically defined by PM. MVP is a set of product requirements that are minimum in order to launch as a product and still provides value to a customer. It’s a bare minimum.

A conceptual diagram of MVP-Minimum Viable Product, showing that it only includes critical features.
MVP-Minimum Viable Product

Because it’s minimum, it typically does not take the experience part of a product much into consideration, and primarily focuses on achieving functional outcome of a product value as shown above.

There’s a similar concept called MLP (Minimum Lovable Product). MLP is a set of product requirements that are minimum to make the product not only functional but also something that a customer would love.

This “love” certainly addresses experience — the emotional aspect of a product to go beyond just the function.

A conceptual diagram showing MLP — Minimum Lovable Product, which covers critical features and some UX features.
MLP — Minimum Lovable Product

From a pure UX perspective, you want to make the product value, both outcome and experience as good as possible.

Unfortunately in many cases, the experience part is considered outside of MVP by PM, as shown below.

A conceptual diagram showing that UX features are typically outside of MVP.
UX is typically outside of MVP

Outcome is always part of MVP, especially for critical features. Without a function, a product is useless. But many of user experience enhancements tend to be labeled as lower priority by PM.

In most cases, available resources are limited, especially engineering resources to build a product. When PM is confronted with a hardship where he needs all the remaining resources to complete critical features so that the MVP can ship on time, UX enhancement features are typically among the ones to be cut. Or an overall user experience of a product gets watered down to the most stripped-off version.

A conceptual diagram showing that limited engineering resources can only cover critical features to build.
Engineering resources are always limited

PM owns feature prioritization

Feature prioritization is one of PM’s most important tasks. As a result, what typically happens is the first version of a product launches with MVP, then the next version or the next next version start looking into MLP and beyond.

A conceptual diagram showing Version 1 of a product ships with MVP, followed by version 2, 3 which could cover MLP.
Version 1 of a product typically ships with MVP, followed by version 2, 3 which could cover MLP

There’s a well-known theory called Kano Model for product development and customer satisfaction. It was developed in 1980s by a Japanese professor Noriaki Kano, which classifies customer preferences into 5 categories:

  1. Must-be quality
  2. One-dimensional quality
  3. Attractive quality
  4. Indifferent quality
  5. Reverse quality
A diagram showing Kano Model’s customer preferences classified into 5 categories.
Kano Model (Source: wikipedia)

As in Kano Model, it’s important to understand how each feature is positioned from customer’s perspective, when prioritizing features for a product.

A UX designer should work together with PM and help them prioritize features so that the experience part is not ignored. This is something that may not be typically considered as a UX designer’s job, but it’s important as the feature prioritization hugely impacts the user experience of a product, and PM may not realize all the UX impacts when prioritizing features.


Understanding a larger business context

A UX designer needs to understand a larger business context in order to function effectively as part of a product team.

I experienced many times where a disconnection between a UX team and a PM resulted in the UX team working hard on features and UX enhancements that never implemented in a real product.

Even if a UX designer collaborates closely with PM, this will probably still happen to certain extent. Over the course of time, priorities might change due to various reasons such as competitive landscape changes and resource fluctuation. Whenever that happens, PM needs to adjust the plan, which may result in pushing some features out of scope.

While it’s easy to blame PM, typically there’s always reasons at a higher level. Understanding those reasons behind business decisions helps UX designers do their work better. As a result, UX designers can make a better contribution to the product by focusing on areas that have higher impacts.

A UX designer should always be in the loop of these constant changes around product development such as priority shifting, so that you are always aware of those changes, and ready to respond accordingly if needed.

Instead of waiting for PM to inform you, a UX designer should proactively engage with PM on a regular basis. PM is always busy with so many things to worry about. Updating a UX designer with changes could easily get lost in their never-ending to-do list.

This is why a collaboration with PM becomes critical for a UX designer. Actually, not only a collaboration but a strong partnership with PM becomes so important in order to stay in the loop of a larger product context and development status.

A conceptual diagram showing the criticality of UX + PM partnership.
UX + PM partnership is critical

Collaboration with engineers

A product needs to be built by engineers in order to launch to the world. An ideal UX that cannot be built is meaningless. An ideal UX that costs too much to build is impractical and worthless.

Even if your design provides a better UX than the current version of a product, it does not make sense for engineers to move forward with it if it’s too expensive to build, or if an assigned engineering team does not have a skillset to implement it correctly.

At the end of the day, bunch of wireframes or design prototypes cannot launch a product. It needs to be built by engineers, period.

This is why a collaboration with engineers becomes critical.

A conceptual diagram showing a criticality of UX / engineer collaboration.
UX / engineer collaboration is critical

Design handoff is not the end

What a UX designer does is basically creating a detailed specification on how a product experience should be. This specification is typically created in form of prototypes, design specifications, wireframes, design guidelines/etc., and then delivered to engineers, which is often referred to as a handoff.

A diagram showing examples of typical UX design deliverables.
Design deliverables

Many people think that once these deliverables are completed and shared with engineers (handoff), this is the end of the UX process, and a UX designer’s job is done.

But in reality, that is not true at all. In fact, another phase starts from here. This is where a collaboration with engineers becomes a central part of a UX designer’s work.

A diagram showing that implementation phase starts after a design handoff.
Implementation phase after a handoff

Even though you have included engineers during your UX process, through requirement gathering, journey mapping, concept development, user research, design iteration and so on, engineers will not be able to point out all the problems and challenges in advance.

Because when the UX process is taking place, it’s most likely that engineers are busy with other things.

Engineers are always very busy, and under a constant pressure of tight deadlines. The top priority for them is to work on functional parts of a product, to make things function stably. Engineers also need to fix all the critical bugs. Naturally, the user experience part falls low on their priority, and taken care of in the last minute.

Engineers will only start taking a closer look at the delivered UX design and specifications once they start implementing those in code. I experienced this so many times with disappointments to find out that what I delivered on time was never reviewed by engineers for a month. But this is reality that you don’t have a control over as a UX designer.

And that’s when engineers find out bunch of problems, and come back to a UX designer saying “you cannot do this, because the platform does not support this” or “this data is not available because we don’t have an API for that”. Or a problem might simply be the result of a priority change that pushed back the development of the needed API out of scope.

If a UX designer does not do a follow-through work with engineers after sending deliverables, there’s a possibility that the final product may look like a total crap, completely different from the design delivered by a UX designer in the first place.

And if that’s the case, all of a UX designer’s hard work is wasted.

Good, experienced UX designers know this, so they work hard and spend good amount of time working with engineers to make sure that they implement the design correctly, and make adjustments if needed.

What matters at the end is how the actual final product user experience is going to be, ideally as close as possible to your original design that you worked so hard on and tested with users.

A beautiful prototype created by a UX designer does not provide any value to customers if it’s not implemented at all as a real product.

Therefore, design handoff is not the end, it’s the beginning of the implementation phase, which directly impacts the quality of the final product more than the design phase does.


UX/PM/engineer collaboration

When engineers find out issues implementing the design, or PM needs to shuffle feature priority that affects UX works, a UX designer needs to have a deeper discussion with PM and engineers to sort out what can be achieved under given timeline and resources. Based on that, the design or the schedule and the focus of UX works may need to be revised.

This is where things need to be balanced from a holistic view in order to make a successful launch of a product under those changes.

A diagram conceptually showing a criticality of UX/PM/engineer collaboration.
UX/PM/engineer collaboration is critical for success

At the end of the day, PM is the one who can make a call, as PM owns a product roadmap.

  • If you don’t change the design, how much more resources are needed to launch the product on time?
  • If you cannot add more resources, how much delay do you get to launch the product?
  • If you delay the launch, what is the business impact?
  • Is the delay worth?
  • Is keeping the original design critical part of product’s value proposition?
  • If you change the design to accommodate engineering request, can you still launch the product on time? Or how much delay?
  • If you change the design, how much impact would that make to the user experience?
  • Is that a show-stopper, or acceptable?
  • Is it possible to have a 2-step approach, to launch with the modified design, and improve on it later?

All of these need to be accessed by PM based on inputs from a UX designer and engineers.

A conceptual diagram showing various factors assessed by PM as a change happens in product development.
Various factors assessed by PM

In product development, changes happen all the time.

A UX designer should advocate users as much as possible, but in order to do so, a product needs to exist and launch in the first place. A UX designer is responsible for supporting PM and engineers to make that happen. UX is part of business after all.

A final product will be built by engineers based on PM’s decision on which features to build by when.

As a UX designer, I learned that you need to be nimble and flexible to be able to quickly make adjustments to your design when needed. To do so effectively and efficiently, you also need to know higher-level changes early so that you can adjust your plan and take action without wasting time.

Therefore, it is critical for a UX designer to have a strong partnership with PM throughout the product development process, and work very closely with engineers before and after the design handoff, in order to actually realize the design in the final product implementation.

Now that I look back, there are many products/projects that I wish I could have done better by understanding all these earlier.

Still, it was an invaluable lesson for me to realize as a UX designer that UX cannot exist on its own. UX is part of a larger product team, part of business.

UX designers rely on PM and engineers to realize their design in a product.

UX needs PM and engineers to make that happen.


This article was published on Medium in UX Collective.

Check out related article and a video:

Collaboration with PM and engineer is critical for a UX designer

YouTube video

Leave a Reply

Your email address will not be published.