Every new thing we make is more or less based on an assumption. The assumption is that a user will understand a user interface, and be willing and able to complete a task or tasks in order to get a wanted result.
To ensure that this is true we need to do some sort of usability testing. We can do this at an early stage on simple prototypes or later on functional prototypes. We can use partly working code, almost ready to ship code or an existing application. I have yet to run a test that didn’t come back with issues we had to fix; some of our assumptions are almost always wrong.
The anatomy of Teston usability testing
With Teston, the hard work of getting users to usability test your solution is removed. You don’t even need to run through it together with your subject. You can set up the test when you want to, and the users test it when they have time. It’s a lot simpler and much more available. But, since you’re not there to facilitate the usability test, you need to put a little extra effort into your test script. You can’t help the user get back on track if they misunderstand something, so you should make sure your script is unambiguous and clear.
You will always find some issues after running a usability test. These findings are close to facts. You know it’s real. One or more aspects of your prototype is not working. These are the true results of a usability test.
When you look into why it is not working and how to possibly fix it, you are back to assumptions. The reason for it not working is an assumption, and the fix is an assumption on an assumption. Pretty weak. And the more you change, the bigger that last assumption gets. This can lead to new errors. Often in development, it is too hard to set up new usability tests. Getting new test users and finding the time and place for running a new usability test is time consuming and involves a lot of people.
Not so much with Teston. After re-doing or creating a new prototype, you just duplicate your old test, swap out the URL from the old to the new prototype, and re-run it. This way you get to know if your new assumptions are valid enough for your solution to work satisfyingly. Quick, cheap and with equally good quality as the first test. Voila!
Doing a usability test with Teston is a lot less time consuming than doing it the traditional way, and re-running the test is even simpler. Maybe usability testing is now affordable enough for us to do it all the time?
Any comments or other good experiences with usability testing and re-testing? Let me know!
How to create questions for a user interview?
A quick look at how to set up a script for interviewing users as part of user research.