Section 2 | Guest dashboard: Tasks

[sanya301]

Problem Alignment

The Problem

Guests do not currently have a way to look at an overview of tasks, complete their application (intake profile) and track their onboarding and matching flow via an online mechanism.

User Story:

As a Guest, I should be able to see an overview of task groups as well as tasks(with description/links) that would be required to get matched, along with my progress.

High Level Approach

Dashboard page that shows high level task groups, tasks, progress and status of tasks needed for Guests to complete the matching process.

Solution Alignment

Considerations

• Anticipate that users will be using desktop, tablet, mobile devices --> use responsive design
• In the future, the plan is for the guest onboarding experience for multiple organizations (SPY and beyond), where different organizations might want to modify the tasks needed for a guest.

Goals and Success

Success is if guest can successfully determine all the tasks involved in the HUU process on the dashboard, see their progress and easily click into sections that are unlocked.

Key Features

• Task groups that contain tasks with logical groupings
• Ability to expand task groups to see all tasks in the task group, read their descriptions and status.
• All tasks up until the matching process should be included
• Progress bar that shows percentage of all tasks completed
• Progress in terms of x of y tasks completed
• Status of each task (Complete, In progress, Locked or More information is needed)
• Ability to click into a task to navigate to any additional pages needed to complete that task

Acceptance Criteria

• Guest is able to see the high level task groups needed in the HUU onboarding/matching process in one glance on the dashboard.
• Guest is able to expand a task group to see the tasks in that group, status as well as descriptions
• Guest is able to see the expanded task group that is currently in progress when they navigate to the dashboard
• Guest is able to see the status of the tasks (such as complete, in progress, locked or more information is needed)
• Guest is able to click into any additional page(s) needed to complete a task, or see any additional pages of completed task(s).
• Guest is able to view their progress and where they are currently in the whole process
• Guest should be able to see updated progress and task status updates, if any, the next time they navigate to the dashboard.

Known Limitations

• This issue focuses on creating the dashboard and tasks needed for a Guest to complete the matching process. For the home page to be complete, we would also need features handled by different user stories such as the Coordinator contact info, and Epics such as Navigation bars.

Designs

• [x] Review existing designs on Figma
• [x] Edit existing designs as needed and share a link to the edited designs in this issue
• [x] Designs are edited and ready for engineering - Link to the Figma: Guest Prototype Mobile , Guest Desktop Prototype

Figma

Engineering

• [x] #566
• [ ] #572

Key Decisions

• Guest is first taken to the main page with an overview of all the tasks needed to complete the matching process instead of straight to their intake profile (application).

Team Reviews:

• [x] Product - Sanya
• [x] Design - Ed, Jiehong
• [x] Engineering - Erik, Alejandro

[randelbrot]

Hi @sanya301, sharing a question from @edela0015 regarding showing a disclaimer: "I was looking through the application and was wondering if there would be a disclaimer of some sort just to manage guest expectations in case they don't get accepted by the coordinator".

This is a good point and something to consider for the Key Features in the story. For example, I could envision this as part of the view of the high level steps, the description for each step, and/or the status updates. Let us know what you think.

[edela0015]

proposed: https://www.figma.com/file/BNWqZk8SHKbtN1nw8BB7VM/HUU-Everything-Figma-Nov-2022?type=design&node-id=1483-15519&t=XH8FZoXnAVpMU99y-0

[ju1es]

backend proposal - we need feedback from frontend and product on this one. this is an initial pass and can consolidate/refactor the endpoints as needed but want to check if the necessary data is available for the features.

[edela0015]

note to @sanya301 :

"Acceptance Criteria Guest is able to view a progress bar as a percentage of whole flow Guest should be able to see an updated progress bar and step status updates, if any the next time they navigate to the dashboard."

these two features were removed as having having a vertical stepper with a horizontal progress bar breaks design principles. these two features will clash visually if a "quick glance" is required.

also designing steppers with tasks for the homepage/dashboard seems very complicated for the homepage and to contain into a small portion of the screen and would ask if a separate task page can be considered. Looking at different task heavy dashboards, the tasks were completed on a separate page from the homepage. please let me know your thoughts I will show another proposal soon.

[edela0015]

to add to that, showing overall progress with one key action item (the most relevant at the time) would be a better use of space since we also have to fit contact info and upcoming events

[agosmou]

@edela0015

Hey Ed - thanks for your contributions so far. Looking for some clarification:

