Amiqus is one of Scotland’s leading technology startups on a mission to making civil justice accessible to everyone. As an 18-month-old product and a team of 24 people spread across four countries, we’re well versed in running projects remotely, and we like to think we’re pretty nimble. But even with all the tools, talent and agility you can pack into the months, there are always those big product challenges that are just that little bit too ambiguous or thorny to fit into the usual work week.
One such challenge was that in the space of four months, usage had doubled, then tripled but the product hadn’t evolved as fast and we were struggling to manage the scale of demand. A great challenge to have, but a challenge nonetheless.
Round about this time, a few new members had being added to the team and we were looking for ways to get them up to speed and involved in the product asap. Amiqus is a values-led company, one of those being autonomy and providing space for members of the team to pitch and run with ideas. I’d been itching for an excuse to get the team together for one of Google Venture’s flagship products…
Enter the Design Sprint.
The defining traits of a design sprint is that it is a time-boxed, focused, cost-saving and collaborative approach to getting a project started, unstuck and validated in the space of five days.
Our Sprint Team was made up of seven people from product, customer service and business. I was the Facilitator and the CEO was the Decider. We chose to adapt the original Sprint Book model to follow AJ&M Smart’s four-day version, a model that uses shorter exercises and where the full team only needs to be present the first two days. Read more about it here.
DAY 1 — AM: Defining the Challenge
After a quick introduction to the week’s outline of activities we dived into the Expert Interviews, where our CEO, sales support and business support leads each took 15 minutes to share their thoughts on the product’s vision, its areas for improvements as well as answer any of the Sprint Team’s questions.
Speaking about our core product Amiqus a tool that makes it easier for people to undergo identity and anti-money laundering checks online, the major issues surfaced were:
- Personalisation: large teams not being able to find their work in the shared dashboard.
- Notifications: the need for reminders and alerts when work was ready to be acted on.
- Work status: the lack of an overview of what work had been checked, was still underway or completed.
While the experts were discussing the problematic areas of the product the rest of the team were capturing notes and formulating them into “How Might We” statements. This structure forces the team to reframe problems as opportunities. The notes captured were then grouped into themes.
“How Might We” notes, turning problems into opportunities to tackle.
One key concept to Design Sprints is the “together-alone” way of working. Where in order to keep decision fatigue low, the facilitator sets the brief for an activity and each member individually writes their answers on a posit note, selects the best one to share with the team, and then everyone SILENTLY reads the solutions and votes on their favourite. It’s a bit weird the first time round but the speed at which decisions are made without endless debates quickly convinces everyone.
“At first I was uncomfortable about having so much process and rules around ideation, however I soon realised it helped to focus our efforts and surface the areas of value within exploratory concepts.” Caroline Smith, Product Designer at Amiqus.
The value of working this way and creating a collaborative space with people from all areas of the business was clear when the most voted Long Term Goal was defined by Lucie, from sales support.
“In a years time, we want to get maximum volume (checks and users) through the product smoothly and with minimum effort”.
From this statment, we drew the map and added the recurring top five“How Might We”s. In one morning we had defined the Sprint Challenge and had the outlines of a brief for the prototype we would be testing on day five.
Then we went for lunch. Nom.
DAY 1 — PM: Producing Solutions
The Sprint Challenge defined, we kicked off the afternoon by letting the team loose on the only activity that allows the use of a laptop: 25 minutes to scour the web for inspiring solutions to similar problems to ours. This was followed by five minute “Lightning Demos” from each team member highlighting what was of particular interest to our sprint challenge.
Inspired and caffeined-up, we shut down the portal to the outside world again and dived into the juicy business of sketching solutions. The Sprint Book calls this activity the “Four part sketch”:
- 20 minutes: Silently walk around the room gathering notes from the existing products and inspiration.
- 20 minutes: Privately jot down ideas and rough concepts, circle the most promising ones.
- 8 minutes: Fold a piece of paper into “Crazy 8s”. In each frame sketch a variation of your best concept. Spend only one minute per sketch.
- 30–60 minutes: On no more than three A4 pieces of paper, sketch your best solution in a three part storyboard. Ugly is okay, words matter and give it a catchy title. This is the only sketch that will be shared with the team, make it self-explanatory and keep it anonymous.
This process worked better for some team members than other. The main goal of this staged process is to challenge your first idea by coming up with many more and comparing. Personally, I feel the Crazy 8s is the most effective at putting the pressure on and forcing participants to dive deep and scrap the barrel for less obvious solutions.
The final sketch were then spaced out and pinned up around the room in preparation for Day 2: Decision day.
Feeling productive but getting a first taste of sprint exhaustion, the team headed out into sunny Leith for a much needed beverage.
DAY 2 — AM: Vote on solution
Walking into the office the next morning, the anticipation in the air was palpable. After reminding everyone of the Sprint goal and key “How Might We” questions, the experts were ushered in to witness the first visualisation of solutions to the product problems they had underlined.
The sketches were taped to the walls and window, ready and waiting… But of course we couldn’t just go in and discuss the ideas, there was a sprint process to follow! In order to not dissolve back into a normal meeting and uphold the “alone-together” process detailed earlier, each person was first issues unlimited sticky dots and told to SILENTLY walk around the room reviewing and marking the areas they liked. Once the dots were all spent, the facilitator then presented the concepts to the team, highlighting areas that were popular and doing their best to answer any questions about the sketch. During this part, the author of the sketch must remain anonymous and refrain from pitching their work. This is all to limit bias towards one person over another and force the concepts to be self-explanatory and concise.
Once the team was content they had understood each sketch they were invited to vote on their favourite concept, finally the Decider steps forward and casts their supervise as to which solution they want to see prototyped and tested.
Obviously this is an emotional part of the sprint, having your work presented and voted on (when you’re not even allowed to present it) is quite a peculiar and frustrating process. It’s fair to say the sketch authors did a great job at staying quiet even if they were squirming to chip in. However this prescriptive process did mean we covered substantial ground and reached a decision in under an hour. A usual show-and-tell powerpoint presentation would have taken the best part of the day.
DAY 2 — AM: Pick the right tools
We now not only had a concise Sprint goal, we also had the first rough draft of what we would be prototyping. The Sprint was also brilliant timing because Rik, our design lead, had just complete a large piece of work refining our UI Design pattern library. He took us through a master Sketch file that was full of components and resources for the design team to just drag, drop and edit into a high fidelity prototype — thus saving us bags of very precious sprint time!
DAY 2 — PM: Storyboard
The next step in the process was to produce the storyboard of the prototype. In the original sprint book the team is supposed to dive into mapping this out in 15 stages, this is harder than it sounds and can become bogged down in detail and unanswered questions. AJ&M Smart hacked this part of the sprint by replacing it with an activity to map the user test goals . At this point, I put my design researcher hat back on and formulated our “How Might We” into tasks for the user to complete during the study. These mini scenarios helped us keep focused on the task we needed to test and formulated the flow of the prototype.
Alongside all this activity, Lucie, our customer support lead, helped source and recruit the participants that would be testing the prototype in less than two days. It’s key recruiting happens alongside the sprint so that by Day 5 you have five testers lined up and ready to test drive the prototype.
Example test plan tasks:
“It’s Monday morning and you’re going through your emails, you see one from Amiqus, please read it. Have you seen an email like this before? What would you do next?”
“Back from lunch, you log into Amiqus to review any outstanding things that need your attention. (on the Dashboard page) What do you think this page is for? What information is most useful to you?”
Much as framing the storyboard with the test plan helped us focus, this part of the sprint is not to be underestimated in terms of cognitive load and decision fatigue. The mood in the room at the end of the day was decidedly more subdued as the pressure was now on to decide, design and build the prototype fast. There were a few quiet mentions of “going too fast” and “needing more time”.
We adjourned, pensively.
DAY 3: AM: Make it real enough
By this point, we were dreaming about the sprint. In order to shake of the uncertainties of the day before and regain clarity and focus, we revisited out Sprint Goal and “How Might We” statements before presenting the refined Storyboard to the Decider for sign off before the build.
The Decider approved the prototype storyboard with a succinct “grand”. Relieved and energised, we divvied up the storyboard to be fleshed out into a testable product that was real enough to trigger honest reactions. Rik’s design pattern library in Sketch was used to design the individual screens and Invision to stitch them together in an interactive prototype.
The rest of the day was spent dividing, designing and conquering pixels.
DAY 4: Run through and prep for User Test
Lunch breaks were definitely a distant memory by this point, the designers were flat out producing the high fidelity prototype, the last few participants were being chased and confirmed and the posit note supply was running dangerously low. Our first trial user test was scheduled for the afternoon.
We were keen to get feedback in-situ in the user’s place of work, therefore we had to figure out a fool-proof way to record and share the test laptop screen remotely. After looking at several options we decided to use our Youtube channel and privately live stream each session. This was great as it allowed anyone with the private link to tune in from anywhere without disturbing the test as well as automatically recording the session.
We ran the trial run at 3pm so that we would have time to fix any issues. At 2:45 the sprint team downed their tools and gathered in the “observation room” to watch our first real user navigate the prototype. The session went well, a few minor tweaks and fixes to broken links and we were ready to let real customers loose on the prototype and answer our burning sprint questions.
Sample Study Goals — what do we need to learn?
First gain an understanding of how current user of the product manage the high volume of checks through the system.
Test overall concept of a dashboard view and people view, if this separation would better support them than the current process and what information is important.
Test if the navigational change makes sense as a mental model for the AQID user.
Test if the notification emails and centre respond to their need of being notified of where to focus their attention.
DAY 5 : Watch, Learn & Validate
We had five target users lined up, defined as “Letting Agents needing to verify their client’s identity and use Amiqus to run at least 200 checks a month”. These were spread on either sides of the city with very short intervals between sessions. Manic biking, tramming and taxiing ensued but we made it out to each participant as scheduled, albeit a little out of breath.
I facilitated the tests one-on-one with the interviewee while the rest of the sprint team tuned into the Youtube live stream. This worked particularly well for Amiqus as we are a 50% remote company. During the tests, the sprint team was arduously taking notes and categorising them into the specific task for easy comparison later.
The five sessions finished, I bike back to the office and logged in for the final debrief with the (now exhausted) sprint team.
The prototype held up, validate some of our ideas, killed off many others and also unearthed some really juicy insights. As we went through the team’s notes, patterns started to emerge and the path to how we could rethink and redesign the product became clear. We were exhausted and spent but somehow energy and ideas were fizzing and the team was already thinking up what the next Sprint could be…
Sprintastic, but what did we get out of this?
For five days, reality was suspended and a number of us got to dive deep into the daunting task of figuring out how our product needed to change to handle the scale of growth we’re experiencing. From the user test we gathered insights that reshuffled our priorities, however, as we come out of our Design Sprint bubble, some of the changes research proposed were pretty chunky in terms of product overhaul and so these have been pushed to later in the year.
Working collaboratively for a week really brought the team together and everyone up to speed on our current challenges. However, for the next one, we agreed we’d want to include more people from the wider team, we mainly had business, sales and design for this one, keen to bring in insight from the development and marketing side too.
As well as a bank of tested concepts, we also developed a fairly robust remote user testing and screening technique. Using Youtube Live, our team was able to dial in and follow along from all parts of Europe!
“It’s incredible how much can be achieved in such a short space of well focused time, bringing our design team closer together in the process. It was evident that having a clearly defined goal is incredibly important to produce a valuable output from a design sprint.”
Rik Hudson, Design Lead at Amiqus.
Design is at the heart of what we do at Amiqus, we’re looking for talented UI/UX designers to join our team. Interested? E-mail [email protected]
