ROLE
TOOLS
DURATION
CLIENT
Product, UX, & UI Design
Figma, Salesforce
October 2021 - April 2022
US Dept. of Veteran Affairs
PROJECT SUMMARY
Booz Allen Hamilton has partnered with the VA to create a new application to help prepare for and manage localized incidents that occur at VA Medical Centers that require labor pool. Labor pool being initiated means an incident requires individuals from other departments at the VAMC to help aid in whatever tasks are needed during these incidents or emergencies. Currently, the VA had no application in place to handle supervisors submitting their employees into labor pool, creating needs/tasks, or matching these labor pool members to needs. They also lacked cumulative reporting metrics and accountability measures.
MY ROLES & RESPONSIBILITIES
As the sole designer on this project team, I was tasked with leading or assisting in:
-
Requirements gathering
-
Product feature creation with collaboration from the Business Analyst and Salesforce Solution Architect
-
Conducting user research and analysis, user flow mapping, information architecture design.
-
Creating custom Salesforce functionality design, wireframes, prototype demos, UI design
-
Conducting product testing, usability testing, and quick reference guide writing.
PROBLEM & DESIGN CHALLENGS
With no current software or set standards to manage labor pool during an incident, each VAMC member interviewed shared experiences different from the next on how their teams handle incident response with labor pool. This proved to create challenges when creating user journeys as most people's practice varies from VAMC to VAMC.
How might we centralize labor pool functions to prepare, coordinate, and complete labor pool submissions, tasks, and assignments.
This application will be built using Salesforce and Salesforce's Lightning Design System. Creating a complex application and tailoring it to a specific need of the VA while trying to maintain standard Salesforce practices and functionality will prove to be a fun challenge.
WHO ARE THE USERS? - PERSONAS
After initial requirements sessions with the SMEs, it was determined that there would be 4 unique types users of this application in compliance with the VAMC Incident Command structure.
KEY RESEARCH INSIGHTS
Following the first set of requirements gathering sessions and initial round of user interviews, synthesis from these sessions yielded the following key insights:
Insight #1
Each incident has a different set of needs/tasks that have to be documented and communicated.
Insight #2
Most supervisors want to have the ability to submit their employees by the hour - not an entire day.
Insight #3
Current practices do not allow for easy reporting of incident and labor pool statistics.
Insight #4
Labor pool members need to be matched/assigned to a need based on time available.
Insight #5
It can take 50+ hours for various personnel to complete the organization, creation, and management of labor pool.
Insight #6
Many of those coordinating the incident or volunteered into labor pool don't have all the details of what they are needed for and where they report.
WORKFLOWS - HAPPY PATH
After conducting initial user interviews with department leaders at various VAMC locations in VISN 1 (New England), it was clear that no location handled incidents with the same journey. They used any combination of manual phone calls, Teams messaging, shared Excel spreadsheets, shared Microsoft Forms, or email to create needs/tasks, submit team members into labor pool, and coordinate the assignment of those needs. This was all happening in the midst of an emergency. Speed was key.
Since there as no singular user journey for handling the enactment of labor pool and its organization, it was more beneficial to create a happy path based on user research than to create various journey maps for each scenario.
ITERATIVE DESIGN & DEVELOPMENT
After establishing the information architecture alongside the Salesforce Solution Architect, lightning pages in Salesforce needed to be created to start displaying functionality and related objects for this application.
​
Basic App Functionality and Page Layouts
These pages were needed for the application to have basic functionality to create, display, and edit objects related to the incident itself. These pages consist of objects relating to the incident including, needs, labor pool members, need/pool member assignments, incident locations, and incident team members.
Below are examples of redlining page layouts sent to the dev team to create better data visualization, record creation forms, and reduce cognitive overload.
Custom Functionality #1 - Adding a Team Member into Labor Pool
To accommodate a very important function into the LPT project, it was determined that a custom component and functionality will be added to create the process of adding a team member to labor pool. This functionality would be integrated with an API call to their HR system to populate employee data so that the information was accurate and up to date.
What is important to a supervisor/service chief in an emergency? Speed and accuracy.Below are the initial wireframes submitted for usability and feedback.
To accomplish this requirement, this new functionality and design had to be housed on a single page. This component will house the ability to add their members to labor pool by time. Once added to labor pool, managers will have the ability to adjust their submission or remove their employee from labor pool. The employee will also be notified via email that they have been placed into labor pool and to stay alert for further emails once assigned to a task. These wireframes are the product of the above prior version feedback and features components built and mocked up in Figma
Below are the final Figma art boards for this above custom functionality shared and collaborated with development documenting all functionality, user flows, and design tokens.
Custom Functionality #2 - Assigning Labor Pool Members to Tasks
To accommodate another very important function into the LPT project, it was determined that another custom component and functionality will be needed to assign labor pool members to a specific task.
​
This functionality has to take into account the date and time of both the labor pool member's availability and the task. The coordinator of this incident needed to be able to quickly access which tasks were still unassigned/partially assigned and add in additional. After some ideation, this initial wireframe of a drag and drop feature was created. The coordinator could drag the shift of the labor pool member and drop it into an open task, thus completing the assignment. This would give a seamless user flow and also give the user full visibility into the assigned status of each task for that day.
After research by the Salesforce architect and development team, it was determined that the drag and drop feature was not a native Salesforce functionality. I now had to ideate a way to replace the drag and drop feature but still keep this same user flow. So, instead of a drag and drop feature, the individual members would be assigned through a picklist that is located on each of their respective time bars.
Once the coordinator opens the picklist, a list of all available tasks (in the order they appear in the below container) will display and can be selected for assignment. After the coordinator selects a task to assign this labor pool member to, the labor pool member will be removed from the container and appear inside the task time bar.
With this type of scheduling functionality, there are many scenarios that must be accounted for when selecting labor pool members for assignments. What happens if there are overlapping time between assignees? availability extends longer than the task? someone is already assigned to the task? How many can be assigned to 1 task? etc.
​
Below are some of the documentation for the developers of behavior when there are more than one assignee to a task and there are overlapping times:
After discussions with the developers, it was clear that having more than 2 labor pool members assigned to a task was not feasible in this first iteration as the amount of logic to handle more than 2 assignments would be immense. Since the application was built with secondary flexibilities, there are ways to circumvent this limitation by breaking up the task into 2 tasks and assigning 2 to each task (total of 4), breaking up a labor pool member's large shift so they can be placed into multiple tasks, etc.
Below are the final Figma art boards for this above custom functionality shared and collaborated with development documenting all functionality, user flows, and design tokens.
IMPACT
-
Reduced hours of manual communications and organization of labor pool tasks.
-
Created more accountability for each department at the VAMC during an emergency.
-
Helped standardize a process that could potentially save millions of dollars and even lives.
-
Learn from prior incidents (what went wrong/what went right) by having documentation and reporting in one place.
-
Clone tasks from prior incidents if the same type arises, saving hours of manual input.
-
Up-to-date employee and location information through the use of HRPass API integration. (No manual updating)
FINAL RELEASED PRODUCT
