Building a Better Product -UX

Musings on product gaps, one topic at a time.

Anyone who knows me well, likely thinks its absolutely ridiculous that I work for a software company.

“Why?” you ask. Because every piece of software that I lay my hands on I manage to break.

So now you are probably thinking, maybe you are just good at finding bugs. Perhaps your true calling is QA and not product management.

Photo by Sigmund on Unsplash

The issue is that I am not trying to find problems, I just go down rabbit holes in the UI and end up at in those places where the issues lurk. I get lost and the resulting user experience sucks.

My partner claims that I don’t think like normal people, and perhaps the UIs are not designed for someone like me. I don’t agree with that assessment.

Here’s a truth that I think many companies overlook:

UX design includes all of the interactions, not just a single interface. It is the end to end process that allows the user to reach the objectives that you promised in the product purchased.

Let me further illustrate my point. I took a course on how to use a piece of software. The course took many days and ended in an exam. I still don’t feel like I can easily complete the tasks that I want to use the product for. One could argue that any company that creates software training that requires significant time to execute, knows that the software could be easier to use.

As a user, I feel anxiety and dread whenever I need to use a product where the likelihood of reaching the promised goals seems low.

In my opinion, I think one issue is that the UIs can get overloaded by other objectives. Huh? Here’s an example. Consider software in which data entry (& edits) need to be highly controlled. Instead of making it hard to do those things, make it hard to do them accidentally. Add verification or authentication to secure the data, rather than burying the functionality.

Security is a separate objective from usability. Overloading the components of your workflow UIs makes for poor UX.

As a PM, I understand that the buyer and the user can be (usually are) different people. (Apps being a notable exception.) And, these people will have different POVs. The software buyer may not be concerned with the UX, but is focused on other functionality. However, if you make the sale but the users won’t use it or use it and achieve poor results, then your buyer won’t be happy either. Especially if there is considerable cost for config, training, migration, etc.

Left: What the Buyer sees. Right: What the User sees.

So when prioritizing your backlog, I highly recommend that you consider the UX as more than just an add-on. Add if you don’t have the right people in your team, consider making the case to get them. Here is my final thought on UX:

When a company produces a product with poor UX, what does it say about its views of the user?