Good customer experience (CX) in government is critical to meeting the needs of the public and agencies alike. Not only is CX a guiding principle within the 21st Century Integrated Digital Experience Act (IDEA), but it can help foster trust in government services. The Office of Management and Budget’s Section 280, Circular A-11 defines CX as:
The public’s perceptions of and overall satisfaction with interactions with an agency, product, or service…[Customer experience] refers to a combination of factors that result from touchpoints between an individual, business, or organization and the Federal government over the duration of an interaction, service journey, and relationship.
Surveys are a typical starting point for measuring customer experience. I can see why — you can measure things like customer satisfaction with a service over time. However, surveys can be complemented by other efforts.
I encourage government practitioners to start with what you want to learn from users, and why, before deciding on a particular research method. This post includes a series of guiding questions to help you and your team brainstorm and select an approach for measuring customer experience.
Before thinking about what to learn and why, you should start with your overarching program or service goals. Learning itself is often not the end goal, but something that can help you understand if you are on track to reach a larger goal. Ideally, this goal or set of goals should already be established and aligned on by your program.
This is one of the most important questions to ask yourself and your team. Measuring and learning give you the opportunity to make decisions in service of a larger goal. Sometimes, information gathering is about fulfilling a reporting requirement, and that’s okay. Regardless, what decisions can this initiative help you make? What can this initiative help you do? How can you improve your program or service with these inputs? Is it to benchmark progress? Measure the success of a launch? Learn about user needs? Increase enrollment in a government program? Whatever the reason, being intentional about why you want to start learning something can clarify your objective and inform what you want to measure.
Next, identify which users you want to learn from. Try to add at least some level of specificity. “Members of the public” or “agency employees” may be too broad. “Members of the public who applied for benefits in 2024”, “taxpayers who are eligible but not enrolled in this program”, or “agency employees who processed permits in the last quarter” can help you make more informed decisions and more easily target these users during recruitment.
This Mad Libs-style thought starter can help you hone in on your own audience: [user type] who [have completed an action or fit certain criteria] within [timeframe]
A key aspect of customer experience is considering not just end users but agency employees or other stakeholders who administer or support your government program. Also, keep accessibility and underserved communities in mind throughout this process so you can provide an equitable customer experience. Later in this exercise, as you plan out what method(s) you’ll use to learn from users, you should consider ways to reach people with disabilities or whose first language is not English, like including multilingual content, involving interpreters in interviews, or ensuring a screen reader can access your survey.
Next, move onto what you want to measure. Other ways to ask this include, what do you want to learn? What can you measure that will help you understand if you are on track to reaching your goal?
Consider framing what you want to learn in the form of a question. “Why” and “how” questions are especially useful for identifying root causes and user context.
For each question you brainstorm, also ask yourself why you want to learn this, which can help you understand if they are in service of supporting a certain goal.
Then brainstorm what sources or methods make sense for collecting this information. Outline a few examples, like user interviews or contextual inquiry (best for “why” and “how”-based questions), analytics (best for “what” and “where in the journey”), and surveys (best for attitudinal-based questions, and to some degree “what” and “where in the journey”).
Find inspiration for different methods by reviewing 18F’s Methods cards.
As you choose a method or set of methods with your team, consider risks, limitations, and constraints, like timeline, budget, or administrative burden on the public.
Also be mindful of any tradeoffs that come with each method you’ve brainstormed. For example, it is easy to over-index on survey scores like Customer Satisfaction Score (CSAT). They have neat and tidy numbers and are easy to show on a slide deck, but they don’t provide context.
Surveys should not be created and analyzed in isolation. Instead, they should be part of a larger strategic effort. Consider pairing surveys with qualitative user research methods like user interviews or contextual inquiry that provide context into user behaviors, needs, motivations, direct observation of them interacting with your service.
Regardless of which method(s) you choose, you should see if there is any need for Paperwork Reduction Act (PRA) clearance. Your agency’s PRA Office will be a great resource for navigating this question. If you are conducting a round of user interviews or usability testing with 9 or fewer participants, you will not need clearance, according to PRA.digital.gov.
There are three ways you should answer this question for each item you’ve aligned on that you want to measure. The first is, when do you want to start gathering this information? And are there any limitations to how soon you can start gathering this information? If your method requires users to fill something out, you may need to wait until you have a significant number of responses, compared to a more passive data collection method, like web analytics, which you could already have at the ready.
The next question is, which points of a user’s service journey would it be most useful to collect this information? At the end of an experience? If they are eligible but not enrolled? Or somewhere in the middle, like if they have applied but haven’t received a decision? Would any of these points better serve your end goals or help you make more informed decisions?
The last question is related to frequency: How often would it be helpful to measure this information? For example, if you are benchmarking enrollment data, you may need to collect this information on a monthly or quarterly basis, compared to understanding user needs and pain points while designing a service, which could be done once, and possibly validated later after launch to understand if the new service meets their needs.
Finally, after aligning with your team and going through any other steps to prepare based on your method(s) of choice, you are ready to get started! How you implement your initiative will depend on the method(s) you’ve chosen.
Here are other resources on learning about your users based on different methods:
User interviews
Usability testing
Surveys
Analytics
]]>Ever wondered how the federal government, cities, towns and other groups get a .gov domain for their sites? The Cybersecurity and Infrastructure Security Agency (CISA) manages all these domains across the web. Similar to .com, .org, or .us, .gov is a ‘top-level domain’, or TLD. Enterprises use a TLD to register a domain name (often simply called a domain) for use in their online services, like a website or email. CISA sponsors the .gov TLD and makes it available solely to U.S.-based government organizations and publicly controlled entities.
We worked with our partner at CISA to build a minimally viable product (MVP) and new website for the .gov registrar. As part of the work, we planned multiple rounds of testing with a mix of participants to give us feedback. We also wanted to collect feedback from current customers as part of our research, so we suggested CISA build a customer panel.
A customer panel is a group of selected customers who voluntarily provide feedback, opinions, and suggestions about the registrar and the possible future state. This connection with real customers gave us an opportunity to understand what matters for people who use the registrar now. It’s often a faster method of finding participants “from the inside out” of a site or service as opposed to a broader, more resource intensive recruitment process “from the outside in.”
Some of the benefits of building a customer panel:
Current users of the service receive an email notifying them when their request has been approved. CISA added a request for feedback to that email, asking users if they would participate in a brief interview to share their thoughts on the present and possible future state of the service. We screened participants to understand their needs and goals, and asked if they would be interested in seeing the potential future state of the site. Those who agreed went into our recruiting pool to test the MVP.
Asking participants if they’d like to provide feedback does not necessarily initiate the need for the Paperwork Reduction Act (PRA). If the call for feedback is open-ended and asks for no information to schedule a session other than a name or email address, it falls under the Social Media Guidance memo from 2010.
From the memo Social Media Guidance, dated 4/7/2010:
Feedback requests.
Under existing OMB policy, agency uses of general or undifferentiated “suggestion boxes” are not covered by the PRA. Similarly, an agency does not trigger the PRA’s requirements when it posts its email address or uses an application for brainstorming or idea generating on its website to enable the public to submit feedback. However, if an agency requests information from respondents beyond name and email or mailing address (e.g., age, sex, race/ethnicity, employment, or citizenship status), this request is covered by the PRA because it seeks information beyond what is “necessary” for self-identification of the respondent.
We conducted two rounds of tests on our MVP of get.gov and the new application process. Participants recruited through the current site were especially crucial in giving feedback to the team, helping us to measure value added against the current site.
Thanks to the panel, we were able to:
Getting feedback from real users is critical to building the right thing. By creating a customer panel, we’ve been able to hear from users shortly after they complete their first use of our product, and that’s produced some really useful insights as we build new features. –Cameron Dixon, CISA
If you are considering building a customer panel, here are some tips:
Lalitha is a product manager at 18F. In her tenure at TTS, she has had the opportunity to collaborate with amazing federal teams through visioning, strategizing, coaching, delivering and launching digital products, most notably the Department of Justice’s civil rights portal. At 18F, Lalitha collaborated with and led teams in developing and coaching product management at FEMA, EPA, DOE, HHS’ Office of Head Start and DOJ’s OIP (for foia.gov).
From her nomination:
“Lalitha led the charge for the in-person proofing product offering on Login.gov from the start. She was staffed from 18F to support Login.gov and was immediately tasked with building out, testing, and implementing an entirely new wing of Login.gov’s product. She did this while starting with a brand new team, working remotely, balancing stakeholders both intra- and inter- agency, and all the while maintaining an exemplary work-life balance.
In-person proofing is a critical element of Login.gov’s accessibility work that strives to ensure that everyone is able to verify their identity and access government services. Lalitha championed the ideas that make government services more accessible by continually centering the needs of the users through the development and rollout of the in-person identity proofing pilot. In her leadership of the in-person identity proofing effort Lalitha drove collaboration not only across TTS (between 18F and Login.gov, TTS Operations, and TTS Agreements) but also across agencies, as the US Postal Service was a critical partner in piloting this new offering.”
Lalitha lives in Virginia with her husband and two boys. She is motivated to solve problems for the general public by delivering equitable products and services and ease their interactions with the government. When in doubt, she researches and empathizes with individuals that struggle to use government services to guide her in improving outcomes through her products.
This award commemorates the life and work of Andrew Hyder, a consulting software engineer at 18F who passed away in 2021. Andrew was a community organizer who brought together activists, technologists, community members, and others to improve the way that governments delivered services to those in need. Examples of his contributions can be found in these blog posts: A dashboard for privacy offices and Forms Resource for Federalist Users.
“Feed the people” was Andrew’s well-known refrain, though it went beyond just nutritional benefits and programs like GetCalFresh. He challenged colleagues and partners to think about the true benefits and costs of our work, always seeing the connections from our keyboards to the lived experiences of people across the country.
]]>We suggest using the following table when determining target audiences for each research artifact:
Team | Agency | Partners | Public | Vendors | |
---|---|---|---|---|---|
Interview notes with names | Yes | No | No | No | No |
Interview notes without names | Yes | Yes | Yes | No | Yes |
Maps, diagrams, prototypes | Yes | Yes | Yes | Yes | Yes |
After interviewing several participants, your team has valuable insights. Before sharing, ensure all personal information is removed. These edited notes can provide helpful, anonymous insights for internal and partner agency discussions.
Your project’s running notes contain detailed observations. Before sharing, review and edit out any sensitive information. These revised notes can then be a useful resource for the internal team, offering insights into the project’s development.
The customer journey map your team created shows the user experience from beginning to end. Make sure to remove or anonymize any personal anecdotes or user data. This map can then be shared broadly, offering insights into customer interactions.
Use case scenarios developed by your team help understand potential user interactions. As these scenarios are generally hypothetical and don’t contain personal information, they can be shared with a wider audience to illustrate your service design process.
Your project’s screening materials detail the selection criteria for research participants. While they don’t contain personal information, they do show your target demographic. These can be shared with internal teams and partner agencies to aid in their understanding of your research approach.
Your research plan outlines your methodology and goals. Free of sensitive data, this document can serve as a guide for other teams and agencies, helping them adopt similar research approaches and ensuring methodological consistency.
Your team should still use discretion when sharing synthesized interview notes, running notes documents, or affinity maps, ensuring ultimate discretion on the removal of PII or other sensitive information. Additionally, you’ll want to ensure that your research complies with the Paperwork Reduction Act. Speaking with colleagues in other agencies or cross-agency working groups to discuss these tactics might also be helpful.
We recognize these rules won’t apply to every situation, as some agencies have very strict guidelines for what’s shareable, and for good reason. Sharing isn’t only about transparency; it’s meant to help our colleagues understand the work behind the outcomes. Outcomes are only as good as the methods used to compose them, so there’s a lot of value in sharing your work early and often when it makes sense to do so.
Happy researching!
]]>The passage of time on its own isn’t a good reason to do a redesign. Changes in user or organizational needs should drive that choice. In our case, we realized the site no longer reflected our goals. Additionally, some of our designers had windows of time to work on parts of the site between client projects.
We also realized that we could use a small redesign to jumpstart an ongoing process of refinement, which we could pursue without disrupting other priority work.
Our wish list of improvements spanned from ambitious to modest. We set aside those that would need a lot of research and discussion to settle on a solution. (For instance, we’d like to move the site to a new static site generator in the interest of sustainability. We decided it was out of scope for this refresh as that would entail more labor for set-up and content migration.)
We selected issues that were ready to move forward right away and that could be completed quickly or at a steady clip.
We figured out a process for coordinating a “tag team” of staff to organize operational work into small pieces, which then completed tasks in pockets of time between projects.
Two supervisors lead this work. They manage a backlog of issues in GitHub, collected from various sources. They also have standing meetings with leadership stakeholders.
Like all of our work at 18F, tasks are managed through agile methods. Daily syncs and blocks of time for coworking ensure everyone knows who’s working on what and can get help as needed. Biweekly planning meetings aligned priority issues to available skills. Biweekly retrospective meetings surface and remediate issues within work processes quickly. These processes make onboarding and offboarding staff routine and effective. (It also allows us to work on a range of priority work concurrently.)
At the top of our wish list was to enable users to quickly find what they’re looking for. We also wanted them to easily understand our services and resources.
We started by digging into our existing trove of research. We knew from years of web analytics data what content our users search for the most and spend the most time on.
Interviews with our leadership team also clarified current organizational priorities and goals.
As one would expect with a site “refresh,” we kept the amount of design to a minimum.
A couple of content designers reviewed the site’s information architecture and content. Informed by the 18F Content Guide, their recommendations led to clearer labels, more scannable copy, and a more consistent voice and tone across the site.
A product designer used the new copy to draft new page layouts, including a new blog post template, based on the U.S. Web Design System.
Thanks to that standing meeting with leadership, the new designs received quick attention and signoff. After a little refinement by a UX designer, they were handed off to a UX engineer to build.
Yes—a UX engineer. One thing that enabled us to refresh the site rapidly is that we intentionally hired several designers who can also code. Industry best practices are moving in this direction and we’ve also seen the benefit of having designers who can flex their skills as UX engineers. This gives us more agility to match people to projects based on appropriate skills and to ship projects quickly.
We run the site on a simple but nimble tech stack so that it can be maintained without highly specialized engineering knowledge. It uses standard web languages (HTML, CSS, and Javascript), an open-source static site generator, and cloud.gov Pages.
Since one of our goals was to continue to make the site easy to maintain and update, we took the time to carefully review the existing code to sort out what could be removed or streamlined.
Because the previous site also used the U.S. Web Design System (USWDS), translating the new designs into code required revising rather than writing new code. We used this site refresh as an opportunity to migrate to USWDS 3.0, to make use of its new modular approach.
That’s how we launched a new 18f.gsa.gov in the course of several weeks. It wasn’t a simple process, but it was a steady one thanks to clear goals, disciplined decisions, and good coordination.
Next, we’ll plan and conduct user testing to assess how well the refreshed site serves our users’ needs and our goals. We’ll also continue to iterate based on FY24 goals and priorities. Whatever issues are identified will be addressed by available staff as opportunity allows. Based on what we’ve learned during this site refresh, future work sprints on the 18F website should be easier to coordinate and execute.
Websites aren’t meant to stand the test of time. They are a flexible medium that should serve their users’ needs and organizational goals. While that can seem like a monumental amount of work, identifying smaller tasks can help you publish and update your site at intervals you can measure in weeks or months rather than years.
With special thanks to the people who made the refresh possible:
Ron Bronson, Anita Cheng, Mel Choyce, Amanda Costello, Jennifer Damis, Jeff Durland, Austin Hernandez, Igor Korenfeld, and Michelle Rago
18F and the Administration for Children & Families’ Office of Family Assistance partnered on building a new data portal for TANF to replace one over 20 years old. This new portal would upgrade the data reporting experience, improve data quality, inform better policy and programs, and ultimately help the low-income families that receive TANF. We last blogged about this work in 2020.
We caught up with Office of Family Assistance leaders Lauren Frohlich (product owner), and Alex Pennington (technical lead) to see how their agency is continuing with the work.
Lauren Frohlich: A lot has happened. I think we were just getting our Authority to Operate (ATO) right as 18F was rolling off — so, we’ve had our ATO for two years now. We are in production and bringing in users; over 85% of our users have created accounts in the system, and we’re getting great feedback. We’re finally into the exciting parts of development with our vendor, and I think we see the end in sight for our old system.
Alex Pennington: The system is in use; that’s huge! Not only do we have the system up, but OFA is operating and maintaining the system, and regularly pushing new updates to the code.
Designing the contract and the system the way we did — for OFA to have control and input and be so involved in the development — I think it facilitates the ability to be responsive. It’s just 180 degrees from our past experience. It’s so refreshing. –Lauren Frohlich, Product Owner for the TANF Data Portal
Alex Pennington: The biggest thing is that our TANF partners immediately know that their data has been submitted. There is no question of, “do you have our data?” They can see it. And not only are they seeing those notifications in-app, but they’re getting email notifications from us saying, “Hey, we have your data.” They can also see the history of all of their data submissions. Our engagement has really improved because the new system has enabled us to communicate more fluidly with our partners, and I’m so excited about that.
Lauren Frohlich: For our Tribal TANF program, that’s the biggest change. It went from them sending email to a black box resource mailbox, never really getting feedback unless something was wrong, and then it was months and months later until partners heard from us. Already in the new system, there’s that immediate confirmation that we got it, and being able to see the history. And, then there’s the promise of what’s next: to see the parsing and data validation errors in the app; it helps build trust with our users.
Alex Pennington: It’s definitely the parsing. The new app currently stores the data files, but it also will need to parse and extract data from the files. We’re coming to terms with the fact that it’s not just the system that’s old and broken. It’s also how we organize our data that’s also old and broken. And our developers are seeing that. It’s making the parsing and validation process pretty complicated, understandably so.
Lauren Frohlich: Another thing is we’ve been onboarding more and more users. Naturally, the most excited, eager ones come on first. And now, we’re getting to more reluctant users who were happy with how things had been working. So that’s been a challenge.
Lauren Frohlich: We’ve been laser-focused on what we’ve been calling parity, which is the set of minimum features needed to be able to decommission the old system and switch people over to the new one. After we get to that point, we will have to think a little bit more about future trade-offs and priorities.
Alex Pennington: I would agree, and just to add onto that: Sometimes there are bugs, right? We prioritize fixing them if it prevents users from doing the minimum of what they need to do, submitting data. If there’s a problem, like maybe the files are too large or something, and we catch that, then that’s a hotfix. But other things, we put off until we’re beyond parity.
Lauren Frohlich: Yeah, there are some milestones we can definitely put on there.
Lauren Frohlich: Getting to ATO, that was like a 7 out of 10. And, not to be too negative but there were definitely some low points. It started to turn up again after the integration challenges. Some high points were getting focused on feature parity with the old system and launching production.
Alex Pennington: I rated v2.0 with real users off the charts because it was a great day! There were 10 users; 5 of them were states and 5 of them were tribes.
Lauren Frohlich: We’re now doing onboarding in full swing. I feel like we’re at a pretty steady pace. It’s leveling out a bit.
Lauren Frohlich: To select what state and tribe you are from, we have one combo-box. When users started using it, some tribes assumed that they had to select the state where their tribe is located. It wasn’t intuitive, a lot of forms don’t do it that way. It’s in our backlog to split it up so that you first select: “state, tribe, or territory.”
Lauren Frohlich: I’ll say I’m most proud of Alex, just watching her master and navigate everything to find bugs and improve processes. I think of how far we’ve come as an office, in terms of our autonomy and control of our system. She is an empowered tech lead, and together with Thomas, our other system admin, they know the new system so well and it completely changes our ability to serve our TANF partners.
Alex Pennington: Thank you! I’m just thrilled that we can actually be responsive now to our partners. It used to be: “Oh, just wait a couple of days. Wait a week. We’ll get back to you.” And now we can say: “Hey, start using it today.” It’s been such a pain point, not just for them but for our team that works with the data every day. That changes the nature of the conversation, which is what OFA has been trying to do around our data — getting closer to the point where we can actually have conversations about, “what is this telling us about the families being served?” and not just about, “do you have your data?” I love that!
Lauren Frohlich: Designing the contract and the system the way we did — for OFA to have control and input and be so involved in the development — I think it facilitates the ability to be responsive. It’s just 180 degrees from our past experience. It’s so refreshing.
Shout-out and kudos to the many, many team members at Administration for Children and Families, 18F, and industry partners who’ve supported this project and brought the TANF Data Portal to where it is today! ❤️
Interested in how 18F can help your agency with legacy tech transformation, user research, and acquisition? We’d love to hear from you at inquiries18F@gsa.gov
]]>Digital accessibility is about creating products, services, environments, and content that anyone can use and understand regardless of device or ability. Accessible design and development practices can help us build inclusive, barrier-free experiences. However, we can inadvertently lose sight of the people we serve if we don’t question our assumptions or continuously work to better understand our audience.
There are many ways we can accidentally cause harm in attempting to provide support. We are humans, after all, working to humanize a digital space. Avoid these mistakes and oversights when thinking about the accessible user experience.
When accessibility is implemented as a formality or symbolic gesture, it fails to properly address barriers and lacks meaningful impact. Tokenism prevents us from understanding the lived experiences of people with disabilities.
Digital experiences that aren’t informed by real users can ignore the people they serve. If people with disabilities are not included in the project, the end result may not accurately address the real challenges faced by users.
Learn more about GSA’s inclusion activities.
Digital accessibility sometimes focuses on specific disabilities, neglecting the broad spectrum of disabilities and experiences. Too narrow of a focus can exclude people, blocking access and leading to further marginalization.
Learn more about diversity of abilities and barriers.
Leaving accessibility until the end of the project can degrade the overall user experience and compromise inclusivity. When accessibility isn’t considered throughout the process, the focus can shift to compliance and away from people.
Learn more about integrating accessibility into project plans.
Accessibility still requires more awareness. If we are not properly trained, we can harm the communities we serve. Incorrect implementation of accessibility principles and practices can make the user experience worse, even with the best intentions.
See how various roles can have an affect on the accessibility of a project.
When we rely on empathy alone, we overlook the lived experiences of people with disabilities in favor of our own perspectives and perceptions. If we don’t engage with our users early and often, we will have a hard time aligning with their real needs.
Empathy: its nature and limitations.
These oversights are common, but preventable. Being aware can help you avoid causing unintentional harm when trying to be inclusive and accessible.
If you’re interested in learning more about accessibility in your digital space please reach out to Inquiries18F@gsa.gov.
]]>This workshop may be a rare opportunity for participants to meet and talk to others. They’ll want to chat about their world with others who understand the problems and nuances of their work. Build in time and space for participants to speak about their work tools, blockers, challenges, etc. It’s also a golden opportunity for project teams to listen in on those conversations that can be insightful to us in moving the work forward and deepening our understanding of the problem space.
Hold a space (and a time) for revisiting for thoughts, questions or concerns coming up throughout the workshop that may be best incorporated in a future meeting. This can be done using a posterboard in person or a virtual whiteboard if the workshop is being facilitated online. Having a parking lot allows participants to surface things that may be better suited for a longer discussion later on during the workshop or during a future session.
If an unexpected action item arises based on chatter among participants or is stationed in the parking lot be sure to include it along with the other action items. Who should handle it when? Is it feasible now? Even if it isn’t, address rather than ignore.
Value the unplanned conversation as you would a planned activity in the case that it’s contributing to our knowledge about the topic. Time the participants spend chatting amongst themselves about the problem is not wasted time. Allowing participants to freely use the space to discuss whatever is at the top of their mind in relation to the project. By listening closely and taking notes, the team will learn more about the problem space, top of mind priorities, major blockers, and other tidbits that might surface in a casual conversation with another SME (Subject Matter Expert). Take notes of what you’re hearing!
Schedule the activities that require the entire group to participate toward the beginning of the workshop. Schedule activities that are easily completed asynchronously toward the end of the workshop. This will allow you some flexibility in accommodating unplanned but fruitful topics of discussion while having participants complete solo activities asynchronously or in a future session.
Ensure you schedule any follow up sessions or establish that you’ll reach out to do so in the case that you do not finish the entire workshop. If the unfinished activity can be completed asynchronously, now would be a great time to remind participants to finish the activity on their own and provide a deadline.
Meet with your team after the workshop to debrief and talk about any insights that surfaced and how they might inform the direction of your work. Bring the notes you took as you listened to the SMEs speak amongst themselves, your action items and the parking lot. Discuss how you’ll incorporate any relevant findings.
Using these 7 tips will help you incorporate unplanned but important topics of discussion while maintaining a structured and organized workshop. Acknowledging thoughts and ideas from participants but using your own discretion in regards to how and when to dive deeper into those conversations keeps the participants feeling heard. It gives you as the facilitator the ability to maintain the structural/organizational integrity of the workshop.
]]>Project management Building a healthy 18F engagement |
|
Product delivery Building a user-centered product |
|
Current work | Near-term work |
Post-18F sustainability Building a partner environment for delivery |
|
Short term capacity building | Post-18F sustainability and capacity building |
Learn from the work |
Throughout the engagement, we want to make sure that we are aligning stakeholders, monitoring our budget, and providing the appropriate resources to a project. This can mean introducing new agreements, adjusting staff, or revisiting the project scope or deliverables as the project progresses. We make sure we have the appropriate paperwork and support to kick off the project.
We aim to have a productive working relationship within the 18F team and with the partner. In the kickoff phase of our work, we align with the partner on the scope from the initial agreements phase. Then, in our discovery phase, we align with our partner on the first slice of product development work and capacity building, and determine if that is within 18F’s capabilities. As we roll off an engagement, we ensure the partner is not reliant on 18F tools, and resources are transferred to the partner.
The ultimate goal of our product delivery work is to introduce a new or modernized digital product that will reduce administrative burden for the public. We use human-centered design to validate the mission and problem or identify a need, and lean methodology to prioritize a first slice of work. We conduct end-user research, stakeholder research, and technical discovery to see what might be the highest value and most feasible place to start.
We then mitigate both project and product risks by starting to build out initial feature sets of working software: either as throw-away prototypes or as slimmed down versions of the future production product. We test those assumptions through usability testing and iteration of the product. We work with our partners to define a product roadmap from the learning of our initial iterations. We also determine whether our initial prototypes will meet the long-term needs or technical constraints of our partner and either scrap them for a pre-production software or mature the codebase from a prototype into pre-production. We also use our initial product development to chart a course for security authorizations.
We then work to mature the product for launch by developing the minimum set of features that will provide the most value to our users at launch, undergoing security testing, and establishing product metrics, and system operations like release management. We launch the product and continue to deliver the product in production. Our partners face certain challenges, and there are times when an industry partner may make more sense to conduct the product delivery, development, and design.
We want to build products that our partners can successfully manage in production after our 18F engagements conclude. We often think about coaching and what the agency’s product management capabilities are in our work from the beginning. In our discovery work, this means identifying a critical first slice of capacity building which is often around introducing a government program manager to digital product ownership and agile methodologies. As we conduct our initial product development, we establish a baseline of the skills and resources needed for the partner to sustain their work.
For some projects we support our partners in launch since there are a lot of security, compliance, and user support activities required for a launch in government, and our experience helps us mitigate those risks. We also support our partners to learn how to deliver continuously in production. Before we conclude our partnerships, we work to ensure that our partners are capable of managing digital products in production without our staff, and transition tooling to the partner.
In our work, we also want to facilitate curiosity within 18F and in the broader civic tech community. We work in the open so others can use our code and resources, such as documentation on our architectural choices and user research summaries. We update our resources and templates throughout projects so that we can deliver better and faster as we build from our experience. We share our work within 18F via presentations and project reflections so that we can all benefit from an individual’s project experience. We also think about what lessons might help other digital service teams and agencies and publish guides and posts on this blog to facilitate broader adoption of modern digital services.
]]>This award commemorates the life and work of Andrew Hyder, a consulting software engineer at 18F who tragically passed away in 2021. Andrew was a community organizer who brought together activists, technologists, community members, and others to improve the way that governments delivered services to those in need. Examples of his contributions can be found in these blog posts: A dashboard for privacy offices and Forms Resource for Federalist Users.
“Feed the people” was Andrew’s well-known refrain, though it went beyond just nutritional benefits and programs like GetCalFresh. He challenged colleagues and partners to think about the true benefits and costs of our work, always seeing the connections from our keyboards to the lived experiences of people across the country.
It’s easy when you’re working at a high level to forget to pause, adjust, and take in the impacts of our work on everyday people. Andrew always encouraged us to do this, at all phases of work, gently calling us back to earth when we’d gotten stuck in the clouds. His presence is both deeply missed, and daily cherished.
As we open the 2023 award nomination period to those in TTS internally, we’d like to recognize the work of 2022 honorees Jessica Dussault (18F) and Will Cahoe (10x).
Jess is fun-loving, sincere, hard-working, and dedicated, and she brings enthusiasm and energy to everything that she works on. In her time as a consulting software engineer at 18F, Jess has demonstrated a dedication and enthusiasm to improving government public service through her efforts on projects and contributions to TTS culture.
She worked on improving how the public learns about government services through the 10x Public Service Catalog project. She collaborated on a more secure, agile, and human-centered website for the Office of Head Start’s Early Childhood Learning & Knowledge Center. Her work improved the existing architecture, and she helped to introduce new software development and hiring practices to the Office of Head Start.
Jess shares new approaches to improving government service through her writings on 18F’s blog, the TTS Engineering Newsletter, every day in Slack, and in the numerous meetings, team meetings, and coffees that she partakes in.
In all of Will’s work, he embodies the enthusiasm, warmth, and dedication that so many of us remember as hallmarks of Andrew’s work in TTS. Will began his federal career in the Peace Corps, and joined TTS soon after. From his first day at GSA, he has infused TTS with humor, kindness, appreciation and celebration of differences, and an immovable dedication to public service. Will’s creativity and ingenuity surface in everything he does – from problem solving to public speaking. Nothing Will does is dull, and the federal government is a better place because of his inventiveness.
Will is the product manager of 10x.gsa.gov, and in this capacity he oversaw the launch of an entirely rebranded and restructured website. Will provided the vision and direction to create a site that both met user needs and reflected the uniqueness of 10x’s approach in the federal space. He crafted all communications, so each project description conveyed both project-specific work and bigger-picture program learnings.
]]>