You can move mountains when the team has an awareness of the current user experience.

In his article, Jared Spool shows the importance of team members and stakeholders being aware of the current user experience.

I thought to myself, "Yeah that makes total sense, I wonder how we would do that in our org if we ever came across a similar situation"

I thought too soon haha

Identifying the UX issues

A couple of us designers were working on helping an IT team improve an application. The users felt it was too cumbersome and that the tasks took much longer in the new application than they did using their manual excel files.

As we worked with the users to understand their various painpoints as well as during our own heuristic evalution so to speak, we found several issues that could be fixed. We brought our insights to the IT team, excited to help create a better product.

The document generation page (among other things)

Specifically, one of the most ridiculous things in the application was generating a document of your data. You first were taken to a screen (sorry, can't share it here) that had a bunch of buttons that didn't make any sense to someone wanting to generate a document. Then, once they clicked the right button, they had to select which file format they wanted. But unbeknownst to them, if you select the wrong file type, you can't edit some legal language that you need to edit. And, there's a template for the document that needed to be selected that didnt look like you could select it.

And when you finally got through all that, you now had to choose whether to "Generate" or "Submit" the document. Wot. Generate will give you your document, but submit will also give you your document, but not open it and show it in your list of documents which is on another page there is no easy way to get to. Users thought it meant submit for approval.

The software package

As we were showing the IT team what the issue was, they looked into the software package and said "Oh this isn't customizable in the software package so we can't really even change the text on the buttons", or "This will impact the way we process the data", etc. The IT team were nice folks, it just felt like our ideas were getting stonewalled by this packaged one size fits all software and caution when it came to change.

A failed usability test?

We were getting a little frustrated as designers at this point, since we felt like we couldn't make meaningful changes in the application. As we prepared for the usability test on what little we could change, we realized users would probably fail a lot of the tasks.

Deciding to invite the team to observe

We also realized we could use this anticipated failure to our advantage, to help prove that the user experience wasn't great and something needed to give. We extended invitations to the team, IT folks as well as a couple of key stakeholders.

The usability test

Most of the team were actually able to attend and observe. Users really struggled with the key tasks that we wanted to test - including the document generation page mentioned earlier. It was clear no one could get through it unless you were told how it worked, and even then it would be inefficient.

The IT team could fix it!

Soon after this usability test, the IT team told us that they could indeed change the document generation page and that they would actually rebuild it from scratch instead of using the software package!

The next usability test

Shortly after they built the new document generation page, we tested it again with some users. They all were able to generate their documents now! The IT team also continued observing subsequent usability tests since they found them insightful, which felt like a pretty big win for us.

It felt like we were able to move mountains

The IT team became more receptive to tweaking and improving the user experience of the current application and in fact started suggesting their own ideas. The Business Analyst started making his own mockups as a way to communicate his ideas, and the IT Lead started collaborating with us on ensuring technical feasibility of our ideas and proposing alternatives as needed. The BPM (SME and product owner) was willing to push back deadlines a little bit if it meant features were designed well.

The biggest lesson learned: Invite folks to see the user experience for themselves, and they will go out of their way to help you make it better.