these two features were removed as having having a vertical stepper with a horizontal progress bar breaks design principles. these two features will clash visually if a "quick glance" is required.

Are you saying we wont use them together, so we will ONLY use a progress bar, or are you saying that we will remove ALL iterations of a "visual progress indicator"?

[edela0015]

@agosmou just to rephrase, I just removed the horizontal progress bar as the placement of it did not make sense. the horizontal progress bar is a percentage of the whole flow, yet the whole flow is "flowing" downwards. the visual progress indicator is flowing downwards.

I uploaded an example from google's material design on common practice for vertical stepper and having both horizontal and vertical progress would be considered bad practice. please let me know if this makes more sense :)

[agosmou]

@edela0015

Gotcha! So the top has a full summary and the vertical steps is where each main step gets granular. Thanks for including the visual - helps a ton.

The Top: Step1 -> Step2 -> Step3

The bottom: Step1-substep1

Step1-substep2

Step1-substep3

[edela0015]

@agosmou oh no I was just explaining why I removed the top progress bar. it would be bad practice to do it this way is what I was trying to say.

[ju1es]

@edela0015 gotcha, can I remove the progress bar from the key features then?

[edela0015]

@ju1es i was able to work it out. Vertical progress bar with vertical steps.

[sanya301]

@edela0015 Just got back from my travels, is the conclusion that we are removing any horizontal views and only keeping vertical steps? So do we want to remove the below as a requirement? Guest is able to view a progress bar as a percentage of whole flow

[KowDesign]

Hi all, here is a link to the latest iteration which has the tasks section removed, rearranged dashboard and dropdown overlay.

https://www.figma.com/file/BNWqZk8SHKbtN1nw8BB7VM/HUU-Everything-Figma-Nov-2022?type=design&node-id=8154-110885&mode=design&t=RExwnH1XF0yXyYKf-4

[sanya301]

Per discussions with design, I've made the following updates to the Acceptance Criteria Guest is able to view a progress bar as a percentage of whole flow Guest is able to view their progress and where they are currently in the whole process Guest should be able to see an updated progress bar and step status updates, if any,

[edela0015]

proposed final edit: https://www.figma.com/file/BNWqZk8SHKbtN1nw8BB7VM/HUU-Everything-Figma-Nov-2022?type=design&node-id=1483-15519&mode=design&t=aYHw79RdPcs4vhFS-0

scroll all the way to the right

[randelbrot]

Hi @edela0015,

The final edit looks good!

One suggestion on wording: I suggest that we change "Relationship Creation Process" to "Host Matching", which I think is clearer.

I drafted descriptions for each step in this Google sheet.

@sanya301, feel free to jump in if you have any remaining edits.

Thanks!

[sanya301]

Thanks @edela0015 this is looking great! I agree with @brycelednar and left a couple of other comments on naming.

