Design Sprints at Archimedes Digital
When clients partner with us, they find we do things differently to most other agencies they’re used to. One key differentiator is our innovation process at the start of a project.
What is a Design Sprint and why do it?
A design sprint is bootcamp for your product idea. The goal is to create and validate product-solution fit, before investing time and money into the build. It’s one great exercise in reducing risk and cost for your product.
In layman’s terms, we check whether the idea has wings before building it. Why? Because we don’t want you spending your money building an elegant square peg for a round hole. Deciding what needs to be built is crucial, and getting this wrong sets a shaky foundation for the rest of the project. We don’t want to do that.
The Sprint takes course over 2–3 weeks. In some cases it can take longer, but in most cases that’s the time-frame you’d be looking at. If you’re in a hurry we can expedite this process. Our record is 1 week, but any shorter than that and we risk not carefully thinking through the project, and making poor assumptions for the sake of hurrying the process — a recipe for long-term failure.
Meet “sync” and “async”
If you’ve never worked with a remote team before, we have two new words to introduce you to: “sync” and “async”. (Synchronous and asynchronous.)
Sync is when we get together on a video call. Everyone blocks out the same time slot in their calendar, and we meet to discuss the project.
Async is basically email and our “whiteboard in the cloud”, Realtimeboard. We collaborate, but everyone does it in their own time.
Our design sprints use both sync and async techniques.
Usually we meet on a video call about once per week. Some things are best expressed face-to-face.
The rest of the time is spent async. Some work is best done when everyone can focus on it in their own time. We’ll take your ideas and requirements, and we’ll get cracking on mapping out a vision for your digital product.
Part 1: Define the problem and goals
Hypothesis
We aim to eliminate guesswork, opinions, and assumptions as much as possible. Instead we aim to be scientific, and logical in our product creation process. Might sound like “corporate fluff”, but when this fluff saves you from making bad business decisions, it quickly stops being fluff.
The first step here is to write down a hypothesis of what we hope to achieve by building your digital product. We use this as our guiding compass throughout the project, and we later use it to measure how successful we were.
Canvas
The design sprint kicks off with a 1-page business plan for your project, called a LEAN Canvas. This defines the most important, high-level goals. We’ll revisit the canvas later. It acts as a guiding compass for our work.
Present research
If budget permits, we will conduct user and market research before the design sprint, and present the findings here. This’ll help validate (or invalidate) assumptions about what your audience needs in your product, eliminating further guesswork.
But, if you’re 100% sure that you “just know” that if you build it, your audience will come, then we can skip research altogether. Having said that, you want to be very sure about this assumption.
Inspiration board
Naturally we come to a project kick-off with existing ideas: features in other products that would work well for ours, art direction, typography, imagery, tone of voice, you name it.
The inspiration board is an exercise that extracts the ideas that are locked away in our minds, making them visible to everyone participating in the Sprint. This allows us to share ideas, and set early direction for the project.
Map
With our project requirements defined, we now roll up our sleeves and start thinking about our solution. Ahh, finally! First on the agenda, a “zoomed out” view of how the solution will work.
Here we think about the steps users will take using your product. How do they find out about it? Where will they land? How will their first impression be a delightful one? And how will we keep them engaged after sign up?
Part 2: Design the solution
Feature prioritisation
We all come to a new project with a solution already in mind. Here we list all features we can think of, discuss them, and rank them on a scale of how valuable, versus how costly they might be.
Prioritising features helps us make sure that we spend our time wisely, by implementing the most important ones first.
Mockups
With the hypothesis, and requirements laid out, and the features prioritised, we generate a clear vision for your product.
This highly visual way of presenting the solution, works great for everyone — clients, designers, developers. These mockups act as our “source of truth” for the product. It’s what you’ll sign off on, and it’s what we’ll use to give you a detailed quote for the build phase.
Taking a closer look:
User testing
It’s important to test on fresh eyes (people not involved with the project) to gauge whether people understand the product’s value proposition and if they will know how to use it, and better, if they’d be excited about using it.
At the end of the user test we’ll have a better idea if we have product-solution fit. We can leverage usertest.io to test with people outside of your typical audience.
A (mostly) democratic process.
During the Sprint, we’ll endeavour to make this process as democratic as possible. We’ll regularly shift between periods of async, and sync. And we’ll use techniques like dot voting to reduce group think.
At the same time, you are hiring us for our product design expertise, and we’ll need to ask you to trust us with the intricacies of the design and development work.
In other words, you point the direction where you want to take the ship, and we worry about what’s involved in getting there.
War room in the cloud.
Traditionally collaborations like ours would take place in what designers call The War Room. Because we’re remote, we do things a little differently.
Us being a distributed team doesn’t hinder us because we pick the right tools for collaboration.
- Realtimeboard is our Swiss Army knife for the entirety of the Sprint. It is our whiteboard in the cloud, and we can’t praise it enough.
- Trello is our board where we keep a list of all To-dos. Once we get into the build phase following the design sprint, it tells us at a glance where we’re at with the project.
We’ll organise access for you to both these tools, and help you get up to speed with them if you haven’t used them before.
What we’ll need from you before the Sprint.
- In preparation for the Sprint it helps if you send us all documents, links, assets, ideas, info, napkin sketches, anything that you’ve gathered preparing for your project so far.
- We want to talk to your target audience directly and test our prototype with them. If you can help us get in touch with ~5 people from your target audience, this will go a long way to facilitate research and testing.
What you’ll need for the Sprint.
- To maximise the chance of success for your project, we ask clients to block out 3–4 hours per week for sync meetings.
- You absolutely don’t need any prior experience in design, development, product strategy, or creating digital product. All we ask is for you to bring a can-do attitude. We’ll take care of the rest.
That’s our design sprint process in a nutshell. With a validated prototype, and detailed build estimates, we then move into the next phase of our process, the build of the actual product. If you have questions please ask us on contact@archimedes.digital.
