UX Report Delivery

Question

Situation:

I'm doing a project for a company doing Public Key Infrastructure (PKI). They've been around for a while and their product, while bleeding edge tech-wise, has horrendous usability issues. Picture Windows '77 if it had existed. It's just a literal GUI of the database, everything is a 1-to-1 translation of what the code can actually do.

There's no budget for a full overhaul, that's out the window. I'm trying to:

• Research and find some low hanging fruits (e.g. standardizing what words CTA's use and also wording in general)

• Aggregate a list of tasks that the system admins (prevailing user group) do on a daily basis and then figure out a way to make them more guided, because right now the user has no way of knowing what goes first, what goes second, etc.

• Find ways to fix documentation to make it easier for the user to follow instructions.

• Overhauling (gently and in a limited manner) the dashboard as it currently gives of very little information.

Question: Since I can't offer large scale interface modifications (they won't do them as they prioritize security patches and other backend stuff), how to best present the above findings to have the client see the value?

I know this is a quite an broad question, I'm definitely looking for opinions. Let me know if I need to clarify anything.

Thank you

Answer 1

This really is a broad question. Lets start with one of your points. . .

You say that you want to find ways to fix documentation to make it easier for users to follow instructions. Obviously the ideal situation is to make the solution so easy to use, the user never needs to read any instructions.

By designing a better solution that is easier to learn and use, you can now save time and money and/or make money:

• For your company because someone needs to conceive and write those instructions.

• For your customer because they need book out time to train their users, which prevents the user from being productive.

• For your customer's users because they need to take time out learning a new solution (and most people will not be happy about being forced to learn a hard to use application, especially now that good user experiences are quite common in other software they may use).

My point here is, the key to your problem is to calculate the cost or benefit expressed in money to promote/defend your design direction. Stakeholders understand money, not design, so talk in their language.

You can either make educated guesses about the costs/benefits, or you can research them. The training/learning costs are often hidden but you can bring them into focus - if there are many users who use this, the training/learning costs can end up being a very large number, and don't forget to extrapolate costs/benefits into an annual figure. Nothing focuses a business better than hearing this design direction can save you xxx per year.

If you have access to your user base you can also watch them work for an hour - you will soon see the real problems and opportunities are (they can often be different to what the business told you), and it won't cost much but will definitely give you more ammunition to defend your design direction.