Known design debt

Goals of this wiki section

• Write down where we made quick decisions that should be revisited
• Be open about what we still don’t know
• Document questions that need to get answered for different topics a future team will encounter

---

Known Design Debt

Like software, design is never done. This is a place for us to document items we know will need to be revisited and the questions we know still need answers.

Product Vision

Our designs were created based on our initial roadmap and ideas for an MVP. However, we need to continually ask if this MVP vision is sustainable, and adjust our design work. Product development work was paused to revisit and refine the product vision. Picking up design work will need to start with any adjustments that the refined vision may require.

Integrations

• Our design work assumed there would be a linkage between G&A and Workplan, which is a tool used for budget planning. Workplan records help program managers and budget approvers validate if funds are available and set aside for a given project. Future teams will need to decide how integrated it should be.
  • What is the future of Workplan as a FS tool?
  • Should it prepopulate fields? Which ones?
  • Could a Workplan integration auto populate funding information?
• Our proposal creation mocks don’t assume an integration with SAM.gov. How might an integration with SAM.gov help us auto-populate proposal information based on DUNS/UEI?
• Our work came at a time when the federal government was preparing to change recipient agencies’ unique identifiers from DUNS numbers to UEI. How might this impact the new system’s design?

Proposal creation and review

• Our proposal creation process was designed assuming that making it easier for program managers to fill in the data will save time and reduce errors, but we learned that not all GMS’ share that assumption. We know that in some regions, data entry is done by grants management specialists and that some of them want to keep it that way.
• Our work came at a time when OG&A was piloting a new face sheet for new agreements (FS 1500); it has yet to be used widely. How should this new process be reflected in the application (if at all)?
• Our work on reviewing proposals starts to explore what the information architecture of an agreement could be. We’ve heard about the tabs being overwhelming, and not knowing what a lot of the stuff is. AND, we’ve heard of G&A specialists going tab by tab through the full agreement
  • What should the IA of an agreement record be at different states?
    • See current tab structure
    • In our reviewing proposals work, we reflected back structures from the proposal creation process. This should be tested further.
• Where is consolidation or relabeling useful? Harmful?

Open questions

Assignments

• We heard repeatedly that people want it to be easier to find “their” agreements and track them. But, it’s been hard for us to define what counts as “their” agreements, as it varies person to person.
• We’ve experimented with a very simple assignment concept in an early design round, but have not yet dug into these questions.
  • How do I know when something is assigned to me?
  • Would this best be achieved by leveraging roles in UMA or the contacts table in the G&A database?
  • In some regions/stations, there is one person who then delegates to others. How might we design this in a way that meets the needs of regions/stations where things aren’t assigned to individuals, but instead people w/ capacity pick up what’s at the “top of the stack”

Versioning and editing

• We know that program managers and grants management specialists can share the responsibility to create agreements in NRM, and we believe making an experience that is easier for program managers will improve the predictability and reduce rework on agreements.
• But, this raises questions about how collaborative editing would work on agreements.
  • Should fields be editable by anyone? Or, should some be restricted to certain roles (e.g. grants management specialists)
  • How do we track and reflect back what has been edited by whom?
  • Do GMSs need document-level versioning of agreements, or can edits be done and recorded at a field level?

Guiding people through actions

• Different people need to review and edit agreement records throughout the agreement process.
  • How do we signal what fields / sections require action from a particular person? How widely is this broadcasted?
  • What does guidance look like? Ideas considered but not yet tested
    • Within an agreement record, highlighting fields or sections that need review. (e.g. add the agreement number and type in this section)
    • Having flows for specific tasks (e.g. a form appears where you’d enter the agreement number and type)
• What does it look like if multiple actions are needed in an agreement?

People we still need to talk to

• ASC/RACA
  • This is the group that manages accounting and executes payments.
• Policy groups
  • This is the group that currently manages policy and training around G&A and the NRM application.
• USFS signatories
  • These are people who sign actual agreements.