If you’ve worked with developers, you’ll be familiar with the concept of ‘Test Driven Development’. The basic principle is that the functional requirements of a given task or feature are used to create specific tests that the code will need to pass. The tests are written before the code, which helps developers know exactly what’s required of them and what level of quality is acceptable.
When designing a system, starting with testing in mind is a powerful way to improve usability and the overall user experience.
Goal-Driven tests
What will success look like for the end user? When working with Business Analysts, Product Owners and Product Managers, it’s all too easy to get lost in a sea of functional requirements. Take a step back and consider what the primary goal of the user is.
Be clear as to who you are designing this for and what they really want to achieve in their workflow. Try and make the goal as specific as possible. This must be the result of user research, else you’ll just be guessing. For example, you may be asked to design a file upload feature within an application. The user goal could be:
“As a Research Assistant processing over 50 similar data files a day, I want to be able to upload data from Excel files into the system in as few steps as possible.”
Agree the user goal with the BA, PO and PM as appropriate before you start the design work. This will give you significant leverage if the pressures of development tempt managers to try and cut out features which will jeopardize the main goal for the user. If everybody can see what success should look like, it’s much easier to prevent a project from going off track.
Usability-Driven tests
Usability tests are a measure of how easy a system is to use, typically measured from a tester’s first experience with a product. It’s a measure of the difference between the expectations of the tester and the realities of the system.
For each key feature or key workflow of the system, you should be writing and conducting usability tests before you ship your product. The tests themselves can be simple to write and understand, and if you write them before you start your design work, you will find they significantly improve your designs.
For example, if the ability to duplicate an item in a system is considered a key feature for the users, you will want to write a test for the usability of this feature. The test may contain a simple task such as:
“You need to make a copy of Item ABC. Duplicate this item and give it a new name.”
Now, when you come to test this feature you’ll be wanting a usability score as close to 100% success as possible. So where are you going to place the button for this feature? Are you going to label it with some obscure, non-industry-standard term like ‘Clone’? Are you going to tuck it away in a hard-to-find dropdown menu? Are you going to use an icon-only button which users might miss or misunderstand? If you design your interfaces to pass the tests that really matter to the end users, you will have a significantly more usable system and will have the usability test data to show for it.