Merge pull request #36 from 18F/2018-revamp

2018 content update

_data/navbar.yml

@@ -13,17 +13,22 @@ assigned:
         show_in_footer: false
         children:
           -
-              text: 'Agile Development'
+              text: 'Human-centered design'
+              href: pages/strategies/human-centered-design.md
+              show_in_menu: true
+              show_in_footer: false
+          -
+              text: 'Agile development'
               href: pages/strategies/agile-development.md
               show_in_menu: true
               show_in_footer: false
           -
-              text: 'Modular Procurement'
+              text: 'Modular procurement'
               href: pages/strategies/modular-procurement.md
               show_in_menu: true
               show_in_footer: false
           -
-              text: 'Open Source'
+              text: 'Open source'
               href: pages/strategies/open-source.md
               show_in_menu: true
               show_in_footer: false
@@ -33,7 +38,7 @@ assigned:
               show_in_menu: true
               show_in_footer: false
           -
-              text: Building Prorotypes
+              text: Building prototypes
               href: pages/strategies/prototyping.md
               show_in_menu: true
               show_in_footer: false
@@ -45,24 +50,24 @@ assigned:
         show_in_footer: false
         children:
             -
-                text: 'Protecting At Risk Kids'
+                text: 'Protecting at risk kids'
                 href: pages/projects/ca-child-welfare.md
                 show_in_menu: false
                 show_in_footer: false
             -
-                text: 'Strengthening the Safety Net'
+                text: 'Strengthening the safety net'
                 href: pages/projects/ak-medicaid.md
                 show_in_menu: false
                 show_in_footer: false
             -
-                text: 'Streamlining Procurement'
+                text: 'Streamlining procurement'
                 href: pages/projects/vendor-pools.md
                 show_in_menu: false
                 show_in_footer: false
     -
-        text: 'Questions'
+        text: 'Learn more'
         href: pages/common-questions.md
-        permalink: /common-questions/
+        permalink: /learn-more/
         show_in_menu: true
         show_in_footer: false
     -
@@ -77,9 +82,4 @@ assigned:
         permalink: /about/
         show_in_menu: true
         show_in_footer: false
-    -
-        text: 'Project data'
-        href: _data/projects.yml
-        show_in_menu: false
-        show_in_footer: false
 unassigned: []

_strategies/agile-development.md

@@ -10,36 +10,36 @@ image-credit: https://www.flickr.com/photos/hernanpc/
 
 ## What is Agile Development?
 
-Agile development describes a set of principles for building software that allow collaborative, cross-functional teams to accommodate changing user needs and requirements.
+Agile development describes a set of principles for building software that allow collaborative, cross-functional teams to accommodate changing user needs and requirements. Agile development alone will not help you build a good product. In fact, many agile projects fail unless they work to integrate human-centered design.
 
 One of the great strengths of agile development is that delivery is incremental, which spreads the risk across the entire development process rather than loading all of it at the very end. When things go wrong, they’re smaller problems that can be fixed more quickly and more easily.
 
-#### Agile development is based on the reality that you will discover new requirements during the development process.
+### Agile development is based on the reality that you will discover new requirements during the development process.
 
-In any complex system, needs change, evolve, or are discovered over time. Instead of ignoring these changing needs, or going through a painful contract amendment and renegotiation process, we embrace the concept that we will discover new requirements as we go.
+In any complex system, needs change, evolve, or are discovered over time. Instead of ignoring these changing needs, or going through a painful contract amendment and renegotiation process, we embrace the concept that we will discover new user needs and constraints as we go.
 
