We’re thrilled to introduce the beta deck of 18F Design Methods, a collection of research and design practices that we use to better understand and serve the users of our products.
It’s amazing to think that this project started off as something folks did in their spare time — those odd minutes between meetings and at the end of the day — and to see how far it has come. What began as an opportunity for 18F to communicate more clearly across teams turned into something a little bigger. We realized that gathering and organizing our design methods could help us keep improving our shared understanding of how we work together.
We realized, too, that these practices could benefit groups beyond 18F: our partners and clients within the federal government, state-level agencies practicing user-centered design, startups and businesses everywhere, and people interested in learning these techniques. Encouraged by the value this collection of methods can offer (and the further learning we hope they’ll spark), we’re sharing them as broadly as we can.
How we got started
When the research guild — a group of 18F’s user experience researchers and designers — first conceptualized these Design Methods, we had no idea what the project would become. The undertaking started as a “hackathon” project (something to be completed within a day or two) but evolved to become a four-month project with a rotating cast of team members contributing their efforts.
We hoped the finished product would do the following:
- Offer an easy introduction to some of our favorite research and design methods to everyone who’s interested (inside and outside 18F).
- Create a shared vocabulary across designers and project teams, and eventually (we hope) across the federal government.
- Show how government agencies — including those without dedicated design teams — can do quick, comparatively low-cost user research to understand what citizens need while respecting federal regulations, like the Privacy Act and the Paperwork Reduction Act.
- Remove barriers that prevent designers from including tested methods into their design process.
- Provide just enough guidance to give designers the confidence to put a method into practice.
How they were made
The project was born from the realization that, while some of our team members have extensive knowledge of design methods, others have no idea where to start. Our initial intent was to create a tool to help people become more conversant in common design practices and start practicing them. Often knowing that a method exists, what it’s intent is, and how it’s done is enough to get started.
To understand how method cards might help product teams, we conducted one-on-one interviews with design leads across roughly 10 projects. We asked them about the techniques they used and any changes they’d made to enable these to work within government. We also spoke with developers and product managers to get an understanding of how they thought about the design and research they conducted.
Constantly shipping products and testing them out is part of how we work, so right away we designed and printed several prototype sets of alpha (initial-stage) method cards to get some quick feedback on our concept. The cards sat around our D.C. and San Francisco offices with signs asking colleagues to try them out and send us their feedback. We also conducted a few more formal usability tests of the card decks, which led to some changes in the beta version.
Beyond learning what people thought of the cards, we wanted to see how receiving a set would change people’s behavior. To find this out, we ran 18F’s first randomized, controlled experiment to measure how receiving a set of method cards affected people’s knowledge and comfort with our design methods. Our research showed that 18F teammates who received cards were slightly more knowledgeable and comfortable with methods than a control group whose members didn’t receive cards. (We’ll report more on this in a future blog post — stay tuned.)
Get your own deck
Check out the method cards online for more information. Our “alpha” digital version provides more details about each method, short stories about how we’ve used a given method in our work, and links to additional resources.
Principles that are and are not here
Every project has a different design process. Our method cards respect that. We’re purposely not offering a suggested order or set of methods. Rather, we’d like users to think of these cards as a palette of methods to pick and choose from. Both the online and print versions of the cards are grouped into phases. These aren’t a set of steps each our projects goes through sequentially, but modes that every projects goes in and out of. Bottom line: Use the cards in whatever way yields the greatest benefit to your team.
There are several excellent decks of method cards out there, but none that we have found are tailored to doing design work in the government. Our cards offer guidance to anyone in the federal government wanting to do user-centered design. For the most part, the processes we use are the same as those used in the private sector. However, we have additional considerations, legal and otherwise. To stay on the happy side of the law, take a look at Recruiting, Incentives, Informed consent, Privacy, and the Paperwork Reduction Act. No matter which methods we work with, these are the fundamentals of our design research.
Like everything we do at 18F, our method cards are entirely open source. That means you can clone, fork, modify, and improve both the online and physical versions of the cards. If you have access to InDesign, you can also customize our template to fit your own needs and make your own card set. We can’t wait to see what you do with them!
What’s next
It’s our sincere hope that people will freely take and use the method cards we’ve created. Our team put a lot of care into this first release, and we look forward to collecting feedback that will help us continue the effort and allow us to improve our work as we go. We know we couldn’t include everything in this version — in fact, we’re just getting started. We’re incredibly proud of what our project team has researched, crafted, tested, and improved upon. Everyone pitched in when they could, and the output is something we are all proud of.
To share your feedback with us, open an issue or pull request on our GitHub repository. We’d love to hear how we could make the method cards even more useful to you.
Project team: