-
Notifications
You must be signed in to change notification settings - Fork 306
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge branch 'main' into snyk-fix-4d01306e6aca5a2791e2be5edbbe2b84
- Loading branch information
Showing
11 changed files
with
519 additions
and
38 deletions.
There are no files selected for viewing
34 changes: 34 additions & 0 deletions
34
...ng-public-participation-and-community-engagement-with-the-federal-government.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,34 @@ | ||
--- | ||
# Originally published at the following URL | ||
source_url: https://www.performance.gov/blog/2024-public-participation-federal-government | ||
source: performancegov | ||
date: 2024-10-29 00:00:00 -0500 | ||
title: "Broadening Public Participation and Community Engagement With the Federal Government" | ||
deck: "Government works best when it incorporates transparent engagement and | ||
feedback from the public. The White House Office of Management and Budget | ||
(OMB) is enhancing public participation in federal decision-making through | ||
draft guidance and a proposed toolkit. These resources aim to standardize best | ||
practices, improve accessibility, and ensure underserved communities have | ||
meaningful opportunities to contribute. By prioritizing transparency and | ||
collaboration, OMB seeks to create politics that reflect the voices and needs | ||
of the public." | ||
summary: "Government works best when it incorporates transparent engagement and | ||
feedback from the public. The White House Office of Management and Budget | ||
(OMB) is enhancing public participation in federal decision-making through | ||
draft guidance and a proposed toolkit. These resources aim to standardize best | ||
practices, improve accessibility, and ensure underserved communities have | ||
meaningful opportunities to contribute. By prioritizing transparency and | ||
collaboration, OMB seeks to create politics that reflect the voices and needs | ||
of the public." | ||
# See all topics at https://digital.gov/topics | ||
topics: | ||
- best-practices | ||
- accessibility | ||
- communication | ||
- digital-service-delivery | ||
slug: broadening-public-participation-and-community-engagement-with-the-federal-government | ||
# Controls how this page appears across the site | ||
# 0 -- hidden | ||
# 1 -- visible | ||
weight: 1 | ||
--- |
32 changes: 32 additions & 0 deletions
32
...ent/news/2024/11/2024-11-26-ensuring-effective-and-timely-usability-research.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,32 @@ | ||
--- | ||
# Originally published at the following URL | ||
source_url: https://www.whitehouse.gov/omb/briefing-room/2024/11/21/ensuring-effective-and-timely-usability-research/ | ||
source: whitehouse | ||
date: 2024-11-21 00:00:00 -0500 | ||
title: "Ensuring Effective and Timely Usability Research" | ||
deck: "Usability reflects how easily a user can accomplish their goals while | ||
using a product or service. The Office of Information and Regulatory Affairs | ||
(OIRA) has issued new guidance to streamline usability testing for federal | ||
forms, websites, and services, helping agencies conduct usability tests in a | ||
more quick and efficient manner that is consistent with the Paperwork | ||
Reduction Act (PRA). By enabling faster, more effective testing, OIRA aims to | ||
enhance public interactions with the government and ensure equitable access to | ||
federal resources." | ||
summary: "Usability reflects how easily a user can accomplish their goals while | ||
using a product or service. The Office of Information and Regulatory Affairs | ||
(OIRA) has issued new guidance to streamline usability testing for federal | ||
forms, websites, and services, helping agencies conduct usability tests in a | ||
more quick and efficient manner that is consistent with the Paperwork | ||
Reduction Act (PRA). By enabling faster, more effective testing, OIRA aims to | ||
enhance public interactions with the government and ensure equitable access to | ||
federal resources." | ||
# See all topics at https://digital.gov/topics | ||
topics: | ||
- accessibility | ||
- communication | ||
slug: ensuring-effective-and-timely-usability-research | ||
# Controls how this page appears across the site | ||
# 0 -- hidden | ||
# 1 -- visible | ||
weight: 1 | ||
--- |
108 changes: 108 additions & 0 deletions
108
content/news/2024/11/2024-11-26-navigating-digital-acquisitions.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,108 @@ | ||
--- | ||
date: 2024-11-26 00:00:00 -0500 | ||
title: "Navigating digital acquisitions" | ||
deck: "How to adopt an agile approach for modernizing websites" | ||
summary: "Learn the best practices for agile acquisitions—from building and buying solutions, to overcoming common roadblocks." | ||
|
||
# See all authors at https://digital.gov/authors | ||
authors: | ||
- frances-carden | ||
- ashley-owens | ||
|
||
# See all topics at https://digital.gov/topics | ||
topics: | ||
- application-programming-interface | ||
- acquisition | ||
- digital-service-delivery | ||
- best-practices | ||
- content-strategy | ||
- usability | ||
|
||
slug: navigating-digital-acquisitions | ||
|
||
primary_image: agile-project-development-flashvector-istock-getty-images-2149784445-2160477593 | ||
|
||
# Controls how this page appears across the site | ||
# 0 -- hidden | ||
# 1 -- visible | ||
weight: 1 | ||
|
||
--- | ||
|
||
Many of us have heard the term “agile acquisition,” but what does it look like in practice, and why is it better for digital modernizations? | ||
|
||
Agile [acquisitions](https://digital.gov/topics/acquisition/) are structured to reduce risks while ensuring that each solution meets a user’s complex needs throughout the web modernization process. Contracts often focus on the technical system behind the website. You may see these types of contracts involved in website modernization approaches. Typically, they begin by gathering requirements. However, if we are to change the user experience we must begin the process another way. During this phase, figuring out the problem you are trying to solve and the product (website) vision followed by user research is key — you want to ensure the assumed audience and problem is correct. User research is especially important for web modernization projects because websites are a primary way that the public interacts with the federal government. | ||
|
||
## Build versus buy | ||
|
||
Once you’ve completed user research, you face two potential avenues for procurement. You can decide either to build or buy something. The user research can help de-risk this decision. By surveying the market against user needs and pain points, you can better decide if there are existing solutions that either solve most of the user needs or if you will need to custom-build to satisfy the user needs. | ||
|
||
### Building in digital modernizations | ||
|
||
If you decide to custom create your modern website, there are a few actions you can take to ensure success. First, structure your work statement for agile collaboration by using a statement of objectives. A statement of objectives states the overall performance goals of a project and is often used in solicitations to give vendors flexibility to propose creative approaches. This is sometimes confused with a statement of work, which outlines the details of a project, including tasks, timelines, deliverables, and success criteria. A statement of work is best suited if you have decided to purchase an existing solution (such as commercial off-the-shelf, low-code, or no-code platforms). When considering a third option of a “blend” of customization and integration of existing solutions then a Performance Work Statement is often best suited. | ||
|
||
{{< ring title="Definitions">}} | ||
A statement of work (SOW) is the portion of a contract that establishes and defines all non-specification requirements for a contractor's efforts either directly or with the use of specific cited documents. | ||
|
||
A performance work statement (PWS) is a statement of work for performance-based acquisitions that describes the required results in clear, specific and objective terms with measurable outcomes. | ||
|
||
A statement of objectives (SOO) is a government-prepared document incorporated into the solicitation that states the overall performance objectives. It is used in solicitations when the government intends to provide the maximum flexibility to each offeror to propose an innovative approach. That portion of a contract that establishes a broad description of the government’s required performance objectives. | ||
|
||
[Explore more definitions on the “ACQuipedia” by the Defense Acquisition University](https://www.dau.edu/acquipedia) | ||
{{< /ring >}} | ||
|
||
Consider using a [time and materials](https://guides.18f.gov/derisking-government-tech/buying-development-services/#time-and-materials-type-contract) contract type for custom development, which gives the government flexibility to control the amount of work via user stories provided through an empowered product owner. The government product owner controls the user story backlog (a prioritized list of work to be done), which constrains the cost but allows the government to easily pivot when a new user need arises. On the other hand, consider using a firm-fixed contract type for existing solutions, and a hybrid for a blend. | ||
|
||
Next, ask potential vendors to showcase similar work they’ve done in the past by requesting access to code repositories that your team could analyze. You will want some experts on your team (like a software engineer or developer)— or at least informed decision makers who are able to read code repositories — to perform this code review and validate whether the code and repositories demonstrate best practices. For existing solutions, consider requesting sandbox access to have a handful of users perform usability testing for major tasks/functionality to evaluate whether potential solutions are viable and meet your needs. | ||
|
||
After awarding the contract, these teammates will judge work quality based on a [Quality Assurance Surveillance Plan](https://guides.18f.gov/derisking-government-tech/buying-development-services/#quality-indicators-defined-in-a-quality-assurance-surveillance-plan), including accessibility requirements. They’ll also track the vendor’s progress on the build of your website through [fundamental agile activities and meetings](https://guides.18f.gov/agile/agile-fundamentals/) like backlog refinement and sprint planning. While these surveillance plans are best suited for custom development, there are elements you can use for your existing solution, including accessibility, usability testing, and user research. | ||
|
||
### Buying in digital modernizations | ||
|
||
As stated, there may already be a product on the market that could meet your team’s needs. | ||
|
||
In that case, you might opt for the second procurement option: buy something. This usually means buying [commercial off-the-shelf](https://18f.gsa.gov/2019/03/26/when-to-use-COTS/) products. When you buy a product off the shelf, it’s important to understand the difference between configuration and modification: | ||
|
||
* **Configuration** involves using a solution’s built-in settings and tools to change its features. | ||
* **Modification** (sometimes called customization), involves actually changing the solution’s core code to change its features. This is more complex and typically requires specialized development skills. | ||
|
||
While you’ll configure anything you buy to your agency’s requirements, avoid going into a purchase with plans to make dramatic modifications. Buying off the shelf and modifying requires a lot of time and money. Plus, customization of existing solutions can cause further vendor lock-in. This is why it is important to ensure the solution meets user needs before purchasing it. | ||
|
||
The process for selecting products you may want to buy begins with defining your problem, product vision, and conducting user research to understand the needs and pain points the product is intended to solve for. When buying a solution, use the research to conduct market research differently by using: | ||
|
||
* A [statement of work (PDF, 130 KB, 21 pages)](https://www.gsa.gov/system/files/SOW_Application.Services.and.Component.Framework.pdf) as your work statement | ||
* Usability testing and scorecards (such as the [Accessibility Conformance Report and Voluntary Product Accessibility Template](https://www.section508.gov/sell/how-to-create-acr-with-vpat/)) to gauge how well a product meets your needs for function and accessibility | ||
|
||
Instead of receiving demos to evaluate a product’s applicability to your need, performing [usability testing](https://digital.gov/event/2018/06/14/usability-testing-with-steve-krug/) with real users can offer insight into whether a potential solution meets your needs. Ask potential users to perform their regular work with the tool to determine in a hands-on way whether it operates and meets their daily needs well. Finally, [firm-fixed-price](https://www.acquisition.gov/far/subpart-16.2) contracts are typically used when purchasing commercial products with detailed and definite specifications and quantities. These types of contracts provide maximum incentive for the contractor to control costs. | ||
|
||
When buying commercial off-the-shelf products, consider the Federal Risk and Authorization Management Program, commonly known as [FedRAMP](https://www.fedramp.gov/). This program was created to provide standardized security processes and requirements allowing agencies to rapidly adopt cloud service offerings. Many commercial products are not compliant with federal security requirements. | ||
|
||
Browse the [FedRAMP Marketplace](https://marketplace.fedramp.gov/products) to find authorized services. Also, consider whether this requirement will decrease competition as advised in the [FedRAMP frequently asked questions](https://www.fedramp.gov/faqs/). | ||
|
||
Budget is a common challenge to agile acquisitions. If you have a smaller budget, a minimum viable product (MVP) is a good place to start and build agency buy-in. This is useful whether you decide to buy or build. | ||
|
||
{{< box >}}**What is a minimum viable product?** | ||
|
||
A minimum viable product, or MVP, is a product with enough features to attract early-adopter customers and validate a product idea early in the product development lifecycle. | ||
{{< /box >}} | ||
|
||
To develop an MVP, conduct an assessment of key technical requirements and user needs, including the price and budgetary constraints. This assessment will help stakeholders focus on the requirements they truly must have in a solution. Use these requirements to develop an MVP. As your agency’s leadership sees the visual representation of the product and reviews the honest and accurate calculations, you might receive additional funds. Throughout this process, it is important not to be overly optimistic, to overpromise, or to pack your [sprints](https://guides.18f.gov/agile/agile-fundamentals/) with more work than can be done. | ||
|
||
## What can I do next? | ||
|
||
Regardless of your decision to build or buy, factor long-term maintenance into your budgets and plans. Develop an understanding of what it will take to maintain your solution over time and plan your budget accordingly. Think about sustaining your solutions throughout its entire life cycle. Also, consider the amount of scalability you will require in the long-term. | ||
|
||
For more information on how to jump start your approach, check out the [18F De-risking Guide](https://guides.18f.gov/derisking-government-tech/). | ||
|
||
You can also join a [Digital.gov community of practice](https://digital.gov/communities/) to connect with fellow web and digital practitioners in government who are working to create better online experiences for the public. | ||
|
||
{{< note >}}This blog post was inspired by the fourth session of the [Spring 2024 Digital.gov Community Summit: Delivering a digital-first public experience](https://digital.gov/event/2024/03/13/spring-2024-community-summit/), which focused on navigating digital acquisitions using an agile approach. These topics included acquiring a website, how to conduct market research on possible solutions, and planning processes, hiring strategies, how to leverage contractors, as well as pricing and budgeting. | ||
|
||
**This session’s panelists included**: | ||
|
||
* Session moderator, **Ashley Owens** – Senior digital acquisition strategist, General Services Administration (GSA) | ||
* **Justen Proctor** – Senior contracting officer, GSA | ||
* **Andrew Nielsen** – Director of Government-wide IT Accessibility Program, GSA | ||
* **Laura Larimore** – Senior digital strategist, Department of State (DOS) | ||
* **Anthony Burley** – Senior project manager, Court Services and Offender Supervision Agency (CSOSA) | ||
{{< /note >}} |
33 changes: 33 additions & 0 deletions
33
...w-we-used-design-studios-and-user-testing-to-develop-a-user-centered-dataset.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,33 @@ | ||
--- | ||
# Originally published at the following URL | ||
source_url: https://blog-nrrd.doi.gov/Publishing-Federal-Sales-Data/ | ||
source: doi-revenuedata | ||
date: 2024-11-19 00:00:00 -0500 | ||
title: "Publishing federal sales data: how we used design studios and user testing | ||
to develop a user-centered dataset" | ||
deck: "The Open Data, Design, and Development team at the Office of Natural | ||
Resource and Revenue (ONRR) successfully added federal sales data to the | ||
Natural Resources Revenue Data (NRRD) platform using design studios and user | ||
testing to create a user-centered dataset. By involving subject matter experts | ||
and refining prototypes through feedback, the team delivered the project ahead | ||
of schedule while meeting user needs. Future plans included additional | ||
usability testing and expanding stakeholder engagement." | ||
summary: "The Open Data, Design, and Development team at the Office of Natural | ||
Resource and Revenue (ONRR) successfully added federal sales data to the | ||
Natural Resources Revenue Data (NRRD) platform using design studios and user | ||
testing to create a user-centered dataset. By involving subject matter experts | ||
and refining prototypes through feedback, the team delivered the project ahead | ||
of schedule while meeting user needs. Future plans included additional | ||
usability testing and expanding stakeholder engagement." | ||
# See all topics at https://digital.gov/topics | ||
topics: | ||
- accessibility | ||
- human-centered-design | ||
- content-strategy | ||
- data-visualization | ||
slug: publishing-federal-sales-data-how-we-used-design-studios-and-user-testing-to-develop-a-user-centered-dataset | ||
# Controls how this page appears across the site | ||
# 0 -- hidden | ||
# 1 -- visible | ||
weight: 1 | ||
--- |
33 changes: 33 additions & 0 deletions
33
...nt/news/2024/11/2024-11-26-three-ways-to-write-fearless-spreadsheet-formulas.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,33 @@ | ||
--- | ||
# Originally published at the following URL | ||
source_url: https://18f.gsa.gov/2024/11/05/three-ways-to-write-fearless-spreadsheet-formulas/ | ||
source: 18f | ||
date: 2024-11-05 00:00:00 -0500 | ||
title: "Three ways to write fearless spreadsheet formulas" | ||
deck: "Spreadsheet formulas can be intimidating, especially given their critical | ||
role in government operations. Applying simple programming principles, 18F | ||
created a resource for making formulas clearer, easier to read, and less | ||
error-prone. 18F introduces three key techniques: using the LET function to | ||
name variables and organize code logically, adding comments to clarify complex | ||
formulas, and leveraging the LAMBDA function to break down problems into | ||
manageable parts. Together, these methods transform spreadsheets from sources | ||
of anxiety into tools of clarity and confidence." | ||
summary: "Spreadsheet formulas can be intimidating, especially given their | ||
critical role in government operations. Applying simple programming | ||
principles, 18F created a resource for making formulas clearer, easier to | ||
read, and less error-prone. 18F introduces three key techniques: using the LET | ||
function to name variables and organize code logically, adding comments to | ||
clarify complex formulas, and leveraging the LAMBDA function to break down | ||
problems into manageable parts. Together, these methods transform spreadsheets | ||
from sources of anxiety into tools of clarity and confidence." | ||
# See all topics at https://digital.gov/topics | ||
topics: | ||
- analytics | ||
- data-visualization | ||
- digital-service-delivery | ||
slug: three-ways-to-write-fearless-spreadsheet-formulas | ||
# Controls how this page appears across the site | ||
# 0 -- hidden | ||
# 1 -- visible | ||
weight: 1 | ||
--- |
Oops, something went wrong.