As a data prepper, I want to evaluate conceptual mockups (v.1) simulating the uploading of flat files associated with TANF reports

[matthewjdoty]

Description:

Evaluate how grantees react to a concept prototype(s) simulating the uploading of flat files. To do so, we will create wireframes for evaluative testing during Round 3 of the user research with STTs.

Questions:

1. What is an 'older text format'? And, is it different from the new flat file format?
2. Do we show output (human-readable version) of flat files?

What will not be done in this issue:

1. Formal mockups will not be created as deliverables for Dev team and may not meet all of the USWDS guidelines.
2. Formal mockups will not show building or updating flat files via manual entry

Note

These mockups will be further explored after #170 (conversation guide) is complete in future sprints.
These mockups will be finalized after interviews are completed with STTs in future sprints.

AC:

• Wireframes are created and reviewed
• This is a usable artifact for user research
• Follow on issues are spun up, incorporated into research goals, interview protocol

Tasks:

• Review what is known about uploading flat files (inc. Tim prototype screenshots)
• Mockup layout
• Review layout with Dev for any functionality issues and update mockup as appropriate (focus on functionality)
• Update mockup per dev review
• Hold a workshop w/ OFA + 18F to review mockup and gather any feedback (Conceptual focus: instead of meeting all of the USWDS guidelines)
• Update mockup per workshop
• Mockups are added to Create a user research plan for STTs for Aug-Sept 2020 #63

Supporting Documentation:

User research findings:

• STT Spring 2020 (Link)
• OFA Interview Raw Notes (Link)
• OFA Interview Synthesis (Link)

DoD:

• Documentation: Conceptual mockups simulating the uploading of flat files associated with TANF reports has been shared with the PO and team for feedback
• @cmajel has reviewed and signed off
• @lfrohlich has reviewed and signed off

Deliverables:

Conceptual Mockup 1 (Edit Data within App): (Link)
Conceptual Mockup 2 (Edit Data within Flat File): (Link)

[dk-ui]

Just wanted to call out here for increased transparency that:

• These mockups will be further explored after Draft interview protocol for Round 3 of research with STTs #170 (conversation guide) is complete in future sprints.
• These mockups will be finalized after interviews are completed with STTs in future sprints.

[dk-ui]

Resulting from discussion and feedback on these conceptual mockups, additional design iterations were created #295, further questioning TDP functionality. These iterations will be revisited in later sprints.

[cmajel]

@dk-ui looking good! I think we'll learn a lot from testing these.

One note for me to sign off. The AC says

• This is a artifact that can be shared for user research conversations.
  Do y'all have a clickable prototype link that could be shared with a participant? If so can you add it to the issue description.

With that I'm good moving this to demo A few additional feedback notes:

• Flagging that demoing both of these flows, in addition to learning about transmission process and team structure, may be a lot to cover in 60 mins. If you want to test both, you may want to think about split testing or putting more time to concept review.
• Of the two flows, the edit in app / flow 1 seems to be the simpler option for users, as I can make my fixes within the app.
• Noting a difference between the progress bar's "checking format" and the step indicator's "Validate file info" heading. Should these be the same?
• It still takes me a while to figure out that I'm getting an error because my file conflicts with what I entered on the webform - it takes a lot of reading. It'll be interesting to see if STTs understand that's what's happening. I wonder if even framing it as a "conflict" or "inconsistency" would be helpful.
• For future consideration....
  • What would happen if there weren't any inconsistencies found? Would I just see art boards 1.7 / 2.7?
  • What would happen if all my files had conflicting calendar quarters? It feels like the error page would get quite long.

[dk-ui]

@cmajel Thank you!

AC Question

• Ticket description is updated with links to each clickable conceptual mockup (shown below)

Conceptual Mockup 1 (Edit Data within App): (Link)
Conceptual Mockup 2 (Edit Data within Flat File): (Link)

Other Points:

• We agree, we are going to do a few run throughs while creating the convo guide to determine the best approach in regards to time.
• We changed the "checking format" to "Validate File Details" so that it is consistent
• Yes I agree, after the convo guide, when we revisit this we will have a discussion on if we want to simplify this text further or keep it heavier to open the conversation up to the user.
• If inconsistencies are found the error screens would be skipped
• Good point! We will discuss methods to shorten it (i.e. A "show more" button; or breaking the validation section up into smaller steps like validate section 1, then validate section 2 etc.)

Thank you so much for your feedback! This is all super helpful!

[lfrohlich]

I made some comments in the mockups, some of which are also pasted here.

• It would be a good to note in the interviews if there are other things that folks call these sections (we heard a bit of this in our earlier research). Would also be good to note that they could submit multiple sections or submit them separately

Alex asked re: "Validate File Details": what's validation mean here i know this is a longer discussion, but my preliminary thoughts on what this could mean:

• the correct record types are included (e.g. T1, T2, T3 for Tanf Section 1)
• the records have the appropriate length/number of positions

For discussion: should these be included as file details or as part of validate report sections? For now it seems like the intention of the validate file details is to check the filename, header, and footer.

• the reporting month is in range with the time period noted on the first page selection

[lfrohlich]

This was closed in Sprint 4