UX/UI as a Proxy of System Quality.

In my work, I am often tasked with evaluating existing or potential software platforms and systems for large and complex organizations.

When doing this, there is a lot to consider.

The vendor’s history, the support levels they provide, the coding languages used, the level of custom work and modules created compared to the original system, and the level of flexibility, security, performance, database technology, documentation, and ease of use.

I normally accomplish my work by doing a mixture of user interviews of the IT teams at my client and the project manager and technical team on the vendor side. Additionally, I will also review schematics that describe the architecture of the system that has been deployed.

But, I have found a reliable and accurate shortcut to understanding the level of quality of a system, and this can also apply to any type of technical or software vendor I am evaluating. I will look at the UX (User Experience) and the UI (User Interface) of the product and also the website.

Based on the quality of the UX/UI, I can make a lot of downstream assumptions about the quality of the vendor team, the strength of their service offerings, and even the software solution being offered.

After all, there are essentially four possible outcomes:

  1. Good UX/UI, Good Software.
  2. Good UX/UI, Bad Software.
  3. Bad UX/UI, Good Software.
  4. Bad UX/UI, Bad Software.

The first scenario is obviously the scenario that we want. We can have good software with a great user interface and experience. This is what Apple has done for years, and why they are able to command such high price points and have such a passionate following. They provide an end-to-end solution that just works well.

The second scenario is often found with startups that have just recently launched a product, and have someone with a design or marketing background as one of the founders. This means that they will know how to create slick landing pages that communicate well and have a strong understanding of UX/UI. But, because the product is young, they will still be working out many bugs and issues, which is only natural.

The third scenario is possible but not ideal or common. It’s the case where you have great software but a terrible user interface. This happens when the vendor has done a great job on building functionality but they have neglected the experience that the user will have.

The fourth scenario is obviously the worst case. This is when you have bad software and a bad user interface. This is where the vendor has built something hard to use and doesn’t work well.

So, the next time you evaluate a vendor or a potential software solution, take a close look at the UX/UI. It will give you a good indication of what to expect from the rest of

I would venture out on a limb and say that scenarios #1 (Good UX/UI, Good Software) and #4 (Bad UX/UI, Bad Software) are by far the most likely. Organizations with a terrible user experience with their products show a lack of care and empathy for the end user, which will reflect cross-functionally in the rest of their teams, such as support, customer care, and software development, and so on.

This is because bad UX is not just a case of having designers on the team or not, it is a cultural issue; it’s about the management team being on top of every aspect of the business and giving a — i.e. being proud — of the product that they ship to customers.

At my software company Blue, which provides project management software for thousands of organizations, I don’t have timelines to ship a particular feature or module. It only goes out to customers when it is ready, ensuring that the feature is highly usable and scalable. This is not by chance; it’s because my senior software engineer and I really care — it would just be against our very DNA as product builders to provide something second-rate to customers.

We couldn’t do it the same way that one cannot just step off a cliff.

The closer you get to the edge, the more alarms start firing off in your brain until you just retreat.

Conversely, when I see a product or software solution with bad UX, it tells me that the above type of culture is missing and that attention to detail is not important in the organization. So bad UX does not just mean bad UX; it likely means a lack of functional and unit testing, proper code storage, rigorous disaster recovery and archival/backup strategies, meticulous project management, and so on.

You might think that judging the skills of a vendor team or their system purely by reviewing their website might be taking a step too far, and this is not a valid heuristic to make valid decisions, but I think it does work.

Again, let’s think this through.

For most organizations, and especially software and B2B service companies, their website is, or should be, of key importance. This is your business card to the world, how everyone who does not meet you personally or step into your office perceives you.

I would go as far as to say that if you cannot figure out how to use the vendor’s website, then it is likely that their software will be just as confounding.

Evaluating a vendor’s UX/UI can give you a good indication of what to expect from the rest of their product and services. If they have put thought and care into the UX/UI, then it is likely that they will have done the same with the rest of their offering. Conversely, if the UX/UI is bad, then it is likely that the rest of their product will be just as confounding. Therefore, when evaluating a vendor or a potential software solution, look closely at the UX/UI. It will give you a good indication of what to expect from the rest of their product.

So if you have an outdated or horrible website? It’s the real-life equivalent of turning up to a business meeting wearing crocs. Sure, you may be comfortable, but you’ll leave an unprofessional impression.

I had a case recently where I was the assigned project manager for a project, but the vendor had already been chosen before I was assigned the project, so I didn’t have a chance to review a list of vendors and help shape the buying process.

The project was to redesign and rebuild the client’s website on a new platform.

Upon the introduction email to the vendor, the first thing I did was review the website, and, no joke, it quite literally looked like a throwback to 1999 — including a reference to the eSpace age with two hands touching fingers E.T. style.

I immediately raised this concern to the client organisation’s management team. If this is the state of their website, how can they possibly do a good job? This was even worse — because the project at hand was a website development project!

To cut a long story short, that didn’t end very well. And this is just one example, but I’ve seen it time and again — a terrible website is a sure-fire sign that the company behind it is not paying attention to detail, or worse, doesn’t care.

So, I think reviewing UX/UI is a quick and solid heuristic to understand organizations while skipping a lot of the hard work required to go in-depth and under the hood of the software platform or the working culture.

This is also a fantastic way to quickly narrow down a list of choices. Say that you have eight or ten platforms that you need to compare. Simply compare the top three or four that have the best UX/UI based on what you can see, and then take more time to study each one in-depth instead of spreading your time and energy over a wider selection and doing a more superficial review.

So the rule of thumb here?

Stay clear of any organization with bad UX/UI in its product offerings or website. 

Related Essays