We’ve been running design sprints for over 10 years. Over that time we’ve built up a bigger and bigger list of things that we know about design sprints. That list of things has been kept in a few places, including our Playbook, our website, and internal documentation. Many resources were spread across different services, all this made it harder to maintain and caused things to get out of date. We realised that we needed to refresh, and build a new place to store all that knowledge.
In short, we’re pleased to announce that a new guide is live, we’re building it in the open, so it will be getting even better constantly. There are more details on how you can give feedback and contribute to the guide after a short history of the project so far.
Researching the issues
When we surveyed our team about why this might be happening we found that:
- Many of us were now unfamiliar with the technology used to build the guide.
- Getting the guide ready to improve on our own computers was getting more and more difficult.
- The guide had a single track and opinion on how to run a design sprint, making it hard to add new exercises.
We also found that we were tweaking, and changing the way that they ran design sprints in a lot of different ways, some taking inspiration from the thoughtbot guide, the Sprint Book, and many other resources to tailor design sprints to the needs of different clients.
Starting fresh
With all of this in mind we decided to start a new guide that would meet all of these needs.
The first step in the process was to gather all of the current resources we had, in all of the guides iterations, and reorganise the information architecture to fit better with our new ideas. The biggest changes were:
- Separate exercises from a design sprint schedule, making it easier to browse exercises separate from a set schedule.
- Allow for more than one schedule. We can now add as many as we want, from a bigger pool of exercises.
- Add a list of resources that can be attached to exercises, and schedules. This includes whiteboard templates, testing scripts and other helpful tools.
- Add a list of common FAQs.
- Add a glossary of common terms and jargon.
Once we had an idea of the structure of the new guide we made some choices to help address the concerns about unfamiliar, complicated, and outdated technology:
The biggest change was to build the new guide using Eleventy. As a team we appreciate how simple and un-opinionated Eleventy is to configure, build on, deploy, and run locally.
As the amount of content grows we plan to adopt Decap CMS (formerly Netlify CMS) to keep the friction of adding new content as low as we can, without sacrificing simplicity. Like Eleventy, Decap CMS is straightforward to add to an existing project, and is configured using a single file.
The guide itself is deployed and hosted on Netlify, we particularly like how simple it is to deploy to Netlify, and the automatic branch and pull request previews make testing new features very easy.
Plans for the future
The guide is now richer, and more flexible than ever. As we move forwards we plan to:
- Add even more content.
- Add even more schedules.
- Integrate Decap CMS more as the content grows.
- Improve the curation of content.
- Explore more ways to collaborate with the whole design sprint community.
How you can help
We’re building the guide in the open, meaning that entire source code is available to view on GitHub.
We encourage you to contribute where you can, we’re happy to hear about typos, and we welcome new content and ideas too.