Blog, Events & News
What Is a Design Sprint and What Does It Aim to Achieve?
By Netacea / 13th Aug 2019
A team of Netacea developers, data scientists and product managers recently carried out a design sprint as part of our ongoing activity to move our platform on to its next phase.
To understand a little more about what a design sprint entails, who was involved and the sprint’s objective, our Senior Product Owner Ben gave us the ins and outs.
Why did Netacea carry out a design sprint?
We could pick something up from the backlog, build it and put it in front of customers but that takes a long time and requires us to go into quite a lot of detail without knowing whether what we’re doing is right.
The design sprint gives us a shortcut to test our plans with customers and internal experts before we commit to building anything. Doing a week’s worth of work is a lot easier than a few weeks or a month’s worth of work.
How does the design sprint differ to our previous approach?
Previously we have identified requirements, worked out designs and basically carried out all the work upfront. We were committing ourselves to the idea.
The design sprint allows us to test and make sure it’s the right thing for us to do before we start to build anything.
What do you want the sprint to achieve?
Our most recent design sprint was very much about targeting accuracy and automation.
We started off with several interviews with experts from around the business and customers. We asked them a lot of questions to find out how they would like to use the platform, not how they use it now.
This gives us an indication of what problems we need to solve and then throughout the week, we carry out a problem statement activity called How might we.
Over the course of the week we get to a point as a group where we will come up with a possible idea and build that into a prototype. That prototype isn’t put live but is used to test out the idea and the concept.
We use the prototype to get feedback and incorporate this into the next iteration.
Who was involved in the design sprint?
We actually had quite a large number of people involved. While normally a design sprint might consist of seven to nine people, we had eleven.
That number included four developers and two data scientists. Because of the mix and match between data science and dev, rather than trying to make do with what was available, we were able to get the people we actually needed in the room.
It worked out really well and we got multiple ideas moving.
Who was involved in your expert interviews?
Typically, a design sprint utilises customer feedback almost exclusively, with some input from internal experts. However, we found it useful for our first design sprint, to flip this on its head and work predominantly with our internal team.
This is great because everyone wants to help and it also allows us to bring in a range of experience with the portal. Some of our experts are power users, who use the portal day-in-day-out, while others may have only interacted with it once or twice.
Would you consider the design sprint a success?
The first user test, as should always be expected, received the constructive feedback we required to move the prototype forward. Constructive feedback is much better at this stage than after we’ve built it, so we’re now able to play around with the prototype and fix the problems, incorporate the correct copy and work with people around the business to figure out how we progress.
We’d always rather receive that feedback now, when we’re better able to fix, than further down the line.
What are the next steps?
In the week following the sprint, we have been running iterations with the feedback and testing this with various different people. We then have enough information to decide whether or not the concept is good, if it’s not then we go back to the drawing board and if it is – which this one seems to be – then away we go!
At Netacea we take a smarter approach to bot management, discover how we do things differently today.