Auto-Plan
Making a complex algorithm feel like magic
- UI Design
- User Observation
- Interview
- Usability Testing
Making a complex algorithm feel like magic
I served as UX Lead for this feature in PACT Planner—a web application that helps program analysts maximize profit for government contractors by allocating labor across different efforts while remaining compliant with complex contract requirements.
Government contracts often specify how many hours each role should work based on an estimate from the contractor. Program analysts are tasked with ensuring employees work as close to the number of funded hours as possible.
"We max our profit when they work exactly the hours they're funded. If they go over, we have to eat the cost. If they go under, we're leaving money on the table." -PACT Planner user
If analysts had a crystal ball, I’d be out of a job. Fortunately for me, predicting the exact number of hours an employee will need is practically impossible. Even if it weren’t, numerous factors affect an employee’s availability, like unexpected absences, project delays, and demand on other projects. So program analysts must constantly adapt their plans in response to unexpected deviations.
Constantly adapting just one plan is time consuming, but our users juggle dozens of plans for various efforts at once. Users reported feeling overwhelmed and frustrated, especially towards the end of the fiscal year when many projects end.
“September is what we call ‘hell month’ and I apologize for cussing, but it is truly 'hell month'" -PACT Planner user
We applied a Design Thinking approach tailored to our team's constraints.
I started with user interviews and observation sessions to help our team understand user workflows and pain points. We discovered that program analysts typically adjust one of three variables to account for deviations from a plan: an employee's future level of effort, end date, or total hours. We also learned that users frequently rely on external spreadsheets to perform calculations PACT Planner does not support, then manually input that data back into PACT Planner.
Then, I designed a usability test to simulate the planning and maintenance of a typical project. I tested with 6 of our product team members, mostly because of restricted access to real users but also to cultivate empathy toward users. The test's tediousness proved rhetorically effective for team members skeptical about the severity of the problem.
I labeled and organized pain points and errors from usability testing/user observation sessions in our research repository to illustrate the distinct pain points users face.
Next, I created UX maps to illustrate user workflows and identify inefficiencies. This process highlighted that eliminating spreadsheets and manual data entry from users' workflows would save them significant amounts of time and reduce task complexity.
Before creating visual designs, I brainstormed solutions in broad strokes with a colleague. We settled on the idea of an auto-updating plan and explored how it might work across different contract types and planning strategies.
I then iterated through design concepts in high-fidelity. Since we already have a design system, there was no need to start with wireframes or low-fi mockups.
After settling on a couple of design concepts, I created prototypes for each.
I demonstrated our prototype to a group of users and received overwhelmingly positive feedback. If not for budget and time constraints, I would have liked to conduct formal usability testing.
I worked with our tech lead to break the concept into bite-size chunks for our agile-abiding team to tackle, then created prototypes and documentation for each bit.
Currently, I am working closely with developers to communicate design specs, review PRs, and help with HTML/CSS. I have also created a basic prototype of the algorithm in CodeSandbox using Javascript as a testing and informational tool for developers and testers.
To help users manage spend plans more efficiently, we developed Auto-Plan—a feature that automatically creates and maintains employee hour allocations. Auto-Plan adapts as employees log hours, continuously adjusting to ensure employees are planned to meet their allocated hours.
Users can customize how Auto-Plan makes adjustments. They can choose to fix either an employee’s end date or level of effort, and Auto-Plan will adjust the other. For instance, if an employee with a fixed level of effort works less than planned in the first few pay periods of a project, PACT Planner will extend their end date. If that employee instead had a fixed end date, PACT Planner would decrease their planned hours for future pay periods.
Users can override the Auto-Plan hours for any pay period and Auto-Plan will automatically adapt to ensure employees are planned to meet their allocated hours. It’s also easy to preview the effect an override will have on the burnout date or future level of effort. Overriding helps users refine Auto-Plan’s work when they have more accurate predictions for the future.
Auto-Plan includes various conditional warnings and indicators to alert users when an employee is unlikely to follow their plan. These warnings or indicators appear:
Warnings may prompt the user to override the plan, adjust allocated hours, or instruct the employee to adhere to the plan.
In addition to warnings, we incorporated several UI elements to make Auto-Planning intuitive and easy to understand:
This feature is not yet released, but users responded very positively to demonstrations:
“This is awesome. I'd say this is almost like magic."
"This does exactly what I was hoping to accomplish."
"I'm really excited about the auto-planning feature."
"That's one less thing we have to worry about doing manually."
We anticipate that Auto-Plan will save users about three hours of work annually for a typical contract. Considering users manage dozens of contracts each year, I expect this feature will significantly increase user satisfaction, efficiency, and effectiveness when using PACT Planner.