In the beginning stages of designing any project, it can be difficult to mentally conceptualize how users will interact with your application. Doubly so if you are new to the business domain of your users – not only do you need to determine a technical implementation that provides an intuitive flow for your users, you also need to get on the same page as your users so you can provide an application that generates value for them and their business.

One way to take the some weight off your shoulders early on in a project is by creating visual mock-ups of the UI that your users will be interacting with. As per Lara Letaw in the Handbook of Software Engineering Methods, user interface design involves “iteratively creating depictions of what you think the UI should look like, and how users should interact with it, based on the software’s requirements.” Let’s get further into this concept:

1. Just like any agile project would recommend, building out “green” areas of your application in an iterative fashion helps mitigate going down the “wrong path” for the project. Build a draft of a view for your application (preferably a home or introductory page) and ask for feedback from the stakeholders before moving forward onto other pages. Work small and work fast so you can get to failing quickly, which opens the doors for learning opportunities to make the UI better.
2. By working iteratively to determine the applications user interface, you allow your development team to get cycles of feedback from your users, feedback which will include what works and doesn’t work for your users – based both on their personal preferences and how the domain of their business actually functions. In some cases you may find conflicting feedback from two different stakeholders – it will be your teams job to determine which feedback takes higher priority than others.
3. As always build the UI pages based on the requirements to a reasonable degree, as requirements can sometimes be imperfect. If requirements seem to be conflicting, contact the stakeholders and ask them to resolve the conflict. Don’t try to charge forward on technical implementation if the spirit of the requirements are not clear.

Your user interface design does not need to be fancy – the goal here isn’t to spend a lifetime making the mock-ups look like “the real deal”, but rather to get something quickly viewable so you can receive feedback sooner rather than later. You can even make low-fidelity mock-ups which are rough sketch drawings of the UI, however be careful with this approach if you don’t have a gifted hand – the last thing you want to do is send something absolutely hideous to your stakeholders for review. Prioritize cleanliness, and provide some helpful text that describes what occurs on the page when users interact with different elements on the screen.

Finally, when requesting UI feedback from your users, one helpful tip is to request your user to attempt to complete a task using your various UI prototypes. Watch how the user interacts with the page and take note if the user indicates that they would’ve expected an element on the page to have been located somewhere else. The more communication that occurs during a feedback session the better.

Hopefully you find this helpful with your next project.