|
Getting your Trinity Audio player ready...
|
By Matthew Reynolds, Professional software developer, novice letterpress printer, and metalhead. Living in Kitchener, Ontario.
How much can a team, dedicated to exploring a given problem, achieve in three days? Which approach would they take in order to make the most of that time?
Recently, Capacity Canada hosted a three-day Google Design Sprint to learn more about a specific problem, then design and prototype a possible solution to that problem, and see how well that solution resonated with representative users. Design sprints were developed at Google Ventures, and (in their words) are a “‘greatest hits’ of business strategy, innovation, behaviour science, design thinking, and more.”
The process is fairly structured but still allows for creative muscles to be flexed in interesting ways.
The problem we chose to explore involves bringing together progressive, small- to medium-size non-profits and tech companies looking to give back to the community using their expertise. Small- and medium-size non-profits benefit most from the inclusion of technology at a strategic level. Their ability to deliver core services is improved, and fundraising capacity increases. We built a design team, recruited users for research and testing, and got to it.
So, what did we learn? What went right? What went horribly, horribly wrong? What would we change? (Spoiler alert: luckily, nothing went horribly wrong!)
Three things that went right…
Bring your A-Team
The Google sprint book recommends a team to be seven or fewer. We went with five (excluding the facilitator — the ‘Sprint Master’). This worked out well for us: we all seemed to get a chance to talk during discussions, and the cross-section of experience from each member was what we needed.
So, what about team member experience? How should what you know of people’s skills and work experience influence the team composition? In our case, while Capacity Canada is very familiar with the problem space, exploring options for addressing that problem was in its infancy. We needed the team to be comprised of sector experts (social/non-profit; technology) without necessarily being experts in the proposed solution. We hoped for open-minded, design-sympathetic folks first and foremost.
We were lucky to build our team with people whose personalities and skills complemented each other.
Interesting — and interested!
During the initial (pre-sprint) exploration of the problem, we’d conducted interviews with potential users. We’d tried the solution on for size, performing elevator pitches to anyone who’d listen. We read more white papers than we want to admit.
But, as this exploration phase progressed, we met some really interesting people! They understood what we were trying to do and were incredibly generous with their time and energy. (It takes energy to be interviewed and add value to that conversation!)
As a result of these initial interviews, and the strong community roots of Capacity Canada and the Sprint Master, the quality of our user participants was excellent. The feedback we received was fair, detailed, and presented within the appropriate context. Participants represented their organizations honestly and appreciated the scope of the work we were doing. In short, they were very helpful.
Feed the machine…properly
As some more progressive tech companies have discovered, if you feed people yummy, healthy food, they’ll keep working and make better decisions. Design sprint participants are no different! We had light breakfasts (fruit, smoothies, etc.), snacks for breaks, and balanced lunches (sandwiches, pasta, salads, etc.).
We didn’t need to worry/waste time thinking about where to get food or a drink. We didn’t need to make sure people got back in time after lunch. This system worked out really well.
Three things that we could have done better…
Big picture questions…
Part way through the sprint, our Sprint Master called attention to the fact that several conversations were causing the team to run well over the time window for a specific task. We all agreed that while the topics of these conversations were absolutely relevant to the larger system discussion, they were not specifically related to the problem we’d decided we wanted to tackle for this design sprint. They were distracting us and threatening to derail our progress.
So, what caused this issue?
In short, while the problem and solution (a web app) had been discussed by some members, the solution hadn’t been explored much from a business perspective. If this team were to hold another design sprint, part of the preparation would need to include answering some fundamental questions in order to create — and document!— that context.
The design sprint helped bring this gap to light while allowing us to move on.
Recruiting representative users
While planning the sprint, we hoped to get three representative users from each of the sectors involved. We didn’t have any problem recruiting users from local non-profit organizations. We did, however, find it a bit challenging to recruit participants from technology companies (often the companies indicated their HR employees didn’t have the time to spare, independent of their support for our project).
For any future design sprint, I think we’d need to reach out more widely to secure participants (especially tech company participants). Building on the success of this sprint, we might find it easier to persuade potential users with concrete examples of value.
Assembling the team
The team assembled for the design sprint had one thing in common: a good relationship with Capacity Canada. But the topology of the team was very much ‘hub and spoke’; all the team members knew the Decider (Capacity Canada’s CEO, Cathy Brothers), but many didn’t know each other.
So, while the composition of the team relative to skill mix was discussed prior to committing to a design sprint, how well that team would work together was relatively unknown. The Decider was confident in her choice of team members and, ultimately, the team was fairly strong. But we could have failed using an untested and freshly assembled team, especially during the prototyping phase. So perhaps we got lucky.
So, what did we learn?
The design sprint process was perfect for Capacity Canada for two reasons. First, it allowed us to get all the right people into a space to work together on a design problem. This isn’t always easy with people’s schedules; but, when we committed to the design sprint process — which included building the right team, blocking off time, and working creatively and with open minds — the results were exhilarating!
Second, the design sprint was an ideal way to meet and work with others in the community who could help design the solution (by contributing to our collective knowledge through user interviews and by providing feedback on our prototype at the end of the sprint). Designing in a vacuum is a horrible idea, especially after experiencing the thrill of great feedback from engaged users.
Many of the problems organizations tackle today are not straightforward: they involve many stakeholders, nuanced politics, and significant resource and design constraints. Running a design sprint allowed Capacity Canada to make a small investment of time and resources with measurable, actionable results. It mitigated the project risk by allowing incremental steps to be taken.
The design sprint process was born in Google’s venture-capital arm, but there is nothing in the framework which mandates a “high-tech” project. Put another way, it is a tool you can use for anything from a social enterprise innovation to exploring an existing customer problem.
And who doesn’t need another tool in the toolbox these days?
All photos, Matthew Reynolds
