The University of Southampton
Digital Team Blog

What we’ve learned from doing a design sprint

A few weeks back we did a design sprint for ‘Become an undergraduate student’ undergraduate course pages.

What is a design sprint?

In a nutshell: design sprints help solve big problems in a short period of time by exploring and discussing ideas. They help generate a strong, effective solution to a problem. In this particular case it was around undergraduate course pages.

Ironically, design sprint is not just about the design. The challenge may actually be more about the functionality or the content than the design. The process for design sprint is a very structured design thinking process, and it translates business objectives into actionable insights in just a few days.

Sounds great, right? But in reality what does it mean?

You can’t fight silos with silos

“We tend to get caught up in busy work — attending meetings, shipping one feature at a time; eventually losing sight of our north star.” – Neha Saigal

Most organisations know what their biggest challenges are. Although, it can be tricky to reach a shared understanding of a problem, and even harder to get to a solution. This is especially true when you operate in a large organisation like our university, where responsibility and accountability to a business problem might be scattered amongst individuals, departments and directorates.

An example of organisational silos 

So, how do you align siloed teams to come up with a plan? You got it – enter Design Sprints.

We ran a design sprint

We were lucky enough that Winchester School of Art’s (WSA) campus opened their doors to us, and we assembled a small team of digital ‘experts’ from disciplines of User Experience (UX), tech development, content strategy and design, user research and product. We also invited Alastair and Adam, our academic colleagues who have deep interest in human centred design and Andreea, a 2nd year Game Art and Design student to be part of our team to add extra knowledge, expertise and represent the student voice.

It was intense few days. For me, it was great to see the power of bringing a group of experts to one room for 4-days and solve a problem or answer a question. It was great to see how Alan, one of our Service Designers, facilitated everyone through a process that helped align the team around what we were looking to solve.

By the end of the sprint, the team have come up with a potential solution, sketched it, built it  –  and what’s best, they have tested it with real users.

Source: Jake Knapp and Google Ventures 

Alan and I thought to share with you a summary of some of the highlights from the process, including some great little clips we took to allow you peek into what we’ve learned and what we would do differently next time. Here we go:

Day 0 – 8 May

Unlike typical sprints, we actually started the process a week before by challenging the current university’s brand proposition. We didn’t want to discard the current work done on the Undergraduate campaign and brand work, but we felt it is important to understand who we’re designing for and how we can build on it in order to create a superior experience online. The outcome of this workshop with senior managers and executives was to set out the brief for the design sprint the following week.

Day 1 – 13 May

Coming into Day 2, most of us didn’t know what to expect. Although the majority of us have participated in design sprints previously, we’ve never worked together in this way. This is because many of our OneWeb team members are new to the university, and because we are not co-located, so haven’t had the pleasure working with each other in this way.

The day was spent sharing information, assessing the opportunities and aligning the team around a common goal. We heard about 8 May workshop, I set the context to OneWeb and the university’s vision, Nick talked about user research. We had data and insights from previous work and we agreed on the design sprint objective and questions we’re looking to answer.

The latter part of the day was starting to sketch ideas individually so we can talk about it the following day. This part was very hard, especially to those of us who are very familiar with the sector and our website. We also had time constraints and had to come up with something within 40 minutes. It’s amazing what time boxing can do to push everyone to the next level!

Some of the many sketches from the day

👉 Here’s Adam’s podcast on his first day.

Day 2 – 14 May

After spending day 1 sketching and ideating, we spent the morning talking through each idea. Alan did a great job presenting each idea. We also walked around the rooms and halls and voted for the ideas that we liked the best.

Alan in action: presenting our ideas

The final casting vote was with me, as the Product Owner for the user experience. It was really hard because there were so many worthy ideas. But the decision was made and the next step was to storyboard what we’ve agreed on in more detail. That’s where we got to at the end of the day.

👉 Adam did another podcast sharing his thoughts of day 2.

Day 3 – 15 May

Prototyping day. We agreed roles and responsibilities in the morning and Alan reminded us all of what we’re here to do. So, with lots to do, the team worked on the prototype, splitting up the tasks and using Invision to create something we can test with our users. It was a long day, not without its challenges.

Day 4 – 16 May

Testing day. When all your hard efforts make sense. A very exciting day for the team to hear first hand what our end users really think of the prototype. Nick, our User Researcher, conducted 6 interviews.

We had issues with some no-shows, but thanks to our lovely student, Andreea, we were quick to fill in any gaps. We also used this opportunity to test it with some Postgraduate students to check what elements are common patterns to both user types.

The outcome

We felt that we were much better informed about our solution, and we’re clear about the next steps we need to to take. We had some first sketch of design principles and ways of working, which we will write up properly and communicate with you all.

We also managed to answer all our sprint questions and feedback from users brought up some additional elements that we need to take into account. The bottom line – we know what we need to do in order to make our course pages better. All of it, in just a few days.

Lessons learned

As with everything, we know there are things we should change, and areas that didn’t quite work for us.

  • We had some users’ feedback on areas that we still need to consider.
  • There is always a temptation to bite on more than you can chew.
  • Too many user interviews, but some didn’t show up.
  • We’re thinking that it would be useful to have some contingencies planned in this area.
  • We all have biases and also too many great ideas! 💡
  • As a group, we like talking! Definitely less talking, more doing. 🙄

What’s next

In just a few days the team had outlined a goal, defined and validated a concept and knew what it would take to achieve that Vision to help us deliver for 31 July and beyond. We created alignment around the problem and validated solutions with real users and got actionable feedback. Design sprints can save the university a lot of money in the long run.

As part of the OneWeb programme, we are now considering how we built it into regular chucks of work and get more of YOU to be involved in this process. So, please keep up to date with our news and show and tells. More on this soon.



Share this post Facebook Google+ Twitter Weibo