End to End UX

As a product manager, I’ve become obsessed with the User Experience (UX). One of the most interesting things about UX for me is that the simplest mistake to make is to assume UX is contained within the walls of a product. In reality, it’s only a tiny part of the overall experience. If you want to do it right, you need to think end-to-end, and do your best to influence the entire process.

Overview showing a number of areas where UX comes into play. These are:
Pre-purchase: Traditional ales motion UX, word of mouth, proof of concept UX, demonstrations & hands on labs UX, analyst reports, official resources UX.
Purchase: Oder UX, order tracking UX, customer project commencement, delivery UX, pre-implementation and planning UX
Implementation: Procedures & services UX, implementation support UX, customer resource/tracking, implementation & closure UX
Functional use: Product UX, support UX, documentation UX, developer UX, lifecycle UX
End of use: Data export/archive UX, decommission UX.

All UX tagged experiences are ones where a vendor can help the user.
End-to-end User Experience

Particularly in the realm of enterprise products, we should be looking at UX as an end-to-end practice that starts before the customer has even decided to buy something, and ends only after they’ve stopped using it forever1. At every step along the way between those two milestones though, there are user experience factors involved.

And in every one of those situations, I want one outcome:

While there are a lot of breakdowns you can do for overall product lifecycle, I’ve drawn the above diagram from the perspectives of areas where you can influence the user experience. (Yellow highlighted ones are the minimum areas where the product manager can have an impact on the experience.) There are five major facets to a product lifecycle:

  • Pre-purchase – everything that happens before the customer decides they’re going to buy the product.
  • Purchase – everything that happens between when the customer starts the buying process and when the installation process is ready to start.
  • Implementation – everything that happens between when the product is delivered and when the product goes into to day-to-day functional use.
  • Functional use – the normal life use of the product.
  • End of use – the things that happen when the product exits use and is being spun down.

In every part of those lifecycle facets, vendors will have significant influence over the user experience. It’s easy to think your focus as a product manager is just on product UX. That’s wrong. It’s also relatively easy to think your focus as a product manager simply relates to the block I’ve labelled functional use. Again, a mistake. If you want to do user experience right, you have to think of it (and be passionate about it) from an end-to-end perspective.

You may not be an owner of the end-to-end experience (in fact it is unlikely there will be a single owner of the end-to-end experience), but even if all you’re tasked with is the product UX, you should be testing the limits all the time of how you can improve the user experience whenever and wherever it may occur.

Agile software development spends a lot of time thinking about user stories. These effectively follow the formula:

As a {persona}, I want {something} because {why}.

For instance, I suspect there was a product manager responsible for my washing machine who came up with the following user story:

As a person washing my clothes, I want my washing machine to beep incessantly at me when it finishes so that I feel machines control my life.

This also, naturally, led to a follow-up story of:

As a person who empties the washing machine and then turns it off, I want my washing machine to give one more hateful little passive-aggressive beep as it powers down to remind me who is in charge.

(I digress — I was doing the washing while I was writing this blog post.)

The reason I bring up user stories is that when product managers are dealing with UX, we need to not only think of user stories, but also think of product manager stories. Thankfully, they’re simpler to write. They go like this:

As a product manager, I want to influence {something} because I want to make things better for my users.

And the {something} there is every single UX-topic I’ve given in the above diagram:

  • As a product manager, I want to influence the traditional sales process because I want to make things better for my users.
  • As a product manager, I want to influence the proof of concept user experience because I want to make things better for my users.
  • As a product manager, I want to influence the documentation experience because I want to make things better for my users.
  • and so on.

This has become my obsessive mantra since becoming a product manager. I don’t always get to exert as much influence as I’d want – but that doesn’t stop me from pushing. The thing I remind myself every day is simple, yet important: UX is end-to-end, not bounded by the product interface.

Footnotes

  1. Though realistically, this mentality should apply to any product – enterprise or commercial.

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.