One last design element thought I had was could we put the locked steps in a "see more" section that the guest could click and that expands downwards? We could also consider showing the first locked step (that's not in progress) and leaving rest of them under see more. Again just thinking in terms of minimizing feeling overwhelmed during the process while providing access to all the info

[paulespinosa]

Hi @sanya301, a few questions:

1. It seems that the "Steps" and "Tasks" terminology appears to have been lost in Implement Guest Dashboard Components #566 and Implement Guest Dashboard Endpoints #572 and also in the Figma designs. It looks like Steps and Tasks have been replaced with Tasks and Sub-Tasks, respectively. The Google Sheet - Work in Progress - HUU Sub-Flows List says that "Guest In-person Verification & Training" is "N/A - not a task, contains sub-tasks" which uses the "Sub-Task" terminology again. Is the terminology in this issue's description out of date?
2. Regarding the acceptance criteria "description of step", the Google Sheet - Work in Progress - HUU Sub-Flows List has descriptions for Tasks. Is the criteria to have descriptions for Steps or Tasks?
3. About the consideration "In the future, the plan is for the guest onboarding experience for multiple organizations (SPY and beyond), where different organizations might want to modify the steps needed for a guest." What does "modify" mean? How might an organization want to modify the steps?

[sanya301]

Hi @paulespinosa thanks for raising this, here are some async follow up questions

1. Where in designs do you see the terminology to be out of date with this main issue? The engineering issues definitely have deviated from the main user story here and I did not realize that until you brought it up. The description of Steps vs Tasks under Key Decisions in this issue as well as the sheets link is something that @randelbrot created probably when I was out in July and I don't think I ever reviewed or got notified of these changes. We need to align on naming in the sheet, on this issue as well as any engineering issues.
2. If we follow the spreadsheet naming convention, then the description is for each task
3. There may be organizations that say don't have an in person training (i.e. delete a task), or have virtual training (i.e. rename tasks or steps), have additional tasks or steps, or want to reorder steps. We can discuss if some of these are harder than others from an engineering perspective, but these definitely do not need to be a part of MVP

Let's discuss further in the meeting today.

[paulespinosa]

Hi @sanya301

1. I went back to Figma to look for an example, but I can't find it anymore. Either I misread or I was looking at a very old iteration of the design. The current design appears to be aligned from the user's perspective. The Guest Dashboard has a "My Tasks" widget that contains "groupings". The groupings have titles but aren't labeled as being called "sections" or "steps". The grouping headers say "x of N tasks". The elements of each grouping are not specifically labeled. But, I can see how a user would infer that they are Tasks based on the grouping's header containing "x of N tasks" and the widget being named "My Tasks".
2. Got it. "Description of Task" matches the design.
3. The following are all post-MVP considerations:
   • Deleting, renaming, re-ordering Steps and Tasks is doable. Assuming a story exists to implement Steps and Task editing features.
   • Allowing an organization to add a Task is doable as long as the Task is an existing feature of the application. For example, assume the application has a Form editor, an organization can create or modify a Form and then assign it as a Task.
   • Giving an organization the ability to create a new type of Task that doesn't already exist in the application is a major feat (might not be possible). For example: just one organization wants their own feature that allows a Guest or Host to record a video from the web application and then assign that as a Task; if the application doesn't have the capability for the organization to make this feature themselves then it won't be possible.

The question is: what would a user call the "groupings"?

[paulespinosa]

@sanya301 @rpradheap This issue is called "Guest Dashboard" but it focuses specifically on the "My Tasks" widget. It would be helpful to rename the issue to reflect that focus: "Section 2 | Guest Dashboard: My Tasks" or "Section 2 | Guest Dashboard: Matching Process Steps". The title is up to you.

Note: The "widget" terminology is what I introduced here. A Dashboard is an at-glance view of key information. A Dashboard can be thought of as displaying "Widgets". You don't have to adopt that terminology though.

[Joshua-Douglas]

Thanks for the discussion @paulespinosa, @sanya301, and @rpradheap,

The current plan for #572 is to create a guest dashboard that has multiple sections. Each section will have 1 or more tasks, and each task will have a status and a description.

We are hoping to design the backend so that it will be flexible enough to support provider-specific customization, but for the MVP we will not implement the features needed to actually create custom dashboards. The MVP will just have one default dashboard.

Let me know if you'd like any changes.

[sanya301]

@paulespinosa Answering your comment from 2 days ago:

3. The following are all post-MVP considerations:
   • Deleting, renaming, re-ordering Steps and Tasks is doable. Assuming a story exists to implement Steps and Task editing features.
   • Allowing an organization to add a Task is doable as long as the Task is an existing feature of the application. For example, assume the application has a Form editor, an organization can create or modify a Form and then assign it as a Task.
   • Giving an organization the ability to create a new type of Task that doesn't already exist in the application is a major feat (might not be possible). For example: just one organization wants their own feature that allows a Guest or Host to record a video from the web application and then assign that as a Task; if the application doesn't have the capability for the organization to make this feature themselves then it won't be possible.

Yes the expectation would only be the ability to add a task type that already exists. For a new task type they would have to come to us with a feature request. Again note that none of this is part of MVP so no such stories exist as of now. I hope we can start with a static version and then think of a more dynamically editable version in V2 or V3. But if you have concerns with this, please let me know

The question is: what would a user call the "groupings"?

We discussed this in the PM meeting and this user story has been updated to call what you referred to as "groupings" as task groups. We will bring this to the Tues meeting for further discussion if needed

[paulespinosa]

Thank you @Joshua-Douglas @sanya301.

@sanya301 I see. Task Group is a logical grouping of the Tasks needed to complete an organization’s onboarding and matching process. Do these logical groupings, Task Groups, represent any existing concept or process from our target organization, SPY? Thank you.

[agosmou]

Great conversation above. To confirm, we're dropping section, steps, etc. as the naming convention for "groups"...

and we're aligning with:

task_group:

• task_1
• task_2 etc.

[jiehongc]

Updated user story with mobile and desktop Figma file links