Mock up a new agreement creation form

[allisonnorman]

Background We are exploring opportunities to de-risk electronic agreement creation by doing some prototyping work in our E&I. More details can be found in #152 around how this fits into a broader strategy of de-risking, and more detailed user stories to come.

We'd like to think through how an agreement creation form could work, how it might fit into our existing prototype, create some mocks, and do some usability testing.

Key hypotheses:

• Putting a new agreement/proposal form online will help reduce errors and improve consistency.
• Encoding the decision tree into the online agreement creation process will reduce effort and errors associated with folks choosing the wrong agreement type.

We'll know we're done when...

• [ ] We have mocked up a new agreement creation form that we can start to test.
• [ ] Both Required AND Mandatory fields are captured (with differentiation?)

Tasks

• [x] Review Jay's example form that the policy team has been working on getting approved and see if we can leverage it for the basis of the required fields.
• [x] Create a draft mock for required fields
• [x] Share with team, get feedback
• [x] Share with Jay and Jamie, get feedback
• [x] Note ideas for future iteration

Resources to cross reference

• New FS 1500 cover sheet, to be the new award doc pulling data from NRM
• Agreement coversheet examples
  • Example 1 at the regional level (what are the region-agostic fields that exist?)
  • Example 2 (believe this is a research station?)
• G&A user guide (which notes current mandatory and required fields)
• G&A Field guide (which notes which fields are system required vs business required for different instrument types)
• Past DB mapping exercise (which notes hidden / autogenerated fields)

[tbaxter-18f]

I would recommend leveraging the User Guide for a list of both Required and Mandatory fields.

[cmajel]

@tbaxter-18f totally. Tracking a few other resources that could be helpful here:

• New FS 1500 agreement form
• Agreeement coversheet examples
  • Example 1 at the regional level (what are the region-agostic fields that exist?)
  • Example 2 (believe this is a research station?)

I think the first step in coordinating with #154 is to get a sense of what fields we need and what's different in these cover sheets from the user guide.

[cmajel]

I'm doing my field audit in this sheet under the Agreement creation field audit tab.

I'm still working through some audit pieces, but feel like we're getting to the point where we can start experimenting with mockups and exploring what research activities we need to test this.

[cmajel]

I did an initial pass at an agreement creation form with minimum fields in Figma.

Assumptions to validate:

• That we can hide/autopopulate certain fields if Federal Financial Assistance does not apply to the agreement
• That we should continue to provide an option for people adding agreements to link a Workplan ID up front

Next step is to review this internally and validate with Jamie.

[cmajel]

We reviewed our field analysis and initial mocks in Figma mocks with Jay and Jamie on 4/9 for their feedback.

I took notes in the spreadsheet and Figma of that review. A few highlights:

• Proposal / create a proposal is the phrasing we'll want to use here.
• Date received and date submitted could become system generated fields
• We may need to add a required project description field to comply with upcoming Data Act requirements
• Project categories does accept multiple entries, but the preference from a system admin standpoint is for there to be one entry
• The idea of a conditional field for FFA was received well, and we discussed how a similar approach could be used to filter for for the research-specific questions
• Being able to select a cooperator via DUNS or SAM.gov record would be ideal. But, not all agreements require a DUNS, and we'd need a workflow for a new cooperator. GMS maintain contact records for data integrity.
• Most proposals have a Workplan link from the start (including grants.gov items and no fund MOUs). Note that we should talk with budget about what systems they plan to use in the future (workplan? something different?)
• CFDA is now required for anything with outgoing funding (we had it for FFA items).

As we start thinking about #173 and working in these review notes, a few questions that are top of mind for me:

• Would a program manager know how to answer these questions? Same for grants management specialist, but I suspect these are more familiar.
• It feels that we could streamline what info we ask of people if we know more about the instrument type earlier. When do people know now? When do we ask this?
• What is the best way for us to reveal conditional fields to users?
• What additional info do we need to add to this so that it could be useful and actionable to a budget approver?

Screenshots