-To help this process, we pair identifying requirements at a higher level (an “epic” in agile terminology) with an ongoing user research process. These epics describe the user need, not the solution. Through the user research process, these epics are turned into a set of increasingly-specific user stories. This is done continuously, so that user stories are ready for the development team no more than a month ahead of when the development team implements them. (For example, a user story might be: “As a caseworker, I want to see all my current cases and next steps so I know what I need to do next, and when I need to do it.” We wouldn't write: “The system shall display the next step next to each case in a grid on the main screen.”)
+To help this process, we pair identifying goals at a higher level (an “epic” in agile terminology) with an ongoing user research process. These epics describe the user need, not the solution.  For example, a user story might be: “As a caseworker, I want to see all my current cases and next steps so I know what I need to do next, and when I need to do it.” We wouldn't write: “The system shall display the next step next to each case in a grid on the main screen.” Through the user research and usability testing throughout the life of the product development, these epics are turned into a set of increasingly-specific user stories. Each story should be designed, researched, developed and tested within a single sprint. We validate each implemented story with usability testing with real end users, and use the feedback from that work to generate additional backlog user stories.
 
-There are three leading causes why IT projects fail: a lack of reliable input from users, incomplete requirements and specifications, and changes in the requirements and specifications. The Standish Group, an IT research firm, publishes an annual report on IT projects, in which they point out that these causes of failure are about the impossibility of “knowing” requirements up front.
+ We prioritize user stories continuously and do not focus on what is in the development backlog beyond what can be done within the next month.
 
-#### Agile development requires a shift in how you understand the costs of software development.
+### Agile development requires a shift in how you understand the costs of software development.
 
-The traditional “waterfall” method of software development assumes that software can be built once for a large, one-time investment. In practice, this is untrue, because requirements can rarely be fully known and change constantly. Users' needs tend to arise through research and testing, and development teams must discover appropriate solutions by building iteratively and interacting with users regularly.
+The traditional “waterfall” method of software development assumes that software can be built once for a large, one-time investment. In practice, this is untrue, because requirements can rarely be fully known and change often. The product team's understanding of users' needs arise through research and testing, allowing you to provide reasonable cost estimates in the short-term.
 
 Ultimately, the state’s investment should be measured in working software, not phase documents or milestones. Only working systems are of value to real constituents. Based on that premise, teams are only able to measure the success of a waterfall project after most costs have been incurred, because that is the first time working software is delivered. This is a huge risk. Agile projects allow the state to measure success at more regular intervals, and reduce the overall risk to the state.
 
-#### Starting with small projects can help build agile project management skills.
+### Starting with small projects can help build agile project management skills.
 
-We recommend starting with a small, less important project in order to develop your team’s understanding of agile project management, then expand. Diving right into a large, high profile, or critical project is risky; it requires more coaching and training.
+We recommend starting with a small, less important project in order to develop your team’s understanding of agile project management, then expand and incorporating a user-research practice into that development. Diving right into a large, high profile, or critical project is risky; it requires more coaching and training.
 
-#### Incremental development can allow end users to start seeing benefits even before the legacy system can be fully replaced.
+### Incremental development can allow end users to start seeing benefits even before the legacy system can be fully replaced.
 
-Old systems must be kept up until the new system is fully operational, no matter what approach is used. In a monolithic approach, the end user must wait many months or years to use the new system and see any benefit — and that’s assuming there are no problems with the rollout. In an incremental approach, the end user could start seeing benefits in weeks. Depending on the architecture of the legacy system, parts of it may even be able to be decommissioned and turned off before the full new system is in place to save money.
+If a workflow is worth preserving, then portions of the old systems must be kept up until the new system is fully operational, no matter what approach is used. In a monolithic contracting approach, the end user must wait many months or years to use the new system and see any benefit — and that’s assuming there are no problems with the rollout. In an incremental approach, the end user could start seeing benefits in a shorter time-frame. Depending on the architecture of the legacy system, parts of it may even be able to be decommissioned and turned off before the full new system is in place to save money.
 
-#### Agile principles recommend documentation that supports long-term maintenance.
+### Agile principles recommend documentation that supports long-term maintenance.
 
 One common misconception about agile development, which calls for _just enough_ documentation, is that there will be _no_ documentation. That is not true: agile prescribes documentation that is of value to the long-term team.
 
-#### Like any process, agile development has risks — but they are avoidable.
+### Like any process, agile development has risks — but they are avoidable.
 
 In some cases, teams incorrectly using agile as justification for poor or no architecture, design, or documentation. Incomplete, incorrect, or uninformed adoption of agile techniques can lead to an ineffective process we call “agilefall.” We've written a blog post about [how to avoid this pitfall](https://18f.gsa.gov/2015/12/29/is-your-project-using-agilefall/).

_strategies/human-centered-design.md

@@ -0,0 +1,82 @@
+---
+layout: strategy
+title: Human-Centered Design
+description: Build a product that works well for your users.
+permalink: /human-centered-design/
+tags: strategy
+image: /assets/img/strategy-images/hcd.jpg
+image-credit: https://www.flickr.com/photos/nearsoft/
+---
+
+## What is human-centered design and why is it important in modular contracting?
+
+Human centered design is an approach to engage the end user in software development to yield actionable, prioritized, and assumption-challenging results. By directly engaging users throughout, HCD builds products that work better for users, require less rework, and prompt fewer support calls. We believe that theses approaches need to be incorporated at every step of the agile process. From conducting design research before and at the beginning of an acquisition, and usability testing for every sprint and user story developed.
+
+## Four tenets of human-centered design
+1. Put people before technology.
+2. Conduct design research.
+3. Focus on common user needs.
+4. Only accept proof in use.
+
+### Put people before technology.
+This does not mean that people design the system. In human-centered design we figure out the best way to meet people's needs and then figure out how to make it work within our constraints. If we start with user needs, we can see what needs we can’t meet within our current limitations and work on expanding them. This often maximizes meeting user's needs. Moreover, it helps us prioritize what needs should be met and which needs can be adapted given our constraints.
+
+### Conduct design research.
+We find out people's needs by observing and speaking directly with them with design research methods — not via surrogates or our own assumptions.
+
+In conducting design research, *participants are users*, people who touch the software. This helps us better understand the diversity of users experience that we cannot capture from experts. 
+
+We interact with *many participants in one-on-one sessions*, not large groups, so that we can observe them as they would use the software and minimize pressure they might feel in a group. It also helps prevent group think that might be different from when we talk to a user independently.
+
+We use *standardized* questions and targets of observation so that we identify common patterns across participants and observe a similar workflow for multiple users, rather than just a piece of that workflow. With a standardize targets of observation, we try to talk about all parts of process with everyone.
+
+We *observe and ask about behaviors*, instead of their opinions, because opinions — without an understanding of what people actually _do_ — are rarely actionable.
+
+We leverage a number of different methods that are ok within government such as:
+
+* Stakeholder and user interviews
+* Card sorting
+* Multivariate testing
+* Usability testing
+* Visual preference testing
+* Contextual inquiry
+* Dot voting
+* KJ method
+
+For more on how to use these methods check out [methods.18f.gov](methods.18f.gov).
+
+#### Contextual inquiry
+One tool that is especially helpful prior to conducting an acquisition is contextual inquiry, that occurs where a user will likely be when they use your tool.
+
+1. Go to the places users work.
+2. Ask them what they do.
+3. Observe and ask follow up questions.
+4. Repeat with different users.
+
+### Focus on common user needs.
+We build products that meet the needs shared by the most people and meet address business goals. If we chase idiosyncratic practices we will build an overly-complicated system, that could actually make it harder for most users.
+
+### Only accept proof in use.
+We’re only done when we see — via design research — evidence users can accomplish their goals. Usually, what we hear, what we make, and what’s needed aren’t aligned the first time. So we often conduct usability testing to obtain feedback about how users attempt to accomplish those goals in a product. 
+
+We are ok that we don't get it right the first time, because we often learn a lot more by showing users a rough draft, than just describing to them the idea of what we are thinking.
+
+#### Conducting usability testing
+
+1. Give a user *a functioning product.*
+2. Ask them to *complete a task.*
+3. Observe and *be quiet.*
+4. Repeat with *different users.*
+
+For more on how to run a usability test, check out the [method card on it](https://methods.18f.gov/validate/usability-testing/)
+
+
+
+
+
+
+
+
+
+
+