1. Review business requirements and ask several questions both internally and to users
Product owners/analysts presented me with specific product needs which I'd then question
in order to get to grips with the "why" factor. This is the most powerful question type
you can ask a stakeholder about a given scenario. Ask a user "why" they do something rather than "how" or "what" they do and you'll get closer to the user's needs and jobs they need to get done. I'd ask these questions per user type and follow up by asking "when" would they do such a task.
Sometimes it would help to draw out a simple storyboard of the events that take place
in and around when the user/s were likely to engage with our software.
2. Choose an appropriate prototyping method
A lot of my work is based around prototyping. It's level of fidelity usually
depends on the type of people that I'm sharing it with. When sharing internally, I love to
paper prototype. I've also done this with users after a testing session. Being part
of a small team, I needed to maximise the impact of carrying out user testing.
The best constructive criticism and ideas usually come at
this stage. People are more forthcoming with feedback when they know this is not your finished work. It
makes people focus on the efficiency of completing tasks rather than aesthetics. You can also make tons of them in a very short period of time.
3. Adjust and enhance its level of fidelity
We then identified patterns in usage, documented our findings per user type and adjusted the prototypes where necessary. It is very important to acknowledge how different users may perceive your designs. It's not just a case of "some will like and some will not." Different user types
will have different goals when engaging with your system. The structure of content and layout
may look perfect to one user and be completely irrelevant to another.