Wondering if anyone has any frameworks or ideas on how to explain your usability analysis and then research plan development process better. I'm noticing I'm very bad at this. I go to the usual doing a heuristic analysis to look at time and completion rates, and then doing a pilot test, stakeholders conversation, developing hypotheses and then doing the testing and iterating. It's just not convincing enough and I usually get told that my process doesn't make sense.

Any set way to do this that I'm missing? Or any resources to look at?

1 Answer 1


Sounds like your approach is too broad

In my opinion it's best to focus on the small wins, whether that's in a new development or an existing product. If you can show tangible evidence that changing X can affect Y then the battle is half won.

There's some fantastic books out there on how to detail to the ambivalent manager that concentrating on UCD and the user journey can indeed produce very real results, however it's not my place to promote one book over another, so Google or Amazon become your friends here.

However, with regards to projects that cover broad applications, whether web based or otherwise, the devil is in the detail. Break it down, take a portion of functionality and show why changing it, makes it easier for the user and should increase in usability and traffic.

If I take a real world example, we're currently looking at one of our products that provides planning maps. At the moment equal weight is given to the homeowner who is looking to draw/plan a minor/minor house improvement and the industry professional who makes planning maps for entire housing estates.

Analytics tells us that 10% of our traffic is coming from home users, yet 40-45% is coming from advanced/industry professional users. From this I can make a case that the landing page should be weighted towards the latter. I produce wireframes to show that we don't forget about homeowners, but the text and links lead people to find our advanced tools.

Often times UX requires a degree of patience so you may need to swallow a disagreement within a meeting that turns into an agreement to deploy two different versions of a product that allows you to analyse and produce A/B testing of different ideas.

The TL:DR of this is, you often times need to state your case for UX as the results are not often an instant thing.

  • Thanks, I guess I'm more stuck on hypothetical questions in a job interview context where I have no inside analytic data to make a case upon. Though I do find I struggle with this in general when asked to explain my solution to problems.
    – Yusefi
    Jul 23, 2017 at 0:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.