The client is one of UK's top universities, and is part of the Russell Group.
To deliver digital-first processes across the entire student lifecycle for staff and students to increase self-service ability, reduce administrative burden and thus free up time for staff to focus on those who most need their help.
The project had six areas of interest:
I led a team on focus areas of; Admissions, Graduation and Student Finance.
- Autonomy - Each department runs with various levels of autonomy and so processes and support are also varied, and in many cases were duplicated
- Manual work - Many departmental processes were based around local tools (e.g. Excel on network drive of applications to be reviewed) and often resulted in things ‘falling through the gaps’
- Out-the-box - A key project aim was to keep customisation of the core IT systems as low as possible, leading to a high risk of disconnects with how and why existing processes are run
- Buy in - Some segments of the university’s staff did not believe it was ‘worth [their] time’ to engage in the project
Interviews, personas and journeys
The UX team undertook several dozen interviews across the university and developed 6 student, 3 staff and 2 lecturer personas and associated journeys.
The student personas were mostly based around the needs of different years of students with a secondary axis of specific student types (international, disabled etc).
- First year undergraduate students need more guidance on areas such as university life, studying, social groups
- In comparison, final year undergraduates are well established in their university life, but together with the pressure of exams, need support in what comes next; post-graduate study, getting a job etc
- Post-graduate students may need some settling-in support if they have moved university, but need very different support in navigating areas such as; research grants, doctoral thesis process etc
Staff personas focused on different types of administrative staff and if they were central or department based. The lecturer personas were split by lecturing and administrative duties.
These interviews also laid groundwork for the future deep-dive workshops.
The main process for gathering requirements, discussing processes and documenting system designs was through workshops.
Initially shorter, high-level scoping workshops were run for each of the functional areas to understand the as-is process, differences across departments and document a backlog of work to base the scope of future design workshops.
These workshops were based around activities to encourage collaboration and ensure a shared understanding, many coming from Design Thinking, such as:
- Stakeholder mapping
- Process flow mapping
- 5 whys
- Crazy-8s ideation
- Cost-value mapping
- Backlog brain-dump
- User story pointing
As the workshops had subject-matter experts from a variety of departments, they very quickly highlighted those areas with discrepancies in process which would require more effort later on to fully understand and work towards standardisation.
For many of the workshop participants it was the first time they really had to think about ‘why’ they do things in a certain way. Normally people are too busy doing their job to step back and analyse it.
Unless you give staff the time, space and support to review how and why they do things, then they won’t, and things are very unlikely to improve.
Process & design workshops
The top prioritised user stories from the outcome workshops were brought in to process and design workshops where they were refined and detailed out with acceptance criteria.
This was the first of two difficult steps, reaching agreement across the university on how, for example, admissions reviews should work. A relevant lecturer often needs to review an application, but many see this as a distraction from their ‘main work’ of research, and so departmental administrative staff had to figure out what worked best, often variable per person. Sometimes an email with an application attached, other times printing out and putting on their desk and so on. Each of these methods required the administrative staff to chase, not to mention the potential data security risks.
Initial plans to have lecturers access a core system page with a list of their assigned reviews was quickly abandoned after insights showed lecturers often do not use internal systems due to their complexity. It needed to be as ‘one click’ as possible. This resulted in designing a workflow that emailed a lecturer once they had been assigned a review. The email would contain a link to a custom webpage, which showed the relevant parts of the application, followed by key questions to be answered. Reviews that were outstanding would be emailed again at set intervals and administrative staff alerted so they could chase in person. This kept all the data on the secure service, and not littered across inboxes, shared drives and printers.
As part of the design workshops the team and I would create prototypes of proposed screen flows and functionality, first for playback to the workshop, then for usability testing, and finally as one of the documented outputs handed over to the build team.
Various tools were used throughout the project, from simple paper sketches to high fidelity mock-ups in Axure. Peer reviews were regularly undertaken to ensure consistency of design, style and format across the different workshops.
In line with the workshop cycle, usability testing was regularly taken with user groups appropriate to the designs for testing, aligned with the personas.
Each testing session had around 6 users, and was run by the four workshop teams in parallel, often meaning users would rotate around. In my workshop I would either facilitate or note-take, switching with my colleague as they built confidence in managing this activity. After each session, any key summary points would be converted to backlog tasks from the detailed notes and a verbal report given to the workshop participants the following morning.
Some of the general takeaways from this testing were:
- Students have high expectations of digital services, and many anecdotes were given of where the university was falling short
- Despite all students requiring a minimum English level to attend the university, keeping the copy simple avoids any confusion, especially when explaining specific topics (e.g. finance)
- Consistent with internet users generally, people do not read instructions
The workshops involved over 100 stakeholders and resulted in successful, new features such as:
- Student “My Finance” dashboard, allowing students to make payments for tuition and accommodation fees at any time, set up direct debits, update bank details, check when payments are due and view their financial history
- Admissions review portal, allowing administrators and lecturers to assign, track and review applications from potential students, all while keeping the data secure and reducing review turn-around times
- Graduation management system, using a customer relationship manager (CRM) platform to help plan for and track attendees for the dozens of graduation ceremonies the university has to run each year, including catering, gown rental, seat assignment, pamphlet printing and more.