Having UAT is essential because, throughout creating the system, we as the developers interact with the system the most and things that may seem obvious and intuitive to us may not be so apparent for the end user who will be using it on a regular basis.
When it came to User Acceptance tests, we wrapped up everything into an installation file and provided it to our client for testing. Our client expressed how impressed they were by the product we created, saying how they liked the simple and intuitive design and how it met their expectations. They also expressed interest in wanting to test the system in an NHS Hospital in Wales.
Real Doctor Feedback
Throughout the process, we didn’t have access to any real clinicians, but we were fortunate enough to have a member of the RCGP review our system and give us feedback from a non-technical lens. The feedback stated how the design was simple, and we were given points on how we could improve our system.
Based on this feedback, we iterated further on the UI going above and beyond client expectations.
Evaluating Use Case List
As aforementioned, we were able to get feedback from a real doctor. We walked them through our Use Case Tests which we defined in a previous section where we would go through each workflow.
|User Case ID||Result||Feedback|
|UCU1||✅||Add a countdown timer or feedback text while uploading to indicate the program hasn’t crashed.|
|UCU3||✅||Add a countdown timer or feedback text while removing to indicate the program hasn’t crashed.|
|UCU7||✅||Maybe add a conversation tree so you can have an overview of the whole conversation.|
Our user confirmed that we had all the key functionality a clinician would expect and gave us some feedback on mainly how we can increasing usability, which we then implemented.