Team: Myself and a Product Manager
Duration: About 2 months interspersed with other projects
My Role: UX/UI Design, Prototyping, Research
Tools: Figma, FigJam
PROJECT OVERVIEW
TaskEasy is a B2B marketplace that connects large-scale rental property owners with a nationwide network of 20,000+ service providers.
I worked on the Contractor-facing products. Our users were small, independent local service contractors representing an average of 2 work crews. My main focus was the comprehensive redesign of the Contractor Web Portal and Mobile Application.
For the mobile app, I focused on user pain points, modernizing the interface, and improving usability and accessibility. This case study covers one user journey called Cannot Complete.
The flow allows contractors to mark a job on their schedule as "cannot complete" and explain why by selecting from a pre-determined list of reasons and adding photos and notes.
The redesigned Cannot Complete workflow successfully transformed an underutilized feature into a valuable tool providing the following outcomes:
• Achieved an increase in revenue by enabling faster job completion
• Improved client relations, as job-related issues and delays are communicated promptly
• Streamlined contractor experience, removing jobs from their schedules and improving completion rates
• Empowered support teams to resolve issues in real-time
THE PROBLEM
After interviewing contractors, the following end-user problems were identified:
• Jobs remain on the schedule after being marked as "Cannot Complete"
• The pre-determined list of reasons did not adequately cover their needs
• The required documentation was not specific to each reason selected, which didn't accurately represent the reality of the issue
The existing Cannot Complete flow also failed to address the following business problems:
• Jobs remaining on the schedule prevented timely reassignment to new contractors
• Clients were not accurately informed of issues preventing work from being done
• Operation teams were often unaware of problems, leading to repeated reassignments without resolution
UNDERSTANDING THE REQUIREMENTS
A deep analysis was performed with cross-functional teams, leading to a more complete list of reasons to include. A spreadsheet was developed as a starting point to understand what data requirements each reason necessitated.
Once we understood the business needs, we met with engineering to understand the technical requirements to fulfill those needs.
We identified the following list of backend requirements:
• Utilize SalesForce and cases to manage outputs from this flow
• Update and refine case architecture in SalesForce to connect each case with the correct team
• Define how to implement if/then logic to accommodate varying job requirements based on customer specifications
MAPPING THE USER FLOW OUTCOMES
The product manager and I created a decision tree matrix in FigJam to visually communicate workflows to stakeholders. This allowed us to garner feedback efficiently while communicating expected outcomes to engineering.
The decision tree for "No work required"
I had the initial design from the original Cannot Complete flow, but I needed to make it more robust. To achieve this, I utilized a series of components from our design system that would or would not display based on the decision tree logic.
The conditional logic builds the UI as you answer questions in the workflow.
For Example, if you can cut the lock, the next step in the flow will display the message, "Great! Please cut the lock and complete the job as usual." If you cannot cut the lock, the system will guide you to the next step in the flow and ask another question.
A series of collaborative meetings with stakeholders and engineering ensured the prototype matched expected business outcomes.
The results were:
• Stakeholders visually confirmed the conditional logic performed as expected
• Implemented feedback gathered about the UIs
• Updated the decision tree matrix to account for adjustments made by stakeholders
• Engineering weighed in on the best implementation strategies
TESTING OUTCOMES
Throughout the testing phase, we found areas where we could remove some scope from the initial release.
This allowed a faster go-to-market timeline while meeting end-user needs and accomplishing business objectives.
Below is an example of a feature we removed for V1:
In the "Work-Stopping Debris on Site" workflow, I included an additional bid creation feature allowing contractors to submit a bid for debris removal. After considering the additional scope required to develop this new feature, we concluded that saving it for a future release would be better.
The Submit Bid Flow
FINAL THOUGHTS
The redesigned "Cannot Complete" workflow transformed a feature that made little to no impact on either users or the business into a powerful tool. Not only did it add value to the user, but it also helped our business increase revenue, better communicate with clients, and resolve issues efficiently.
Collaborating closely with stakeholders and engineers streamlined the process and ensured I met all business needs while addressing user concerns.