Designing a new degree finder collaboratively and iteratively
I’m looking ahead to the replacement of our current undergraduate and postgraduate degree finders. Defining what we need to support student recruitment in 2022 and beyond is tricky. In this post I explain how I believe design sprints will deliver this.
The Design Sprint book was published in 2016
What’s a design sprint?
Design Sprints are a process pioneered by Jake Knapp and colleagues at Google Ventures, leading to a book they published in 2016.
It’s a 5 stage process (originally done over a week) in which a small and diverse group set out to:
- Understand a problem space and focus in on what the sprint will set out to try and solve
- Rapidly explore many ways in which others solve similar problems, and generate ideas from this
- Collaboratively decide what we believe to be the best approach to be from the range of ideas we generated
- Turn these ideas into a prototype which can be trialled with representative users
- Try out our prototype solution with a small number of users, ensuring everyone involved in the sprint process shares the learning experience.
The 5 stages pf a design sprint: Understand, Sketch, Decide, Prototype, Validate
Explore the Design Sprint book
Since the book launched, the technique has been adopted by major organisations all over the world to explore design problems and try out ideas with customers quickly and cheaply.
Underneath it all, if you’re familiar with user research and design thinking techniques, there’s nothing really new here. What is new is the package that pulls people into a swift collaborative and creative process to align on, create and test a concept.
What’s a design sprint? A 2 minute summary for beginners on You Tube
Read this book and do what it says if you want to build better products faster
Ev Williams, Founder of Medium and Twitter
That’s a pretty compelling promise on the front cover, right?
It’s exactly what we need too: deliver demonstrably better products for prospective students and the staff recruiting them, and sooner rather than later.
Why bother?
With the help of a few graphics I’ve borrowed from the book, I can explain…
The problem with many projects
Our typical development model at the University means that we don’t learn whether we’ve built the right thing until it’s too late
Learning late in the service or software development process is problematic.
Why? Because learning late means problems that come to light don’t get fixed resulting in bad usability and tools that just don’t do what users need them to. Or developers undertake rework which is both expensive and time consuming.
As time on a project passes, the desire to fix problems for users recedes due to decreasing time, and increasing complexity and cost.
And why do we get ourselves into this position? Because we prioritise delivery over learning.
Despite all evidence to the contrary on project after project, we believe we can define up front what we need and then just go ahead and deliver it. And we hold off exposing users to the new software or service until late stages.
When we don’t prioritise putting our work-in-progress in front of users, we fail to learn until it’s almost too late.
How approaches like design sprints differ
The following benefits aren’t exclusive to design sprints. They’re true of any human-cented development process. As I mentioned, if you’ve undertaken user research or collaborative design activities before, the process will be familiar.
To summarise the proposition, what if we found a way to bypass the expensive and time-consuming development and launch stages and jump straight to the point where we find out whether our idea is a good one?
Prioritising learning over delivery builds better software, faster.
Going back to the realness/time graph, what we’re talking about is this:
The sooner an idea is real enough to put in front of users, the sooner we learn.
Building facade
The point about this being a facade is fundamental here.
Our work with design sprints won’t deliver us a new degree finder. But it will deliver a design concept that we’ve seen many students interact with, giving us confidence that what we build will be fit for purpose.
Building and testing a facade is ofter referred to as ‘Wizard of Oz’ testing in reference to the famous scene in which the “Mighty Oz” is revealed as a man frantically working controls behind a curtain.
There will be a lot of ‘Wizard of Oz’ moments during our sprints. We’ll be giving students a glimpse of (and more importantly the chance to interact with) a potential future state. While Gayle is facilitating user interviews and usability tests, others in the team will be frantically pulling the digital equivalent of levers in the background to maintain the illusion of a working service. Aaron will be patching our learning, sprint after sprint, into a master prototype which we want to be able to share to colleagues on an ongoing basis.
Learning from others
I mentioned earlier that many companies have adopted the design sprint approach, and many have adapted it to suit their situation. We will be no different.
I’ve been chatting with contacts in and out of higher education about their approaches, with the intention of adopting their best bits and avoiding their pitfalls.
Among the people generous and open enough to share have been colleagues at the University of Dundee who embarked on a similar path to us back in 2018.
Read about design sprints at the University of Dundee (Digital Design Team blog)
What will our design sprints look like?
Design sprints undoubtably take commitment. A recurring theme I’ve encountered when talking to others is that it’s very difficult for a suitable range of people to commit significant periods of time.
So I’m expecting us to focus the broad collaborative activity on the early stages, and then leave the prototyping and testing phases to the Prospective Student Web Content Team.
I’ll shortly be reaching out to colleagues across the University to get involved as there is no doubt that the best solution for the University will be one generated through collaboration between colleagues in schools and colleges, in central services, and in specialist teams like ours. (UPDATE: My blog inviting colleagues to get involved).
…the best solution will be one generated through collaboration between colleagues in schools and colleges, in central services, and in specialist teams like ours.
We will be piloting our approach during the early sprints of course, but I broadly expect us to be doing the following:
- Refining the problem the sprint will solve, generating lots of solutions ideas and prioritising them
- Done with student recruitment specialists from schools and colleges, plus relevant central service staff
- Completed in two roughly half-day workshops
- Generating a functioning prototype and a corresponding user research plan
- Done by the Prospective Student Web Content Team
- Completed over the subsequent 2-3 days
- Testing the prototype with prospective students
- Done by the Prospective Student Web Content Team
- Played back to everyone involved in the sprint, plus any other colleages who want to see what we’re up to
- Playback and reporting process will take 1-2 hours, generating consensus on what prototype concepts to keep, refine or kill off.
If you’ve ever attended a usability testing playback workshop that I’ve run, you’ll be familiar with the rapid and inclusive format.
Read a previous blog post about a usability testing playback session we ran
Get involved
Colleagues in schools: I’ve written a blog post about the kinds of contributions we’re looking for, and set up a form so you can register your interest. Learn more and get involved.
Colleagues in central services and college office admissions: I’m approaching heads of services directly (late March) to check availability and try to schedule design sprint topics accordingly. If you were expecting to hear from me and haven’t, get in touch.
Neil Allison’s contact details on our team profile page
(Images from the book: Sprint - how to solve big problems and test new ideas in just 5 days )
12 replies to “Designing a new degree finder collaboratively and iteratively”