Meet partners where they are
Meeting partners where they are helps encourage a more participatory, and therefore sustainable, design process.
We view our partners as co-creators of our design process. We are especially mindful of their:
- Ability to participate
- Design maturity
- Remote friendliness
- Access to tools
- Security and privacy norms
- Policy requirements
Ability to participate
Partner participation is essential to our UX team’s principle of training design advocates. But just because an agency enters into an agreement with 18F doesn’t mean we take their ongoing participation as a given—we actively work to engage our partners at every step of the way.
At a high level, we encourage participation by:
- Building trust
- Respecting people’s time and expertise
- Respecting our partner agency’s culture (beliefs, norms, etc.)
- Approaching new contexts with humility
- Creating appropriate opportunities for our partners to participate in the design process and learn by doing
- Demonstrating success, especially with quick wins
- Clarifying our purpose (for example, with a problem statement)
- Using plain language
- Building shared understanding whenever possible
We also assume that people are:
A partner’s ability to participate inevitably affects our day-to-day work. We are honest and transparent whenever we feel that our partners are not participating as much as the work demands.
Some agencies explicitly choose to work with 18F so that they can build something that’s more user-centered (their goal) while also maturing their agency’s user-centered design practice (their subgoal). These engagements will begin by contemplating questions related to design maturity such as:
Initial level-setting allows us to help our partners level-up over time, and better measure how far they’ve come.
As one example: during a nine-week engagement in which our partner expressed interest in maturing their user-centered design practice, 18F determined our partner’s initial level of design maturity through stakeholder interviews (with their in-house designers) and contextual inquiry. We then identified three learning objectives and created a lightweight curriculum using backward design, a method from curriculum design in which you first define desired learning outcomes, then how you’ll assess learning before devising training material.
At the beginning of each week, for the first six weeks of the engagement, we sent 15-minute “homework” assignments as part of our weekly status emails. This got the team thinking about a particular aspect of user-centered design. Each email also corresponded with a skill-building workshop held later in the week. This helped us to simultaneously meet the goal of the engagement while helping the team mature in its user-centered design practice. By the end of this engagement our agency partners were planning their own research and moderating their own usability tests.
When design maturity isn’t a subgoal
Engaging partners in conversations about how they might level-up in their practice requires some willingness on their part. In cases where our partners don’t want, or don’t have the capacity, to learn more about user-centered design, we need to ask ourselves:
In general, people who are new to design will need to appreciate its direct benefits (like improved usability and customer adoption) before its indirect benefits (such as helping the team identify the most important problems for them to solve). Because of this, we aim to give your partners something tangible, and. Let them experience the show before pulling back the curtain.
18F is a distributed team for many reasons. For example, being distributed allows us to hire people who would not traditionally join government or move to DC, and it allows us to include a broader cross-sampling of people when conducting design research. Being remote-first requires that we maintain a number of remote-friendly practices.
That said, the majority of agencies we partner with are not distributed teams. At the beginning of every engagement, it’s helpful to ask:
Depending on the answers to the above questions we might:
Access to collaboration tools
18F has fairly unique access (within the US federal government, at least) to web-based collaboration software, including chat, whiteboards, wireframing, and prototyping tools. Our agency partners may not have access to these tools, or may be prohibited from using them the way we do. For example, they may be able to video chat, but may be unable to share their screen.
We coordinate with partners to identify which combination of tools will work best for our collaboration, often using a mix of communication tools already in use by the partner agency and new tools that 18F can share access to.
Our collaborations are frequently anchored by at least one or two in-person sessions, where we may use analog tools such as sticky notes, pencil, and paper, or conduct in-person research such as observation that can later be documented in a digital form.
Security and privacy norms
A big part of developing government digital services is managing risk. 18F relies on a number of platforms to create secure, compliant-by-default websites and web applications, including the use of Federalist and Cloud.gov.
As our work moves closer to production, our partners may ask us to help them obtain an Authority to Operate (ATO) for the products or services we’ve helped create. We often begin this conversation by identifying who at our partner agency will play key roles in the authorization process (such as authorizing official and system owner), and by following our Before You Ship guide. It can also be helpful to ask about:
We also meet our partners where they are by discussing privacy norms and relevant information practices. For example, 18F’s design research is defined by information practices outlined in GSA’s Privacy Impact Assessment for Design Research. However, our norms are not our partner’s norms; and just because GSA’s Privacy Office sanctions our design research program doesn’t mean that our partner agency’s privacy office will do the same (see legal and privacy). As we conduct design research on behalf of our agency partners, we may need to prompt conversation between the following GSA offices and their counterparts at our partner agencies:
- Privacy office
- Office of General Counsel
- Paperwork Reduction Act (PRA) Desk Officer
Practicing user-centered design in government is complex. In some cases, we can find that policy dictates decisions we otherwise thought were ours to make about how a product or service functions or how we carry out the user-centered design process. For example, as we helped build the new FEC.gov 18F conducted usability testing to see how our proposed designs might affect the site’s usability. If we were to suggest changes to the forms that campaigns use to file with the FEC, the FEC might be legally required to solicit public feedback in the Federal Register over a multi-month period.
As we collaboratively design with partners, we should ask:
We recognize our partners are working to deliver their missions in a complex ecosystem of regulatory, organizational, and technological policies and constraints. Taking the time up front to level-set on tools and practices helps set the foundation for a strong collaboration.