Gathering UI requirements is simple right? You just need to ask end users what they want, what they need and from there get on with the business of developing the solution they asked for - whether it’s an app, an Intranet or some other enterprise IT solution. If only things were so simple!
When we go about speaking to stakeholders, as part of our enterprise services, it’s very easy to listen to what one or two stakeholders tell us, write it down in a report then get on with the business of designing the solution. The problem with this approach is that the people gathering requirements and the stakeholders in a company often have very different understandings of what their project needs and what different terms used mean. A company director might say “we want our staff to have a mobile app which feels like our CRM”. The person gathering requirements might assume this means they want an app which has the same navigation system, when the company director meant something which has the same ‘look’.
It might never be possible to provide exactly what users want, time and money often get in the way, but gathering User Interface requirements from stakeholders fundamentally requires designers to “walk a mile in the shoes” of end users. It’s about having more than a superficial idea of what CTOs want. It is about getting a deep understanding of how a whole range of users - from the shop floor to the boardroom - navigate, understand and explore the system.
This isn’t something you can do in an afternoon, it might take weeks (or even months) before you fully understand how users talk about their IT needs, what vocabulary they use to describe certain actions (these might be technically incorrect but make sense to end users) and how they navigate through pages.
How can we avoid misinterpreting one another?
There’s a tendency when gathering requirements to treat it as a box ticking activity, but to really ensure your UI gathering is effective, it’s important to do some research. There’s a whole range of methods you can put into practice to find out about UI requirements, and when this is done effectively, you’ll feel a lot more confident that your final build will not only please end users, but will also do much more than they originally thought they wanted.
1. Understand the current state of play: Whether you’re building a UI from scratch, or are improving on a current system, it’s important to get a deep understanding of how the company works, what they do and what the system you’re building for them does.
2. Test your assumptions: ask lots of questions, then ask some more, and after that, keep on asking. Don’t just ask a select few people - IT managers and CEOs - speak to employees throughout the organization, from top to bottom and find out everything you can about how they work and what they need. You need ask questions covering:
a. Why do users interact with the solution in the way they do - is something restricting them? Are they confused or lost? Could it be improved?
b. Where do they interact with the system? Is it on the shop floor, in a back office, front of house, in the car, on a mobile or a tablet or a plain old desktop?
c. Who interacts with the system and in what way do different people interact with it?
d. How do they interact? You need to ask about their problems; where they get lost while navigating; do they always follow the same pathways or do they visit lots of pages?
e. What are their problems and issues, and what do they want and need?
3. Carry out research and document your results. There are many different methods and each one is more or less relevant to different situations. The most important thing to do is to find ways of storing all the information you’ve gathered and it’s worth recording interviews and mapping user journeys in order to really understand their pathways.
4. Present your results and explain your suggestions for UI design. As for feedback.
5. Once everything has been signed off, you can’t sit back on your laurels; effective UI design means you need to keep clients involved throughout the development stage (as irritating as this sometimes can be!). They will typically be investing considerable resources into your developments, so you don’t want to build something which doesn’t actually suit their needs.
The best UI resources
At Infragistics we understand that gathering UI requirements is never a simple process. However, our range of UI Controls and productivity tools (as well as our own consulting services) allow teams to storyboard UI navigation and ultimately build a set of stunning designs. UI requirement gathering is far from simple, but carrying out effective research means you can be confident your builds are the best they can be.