I knew our solution had to work for everyone at the University, so we ran successive rounds of qualitative user research and testing with staff members across the University - from lecturers to administrative staff and beyond. We also invited key stakeholders into workshops to capture their thoughts on existing processes and new requirements. This helped us to immerse ourselves in the current system to understand the failings, opportunities for improvement and needs of different people in the institution. During our formative research with UCL team members on the current system, we found that employees weren't sure if their changes had been saved or not. We tackled this through design by using different active states in the form fields to indicate completion and saving. This helped employees easily distinguish between viewing and editing. We also provided a clear review step, which presented all information about the request, and a save confirmation notification. Staff members found the existing platform unintuitive to use. Simple tasks often needed PDFs or explainer guides to aide completion without errors, as well as signing into a local VPN to gain access. This resulted in additional time and cost being invested and unforced errors creeping into what should be a smooth process. Among employees this caused frustration and detracted from their wholesale experience of the University. We focused on simplifying the information architecture and clearly signposting different areas of the application. This provided easy and quick access to the most common tasks an employee would undertake. We also helped to define a system for organising the different types of notifications on the platform from both an employee and manager view. By creating just 15 highly flexible and efficient components, and defining set styles, we were able to create 100+ pages across three breakpoints. Defining breakpoints like this allowed us to understand whether a component was consistent across all screen sizes. And if it wasn’t, this approach made it easy to understand how its behaviour differed. Each component also had a short description to offer a quick reference for designers when using the library. This ensured the correct components were used consistently across the current and future application. This approach helped us balance the variety of tasks which employees need to complete, and the sometimes intricate inputs, with the amount of design and development effort required to create this functionality. This opened up conversations with the Zensar engineering team and UCL's technical team. We enabled a high degree of reuse in design and development, speeding up both processes exponentially.