The Power of Prototyping: Module Catalogue

As my placement in digital services comes to an end, I have been reflecting on all of the projects I’ve had the pleasure of taking part in. I’m very grateful for all the experience I’ve gained working in the Digital Service UX team and before I leave I’d like to share some of the work I did on one of my final projects, the proposed Module Catalogue redesign. This project was filled with opportunities and challenges, and has definitely taught me a lot about how we should tackle problems in our digital world. 

Digital tools have become a game-changer in higher education. And with technology rapidly evolving, satisfying our student user base doesn’t come without difficulties. Roughly for every 1 staff member in Digital Services, there are around 225 UoY students and knowing or even understanding all their needs is a hefty challenge. Having recently finished some user experience design and research for the university website, I’ve seen this first-hand. In this post, I’d like to share with you how I’ve used prototyping to help inform the Module Catalogue redesign. 

Image: Jake hosting a usability testing session

Why use Prototypes?

Prototyping allows us to test and evaluate new ideas before committing to a change. This means we can evaluate the effectiveness of ideas. The key is exploring multiple ideas before having confidence to select the best route forward through data led decision making. For the Module Catalogue, this was essential, due to high traffic at peak enrolment periods. Despite our best predictions, it’s impossible to know exactly how a user will interact with a product until we observe them. Without this, we introduce cognitive bias into our designs and increase the risk of going live with a feature which may not work as we originally intended.

Prototyping works hand-in-hand with usability testing. For Module Catalogue, we set up scenarios, such as “Imagine you’re a visiting student who studies Biology. What modules are available to you?”. Based on how users approach the problem, we can make judgements on the usability of the product. We did similar on the original Module Catalogue to uncover the first usability issues alongside baseline metrics to measure against going forward. We tested with a range of predefined user groups using our UX&D user panel, issues arose based on their unique approaches to tackling the situation presented. Even if a problem wasn’t easily identifiable initially, it emerged through repetition and analysing of data between different users. 

Problems varied in severity. One issue related to the scroll functionality. We observed users spending a significant amount of time scrolling through multiple page results due a problem with the UI layout. Showing 10 module search results before needing to click the ‘next page’ button is frustrating enough. Then imagine, every time you clicked the ‘next page’ button, it reset the scroll position to the top of the web page. This was not only immensely frustrating, but time consuming also. While no users verbally complained about this issue, it still existed. This is why we prioritise observation over words as a more accurate reflection of user behaviour. In the first iteration of our new prototype, the scroll functionality was changed (along with other changes based on problems discovered). We ran rounds of user testing to track differences. Similar to before, no user verbally indicated issues with scrolling. But our metrics told a different story. We significantly improved task-time performance and decreased the average number clicks and overall satisfaction scores. Prototyping allowed us to quickly and cheaply test if our ideas work before committing time to something which may not work.

How did we make the Prototypes?

For this project we needed high-fidelity highly realistic prototypes, so decided Protopie was the best option. But plenty of options exist, for your project remember that high fidelity may not be necessary. For example, we regularly use low-fidelity sketches to quickly answer our research questions.

Image: Example of Mock application in Protopie

Final Product

After multiple rounds of designing, testing and iteration we crafting 18 areas of improvement. With testing and comparison metrics showing clear evidence of change impact.

On reflection I have learnt that we cannot detect or solve all issues in a design, we must prioritise. Iv also learnt the solution we decide upon may be very different from what was originally envisaged at the start. Showing the importance of not getting too attached to an idea early the process.

Leave a Reply

Your email address will not be published. Required fields are marked *