ReadyTech
Designing student and employer portals to manage apprenticeships and traineeships at TAFEs.
This project aimed to improve the experiences of trainers, students, employers and admin staff through a modern, intuitive and reliable student management system. This was a mobile-first design process, with web added in the high fidelity stage.
What problem are we solving?
The current portals or access students, trainers and employers have is unreliable and unhelpful. The majority of users don’t use them which makes processes paper-based or email-based. There is an opportunity to make these portals valuable which would improve the apprentice experience overall.
Discovery & Research
My involvement
I was responsible for the apprenticeships and traineeships stream of work at ReadyTech. I worked within a squad, collaborating closely with a product manager, lead engineer, and wider engineering team. I lead the project from discovery, to prototyping and testing, to dev hand-off and guidance.
Sketching& wireframing
Testing, VDF & Presentations
HiFi, Testing & Endorsement
Dev HandOff & Delivery
Discovery & Research
From the Statement of Work, I began mapping out a design timeline from discovery through to endorsement. I used the Product Refinery research matrix to help me gauge timeframes for different features.
I prepared a discussion guide with my product manager and led stakeholder and user interviews to uncover insights around the different features in the statement of work. We spoke with admin staff, business analysts, students, employers, and TAFE staff.
I also completed a competitor scan for the employer portal through assessing and documenting an existing portal that served some similar functionality but is being shelved.
No single type of employer
Some employer user types have upward of 100 apprentices (Group Training Organisations) and others have just 1 apprentice (family-owned business).
Huge value in seeing progress
Most employers struggle to know how the student is tracking with their studies. Seeing an overview of their progress (how much completed, how much left) would be greatly valued.
Unit sign off varies by employer
Some employers sign off all in one sweep at the end of the qualification, others in a rolling manner. Not all employers need to sign off on their student’s units.
Invoice payer varies
Students may have their course fees paid for by employers, but not all of them. Some students will pay and seek reimbursement, others students pay everything themselves.
More interested in absences
Employers said they are more / only interested in seeing absences of their student. This includes partial absences. The reason for this is that is affects the student’s pay by the employer.
Notifications are important
Employers would like to be notified of key actions such as a student being marked as absent.
Sketching & Wireframes
I began to iterate design solutions through quick sketches. This helped me translate my learnings into design solutions. I presented early thinking to my product manager and lead engineer to test viability and feasibility.
I moved onto wireframes, addressing features and flows based on my design timeline. I presented these to my squad to again test viability and feasibility, and iterated based on feedback and learnings.
Some ideas were beyond scope and had to be simplified or backlogged.
Iteration 1
Unit sign off flow wireframes
Iteration 2
Iteration 3
HiFi & Testing
I translated my wireframe prototype into a high fidelity prototype through our design system.
With the high fidelity prototype I conducted both moderated and unmoderated tests. I used the results in the unmoderated tests - completed through Maze - to establish a System Usability Score (SUS) document.
Testing helped me uncover design improvements, and validated elements in the existing designs. SUS results were especially useful in gaining buy-in and confidence from clients.
Employers couldn’t find useful links
To mirror the student portal that performed well on this front, the useful links screen was accessed through the profile menu. 80% of employers were unable to locate it. For this, we needed to make access more obvious. My solution of a ‘Need help with something?’ banner was received very well by the clients.
We couldn’t deliver on all dashboard items
Through VDF sessions, I learned we did not have time or capacity to build all dashboard items on the home screen for employers. For this, we identified the essential actions (training plans & unit sign off) and validated this with clients and users. This was approved, and the other items were put on the backlog.
Class list quickview valued by not essential
Although employers liked being able to quickly see students in a particular class from ‘Today’s Schedule’, it wasn’t a critical action. In order to limit development time and fit within our business timeframes, we updated this so just read the number of students within the class i.e. 3 students. The employer could then tap into the class details to see the full list of students expected.
Weekly view for schedule backlogged
Although employers expressed a desire to have both weekly and monthly views for their schedule screen, we were unable to deliver both due to business timelines.
We resolved that the monthly view has a wider usage for employers than the weekly view, allowing employers to see at a glance student schedules, making planning easier.
Dev Handoff & Implementation
Once the designs were endorsed by key stakeholders and clients, I began to prepare for engineering handoff. I worked on a dev-ready file that had features labelled clearly, had comprehensive annotations, and that any custom components were replaced by design system components.
I presented the hifi prototype to my squad, focussing in on particular flows when needed. I helped link designs to tickets, and answered design-related questions in jira tickets, the squad slack channel, and in daily stand ups.
When needed, I updated the designs to fit delivery timelines, seeking approval by key clients for any notable changes.
The portals V1 are now launched and TAFEs are migrating to them.
What would I do differently next time?
Organise sessions with end users sooner
When planning ahead, I could have requested user discovery and testing sessions sooner. Due to a lack of clarity and vagueness, it was hard to know when I should aim to talk to end users. In future, I would go ahead and request these sessions regardless of where I’m at in the design process. I was always able to gather feedback and uncover insights, even without a full prototype, for example.
Ensure all questions in unmoderated tests return usable data
A couple of my questions in my unmoderated tests were too vague, or the prototype flow was too specific. This meant that some data points were unusable due to test parameters rather than the designs themselves. In future, I would test internally before launching the test externally to identify any shortfalls.
Document process more
It became important for me to show stakeholders and the wider product team my process to arrive at certain design solutions and stages. Having a record of my tasks and learnings that I can quickly refer to and share with stakeholders is something I will continue to do moving forward.
Weekly view for schedule backlogged
Although employers expressed a desire to have both weekly and monthly views for their schedule screen, we were unable to deliver both due to business timelines.
We resolved that the monthly view has a wider usage for employers than the weekly view, allowing employers to see at a glance student schedules, making planning easier.