Unlocking progress in Higher Education

We all encounter roadblocks or tricky problems from time to time that can seem overwhelming and insurmountable.

Multiple stakeholders, funding issues, red tape and complex internal processes can combine to make universities a playground for indecision and stunted progress. One way we work with universities is to help them see the light through any given problem, and a path through to action and the outcomes they need.

Sometimes all it takes to gain clarity is reframing the problem and finding a new path to the solution. Recently, I've been working with UCL’s Head of Student Digital Experience, David Goddard, on a project they were struggling to find a way forward on. We conducted a webinar titled ‘Unlocking progress and solving problems faster in higher education’, which delved into the design sprint process and its applications in higher education settings, using UCL as an example. In this blog, I walk you through why we took this approach, how we did it, and why it worked.

How do you solve a problem like… stunted progress

Progress on projects often, quite simply, just doesn’t move fast enough. From full calendars to busy schedules, gaining momentum can take a long time. As such, hitting a roadblock can feel overwhelming and act as a real morale buster. Naturally, the focus then shifts onto another project with a path of less resistance, whilst the original problem sits there unhappily with its arms crossed – remaining unsolved.

So, tell us more about UCL’s problem…

UCL is situated in the heart of London. It’s an institution of around 50,000 students with a diverse field of academic study offered throughout multiple campuses – navigating physical spaces across different locations meant students often struggled to make the most of university hubs.

So here lies the problem: how could UCL ensure each student was getting the most out of their physical student experience and help students navigate their way around their labyrinth of a university campus? UCL was looking at a major investment to implement some way-finding technology, but they weren't sure what the right solution was. David and the team felt that an augmented reality (AR) solution would deliver what they needed. But they wanted to evaluate the options available to them throughout the sprint, test them quickly, and gain insights that would guide their investment to the right place.

So, how does the process work?

The whole point of a design sprint is to move rapidly. Here’s how the 5 days are often mapped out:

• Day 1: Mapping the problem – zooming in on the areas you are trying to solve and asking 'how might we...' questions.
• Day 2: Ideation – sketching out rough ideas and story boarding after 'crazy eights'.
• Day 3: Decision Day – which idea is the best and which will be taken forward.
• Day 4: Prototyping – replicating a real-world experience.
• Day 5: Testing – face to face with users

By the end of the 5 days, you should have a clear idea on a solution and a path to move the project to the next stage.

The method

Preparation is key. Here are some key ingredients to make your design sprint process optimal:

• Clearing schedules
• One large room (where the sprint can play out over the five days)
• Natural light (essential for clear thinking)
• Lots of wall space (for messy post-it-note walls)
• Source participants ahead of time for day five testing  
• Assemble your sprint team (the more diverse the better - people from design backgrounds, students, UXers, and stakeholders.)

The sprint

Day one is about peeling apart the problem.

It was focussed on zooming in to locate the crux of the problem: campus navigation. We then moved onto an ‘ask the experts’ segment, where we talked to subject matter experts such as university welcome induction teams, security teams, and IT architects to uncover key insights about the challenges we were facing. You need to get a 360 degree view into the problem so you can ensure that any solution won’t be constricted by a neglected factor later down the line.

Day two is all about sketching.

We kick-started the day into action with lightening demos – an activity in which everyone in the sprint was tasked with presenting a piece of technology that could be relevant or helpful to solving the problem at hand. This gave us an interesting spectrum of potential tools to use. The afternoon then incorporated an activity called ‘Crazy 8’s’ – a quick-fire storyboarding method where our sprinters had eight minutes to think up eight ideas. This acts as a democratising activity, flattening out any hierarchies, bringing energy and amplifying all voices in the room.

Day three is the decision maker.

This meant taking key elements from the storyboard and transitioning those into a big map detailing how our prototype would work. Day three is all about preparation for arguably the most important day – prototyping.

On day four we build the prototype.

We built our prototype straight into UCL’s app – ‘UCL Go’, to make the testing as accurate to the end-user experience as possible. We used Figma to do it, and then integrated AR software (NaviLens) as we wanted to test its effectiveness in delivering an accessible experience. We built in accessibility options to the app at this early stage, and guided by an accessibility specialist who was part of the sprint process, we set about testing a new campus navigation product for students with varying access needs.

Day five means it’s time to test.

Testing with five people (in-person) is standard in the sprint process and having them booked ahead of time is vital. We walked through certain scenarios using the prototype with the aid of scorecards to see how well each scenario played out. This exercise helped with final analysis, was fun for all involved, and we were able to witness in real-time how well our prototype fared against the real-lie challenges faced by students with accessibility needs at UCL.

So, did it help?

Did this process solve David’s problem? The short answer is yes.

Initially, David entered the design sprint process with the idea that VR would be the ideal way-finding solution for UCL. By evaluating options through the sprint (and being able to test quickly) he very quickly learned what people did need (and it wasn't AR...) which then guided him to invest money on the appropriate technical solution for the university.

David now has a solid foundation upon which the solution can be tightened, tweaked, and perfected with time.

Not only that, but David and UCL have also been able to build and foster new relationships outside of the institution as a positive by-product of the whole sprint process – now with new and bright partnerships for UCL blooming.

How about that for a sprint finish?

We recorded the webinar for those who couldn't make it and you can find it here.

Interested to learn more about how design sprints could unlock progress for you and your team – get in contact.