-
Notifications
You must be signed in to change notification settings - Fork 65
Overview Explanatory content
The Design Manual is an open-source resource built to help employees and contractors produce effective and visually-consistent print and digital products. The Manual includes our design principles, guidelines for user experience, identity standards, and code snippets for common user interface elements. The Manual will continue to evolve as we learn what works best for the CFPB and the people we serve.
We have designed the Manual to be open for the public, which allows you to help us make improvements. All content has been released as open source under the CC0 1.0 Universal Public Domain Dedication, and we’d love for other agencies, developers, or groups to adapt it for their own use.
Many style guides influenced the creation and organization of the Manual, including those from Mozilla, MailChimp, and the BBC. Our primary inspiration is the UK Government Digital Service's Service Design Manual. We hope ours will serve as a step toward improving user-centered design across all US government websites and services.
Hmmm not sure what to say here. Best practices
The CFPB brand helps to cultivate a trusted relationship with consumers and enable them to live better financial lives. These guidelines represent the most up-to-date visual expression of the CFPB brand, also known as identity. When used as the building blocks for visual communication, we can be confident the final output will be consistent and recognizable as a CFPB production.
The UI toolkit contains guidelines for using CFPB's Capital Framework, a set of front-end components built by in-house developers to make creating consistent, on-brand web products as easy as possible.
A good example from Mailchimp:
"A common lexicon of code and UI elements benefits us in a few ways:
- We can build consistently and focus on workflows and logic, not web forms and list items
- We can reuse code instead of roping in a developer
- We can maintain our code by seeing our patterns in one place, define elements in our application, and keep redundancy to a minimum We guard our pattern library jealously, and add new patterns only when the case for doing so is sound. New patterns come at a high cost—they require new design elements, additional code, maintenance, and they increase the cognitive load on users."