Slow and ugly
Many years ago at a previous job, I was responsible for pushing our organization to adopt a new ticket tracking system. We decided to use an open source project called Request Tracker (RT).
This was before the days of Zen Desk and similar services. RT matched our requirements best. I worked with our sysadmins and engineers to get the software running and rolled it out to the organization.
It was a failure. People were openly swearing at RT, and I’m sure they were privately cursing me for forcing them to use it.
While I sympathized with the complaints, I felt hamstrung because RT was deployed on an underpowered server and we had not been allowed to modify the look and feel. Back then RT was a bit of a dog both from a performance and aesthetics perspective.
As I worked with engineering to secure better hardware and get someone to assist with the design, the number of grievances continued to pile up.
One conversation stands out to me. A member of the management team told me that the fact that customers couldn’t reset their password in RT was unacceptable and as long as that was true, we couldn’t use RT.
I listened to the objections and kept a list of the issues that were raised, but I kept my focus on making RT faster and more attractive.
A few months later we relaunched RT. It was met with skepticism, but to the credit of my colleagues, they gave me and it a second chance.
It wasn’t too long after the relaunch that previous skeptics were swearing by the system. One of the team members became the master of RT and made a bunch of process improvements that I would have never considered.
What happened to that list of complaints that I gathered? We didn’t address a single one of them. Passwords worked exactly as they did before.
We simply made RT fast and attractive.
I have a simple rule when it comes to user experience: when something is slow and ugly, nothing else matters.
Until you address those two issues, you’re not going to be tell whether other complaints are real or red herrings.