In our client work, we are 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.
At Mäd, we usually accomplish these sorts of tasks by doing a mixture of user interviews of the IT teams of our client and the project manager and technical team on the vendor side. Additionally, we will also review schematics that describe the architecture of the system that has been deployed.
But, through these experiences, we have found a more 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 being evaluated. We will consider the UX (User Experience) and UI (User Interface) of the product, as well as the website.
Based on the quality of the UX/UI, it is feasible to 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:
The first scenario is obviously the scenario we want. We can have good software coupled with an excellent user interface and experience. This is what leading companies like Apple have 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 undeniably the worst case. This is when you have bad software and a bad user interface. It is where the vendor has built something hard to use that also doesn’t function well.
We could 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, 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 being proud of the product that they ship to customers.
At our sister company Blue, which provides project management software for thousands of organizations, there are no 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 is because the senior software engineer and the CEO really care. It would simply be against their DNA as product builders to provide something second-rate to customers.
They 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, seeing a product or software solution with bad UX tells us 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 that this is not a valid heuristic to make valid decisions. But we 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.
We 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 an idea of what to expect from the rest of their products or 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 confusing.
So, the next time you evaluate a vendor or a potential software solution, take a closer look at the UX/UI. It will give you a good indication of what to expect from the rest of their work.
So if you or a vendor have an outdated or horrible website?
It is essentially the real-life equivalent of attending a business meeting wearing Crocs. Sure, you may be comfortable, but you will leave a (lasting) unprofessional impression.
We had a case recently where our team was given a project to manage, but the vendor had already been chosen before we were assigned the project, so we 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 we 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.
Our team immediately raised this concern to the client organization’s management team. If this is the state of their website, how can they possibly do a good job? Even worse, the project at hand was a website development project!
To cut a long story short, the outcome was not great. And this is just one example, but we have encountered it time and again — an outdated website that is decidedly not user-friendly is a sure-fire sign that the company behind it is not paying attention to detail, or worse, doesn’t care.
So, 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.
It is also a fantastic way to quickly narrow down a list of choices. Consider that you have eight or ten platforms that you need to examine. 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.
