Resource Requests: Bringing a Key Workflow Into the App

The Problem

A key workflow lived outside the app

Project managers had no way to request people in the app, and resource managers had no way to fill those requests there. All of it happened over email and outside tools. The result was vague requests, back-and-forth follow-ups, and hours of scheduling admin.

1

1. Resource to add: Only listed people a resource manager had already given time on this project. Project Managers had to first request resources for the project via email in order to see them here.

My Approach

How I Approached It

1. How I found the problem

• When I began looking into redesigning the resource management features, I started by interviewing my project manager, who originally built the app and was a former project manager/user, to map and understand the existing key resource workflows. (I wasn’t able to interview real users yet.)
• I also surveyed 500+ project and resource managers via email to understand the pain points they had with the resource management features. 56 responded and 34 mentioned the lack of a resource request flow.
• Finally, I dug through all the existing feedback we had on resource management, including complaints support had received and Gong calls referencing resource management features.

2. Made the case for talking to users

I used the survey data to convince stakeholders I needed direct access to users. The surveys made it clear a key workflow was missing from the app. I wanted to know how users were approaching that workflow today and what they needed from an in-app version of it. I then interviewed 5 project managers and 5 resource managers to get a clearer picture of what was needed.

3. Iterated with the team

I went through 6 iterations of the flow starting with a basic user flow to get the team aligned and working my way into mid-fidelity as the ideas matured. I reviewed each iteration with my project manager, engineers, and stakeholders to gain feedback and maintain alignment before building a high-fidelity clickable prototype.

4. Validated with new users

I used the high-fidelity prototype to run usability tests with a separate group of 5 project managers and 5 resource managers, refined the design, and handed it off to engineering.

Findings

Six Findings That Shaped the Design

1. Project managers were requesting blind

What I heard: In interviews, project managers complained about how they sent requests without being able to know what resources were actually available.

What I designed: I added an availability view inside the request flow. It shows allocated time, so project managers can see at a glance who to request before they submit.

1 2

1. Availability tags: Each person is tagged Available, Some availability or No availability for the requested dates, before anyone is requested.
2. Better matches: Similar people with more availability are suggested right below the requested ones.

2. Resource managers were juggling views and doing mental math

What I heard: In early interviews, resource managers said they wanted to see a request and the resource’s availability in the same place. The existing app made them flip between views and work out conflicts in their heads, and they didn’t want that to be true for resource requests too.

What I designed: In the calendar view, resource managers can see pending requests alongside existing allocations. The side panel shows whether a request is fully available. Clicking a request highlights it in the calendar so they can see both at the same time.

1

1. Request on the calendar: The pending request is highlighted next to the person’s existing allocations.

2 3

2. View on calendar: Jumps from a request in the side panel to the same request on the timeline.
3. Capacity check: Each request says whether it fits within the person’s capacity.

3. Vague requests created endless follow-ups

What I heard: Resource managers spent time emailing back and forth to get details missing from requests.

What I designed: I asked each resource manager for their must-have and nice-to-have details. I used those lists to decide which fields to include and which to require, then validated the fields in usability testing.

1 2 3

1. Required: groups or resources: Every request has to name a group or specific people, so resource managers know who it’s for.
2. Optional: attributes: Role, region, skills and more narrow the match without blocking the request.
3. Add attribute: Managers can add as many attributes as they need.

1 2 3

1. Required dates: Start and end dates are required, so every request has a clear timeframe.
2. Minimum allocation: Fill in a percentage, hours a day or total hours; the others update to match.
3. Optional filters: Nice-to-have details stay optional instead of blocking the request.

4. One need sometimes takes two people

What I heard: In testing, project managers asked to fill one need with two people when no single person was free for the whole timeframe.

What I designed: The final screen splits availability by person. Managers can select more than one resource, and the system automatically creates a request for each person based on when they’re available.

1 2 3 4

1. Split dates by availability: When no one is free for the whole range, ticking this splits the dates by who is free when.
2. Dates per person: Jordan covers Jan 10–12 and Marcus Jan 15–23, and anyone’s dates can still be edited.
3. Availability for their dates: Each tag updates to that person’s own dates, so Jordan is now Available.
4. Hours that add up: Each person’s total follows their dates, so the request still adds up to 20 hours.

5. Editing a request meant starting over

What I heard: During testing, project managers found updating a request painful. They wanted to be able to edit pending request instead of cancelling it and sending a new one.

The trade-off: Full editing of pending requests was going to push my engineers over capacity for the quarter so we didn’t build it in v1. I designed it anyway, and shelved it for v2.

What I did design that made it into v1: I made it so users can edit their request at the end without having to go back through all the steps.

1 2

1. Applied filters: Every earlier selection appears as a filter that can be removed with one click.
2. Edit in place: Allocation can be changed here without stepping back through the flow.

6. Newest isn’t always most urgent

What I heard: A resource manager wanted to see requests by start date rather than by when they were submitted.

What I designed: I added a sort option so users can choose their own view. I expected this preference to vary from person to person.

1

1. Start date: Sorts requests by the soonest start date instead of when they were submitted.

The Outcome

Requests now happen in the app

Project managers can now request resources in the app, and resource managers can fill those requests in the app. We estimated this cuts scheduling admin time by up to 50%.

The request flow shipped, but the rest of the resource management redesign never got built because the company was acquired and its goals changed. It’s still some of the work I’m most proud of.

Final Prototypes

The finished resource management features

Resource Management Calendar for Project Managers

Resource Planner for Resource Managers