I first came across the redesigned IdentityTheft.gov on Reddit, of all places. Someone had posted a link to the Federal Trade Commission’s (FTC) newly redesigned site and wrote: I hope this never happens to any of you as the entire thing can be really stressful. The identitytheft.gov website is a true breath of fresh air…You can talk to an actual person. They also have this extremely easy wizard to click through your situation and it will auto-generate a “Recovery Plan” including dispute letters, steps to contact law enforcement, putting credit freezes, and basically protecting yourself.
In the five months since we launched the Draft U.S. Web Design Standards — the U.S. government’s very own set of common UI components and visual styles for websites — over a dozen websites have used components of the Draft Standards on their sites. Recently, we talked to three federal web designers about their experiences using the Draft Standards, which were designed with accessibility and flexibility in mind: Maria Marrero is the User Experience Designer for USA.
One of the most common questions we receive is: Should I integrate the Draft U.S. Web Design Standards into my existing project? The answer is: it depends. A lot of design research supports the notion that many people who use government websites or services may benefit from consistency across interactions, user experiences, and behavior across those websites. A consistent look and feel with common design elements will feel familiar, trustworthy, and secure—and users will be able to navigate government websites more easily because of a common palette and design.
Since our launch of the Draft U.S. Web Design Standards last September, hundreds of people have provided feedback on the project through GitHub issues and via email. We’ve received dozens of feature requests as well as over 400 contributions from the open source community. Over the past five months, we’ve incorporated suggestions from the feedback we’ve received, resolved a number of outstanding issues, and made various updates to our content and structure.
When we launched analytics.usa.gov with the Digital Analytics Program, the U.S. Digital Service, and the White House last March, we purposefully made it very easy to adapt and wrote language on the website to let people know they could use the code without restriction: This open source project is in the public domain, which means that this website and its data are free for you to use without restriction. You can find the code for this website and the code behind the data collection on GitHub.
2015 was a big year for 18F. We almost doubled in size, worked with 28 different agency partners, and released products ranging from Design Method Cards to cloud.gov. Internally, we improved onboarding and our documentation by releasing guides on topics as diverse as content, accessibility, and creating good open source projects. To mark the end of the year, we reached out to everyone at 18F and asked them to reflect on a meaningful project they worked on this year.
In January, 18F Consulting announced a new kind of process for vendors to compete for software acquisition contracts. The Agile Blanket Purchase Agreement (BPA) process would be open to existing vendors on Schedule 70, and require vendors to submit a working prototype based on a public dataset—and then show their work in a publicly available git repository. A number of decision factors led to the request for information (RFI) and then the request for quotation (RFQ).
We routinely publish our best practices in the 18F Guides, and today we’re happy to launch a new one: the 18F Open Source Style Guide. The Open Source Style Guide is a comprehensive handbook for writing clear, accessible, and user-friendly documentation so that your open source code repositories are accessible both internally and externally. It’s important to make sure our documentation is clear both for internal and external audiences.