18F describes modular contracting, the process of breaking up large, custom software procurements into a small constellation of smaller contracts. Modular procurement requires agile, product thinking, user-centered design, DevSecOps, and loosely-coupled architecture.
Handbook by 18F designed for executives, budget specialists, legislators, and other “non-technical” decision-makers who fund or oversee state government technology projects that receive federal funding and implement the necessary technology to support federal programs. It aids in setting projects up for success by asking the right questions, identifying the right outcomes, and equally important, empowering decision-makers with a basic knowledge of the fundamental principles of modern software design.
In this blog post, we’ve detailed some of the steps we take to help capture the best data possible when conducting interviews. This post is intended as a guide for people who need to conduct user interviews and for people simply curious about how we work.
Testing (and re-testing) your designs with users will help you build the best possible product. Our Validate Methods cover varied testing scenarios and potential user groups.
The Decide Methods help you derive insights from the information gathered during the Discovery phase. You’ll validate initial assumptions, develop a deeper understanding of workflows and processes, and develop design hypotheses.
Government solicitations to procure custom software are often long, complicated, and take months. By using 18F’s agile contract format, agencies can hire an agile software contractor with a quickly-written dozen-page solicitation, allowing for immense savings in time and money.
It is frequently assumed that when rules are implemented as code, a rules engine is necessary. However, it is possible for policy people and engineers to effectively work together to code logic that drives technological system without needing a mediating rules engine at all.
