Back to Home
Marketplace
Mobile App
B2B SaaS
ROLE
Product Designer
TIMELINE
7 months
TEAM
PM/PO · Product Designer · Tech Lead · Frontend Engineer
TOOLS
Figma, Figjam
5 → 1.5 days
Company request to reservation
0 → 1
Branches decongested with app design
40+
Companies posting jobs through Tasky

THREE COUNTRIES WERE BECOMING THREE DIFFERENT PRODUCTS
Serhafen manages customs and delivery operations in Chile, Peru, and Argentina for high-volume e-commerce shipments.
Their internal platform was originally designed around Chile. As the company expanded, Peru developed as an independent workflow and Argentina was moving in the same direction.
But there was a bigger problem: no one had mapped the end-to-end operation.
Operations, Commercial, and Management departments each understood their part of the service, but there was no shared vision connecting customs, warehouses, airlines, delivery providers, service level agreements (SLAs), and the supporting systems.
Without that model, each new country risked becoming an independent product.

The manual workflow created a chain reaction.
Company requests took up to five days to move from first contact to reservation payment. KAMs spent time coordinating information manually, while delayed company payments could also delay Tasker payments.
That affected the student side too. When there were not enough active Taskers in the app, Operations returned to WhatsApp and social media to fill jobs, reinforcing the same manual process.
The opportunity was bigger than redesigning the existing interfaces.
Tasky needed to structure the operation behind the marketplace first, then move the parts companies could manage themselves into a B2B product.


01
Map the operation behind the Marketplace
Before redesigning the products, I mapped how a job actually moved through Tasky, from the first company request to student assignment and payment.
The Service Blueprint connected the workflows of companies, KAMs, Finance, and Taskers and exposed where the operation was leaving the product.
One dependency stood out: payment.
Companies often required purchase orders and internal approvals before paying Tasky. When that process was delayed, Tasky could not pay Taskers on time, turning what looked like a finance problem into a marketplace problem.

Service Blueprint - end-to-end service
What changed
We made payment confirmation part of the Task lifecycle.
A company could confirm a Task and upload its payment information. Finance could validate it before the Task became active.
This created a clearer operational state for everyone involved:
Company confirms Task→ Payment submitted→ Finance validates→ Task activated→ Taskers assigned
Instead of treating payment as something happening outside the product, it became part of the workflow the product needed to support.

02
Turn the manual workflow into internal software
Before companies could manage more of the process themselves, Tasky needed a better way to run the operation internally.
I redesigned the KAM platform around the core objects the team was already managing manually.
KAMs could now:


Designing around the task lifecycle
The key change was treating a Task as an operational object with a clear lifecycle rather than information scattered across conversations and manual coordination.
Company requirements could be structured when the Task was created and then carried through the rest of the workflow.
That reduced repeated coordination and gave KAMs one place to manage the job from request through reservation.
Outcome

The average cycle from a company’s first request to reservation payment dropped from approximately five days to 1.5 days after the new KAM workflow was introduced.
The KPI was tracked inside the KAM platform and validated against the team’s operational experience.

03
Move from managed service to B2B self-service
The PM/PO had already identified an opportunity to let companies manage jobs directly instead of routing every request through Tasky.
My role was to turn that idea into a product.
I mapped what companies needed to manage independently, defined the navigation and product structure, and designed the B2B SaaS end-to-end.


What companies could now manage

Companies could define headcount, schedules, locations, requirements, and other job details directly in the platform.

Companies could review and select Taskers for a job or preselect specific people before publishing it to the wider marketplace.

For jobs requiring preparation, companies could define training dates and schedules as part of the workflow.

The product structure accounted for companies operating across different offices or work locations rather than treating every Task as an isolated request.

Companies could confirm the Task and submit payment information for Finance to validate before activation.
This moved critical parts of the workflow from calls and WhatsApp conversations into a structured product companies could increasingly operate themselves.

We deliberately kept financial management outside the initial B2B scope.
A complete Finance area for managing Tasker payments would have added another layer of operational complexity before the core company workflow was established.
The priority was getting the essential loop right:
Create Task→ Configure requirements→ Select Taskers→ Confirm reservation→ Activate Task
Designing with a small team
I was Tasky’s only designer, working directly with the PM/PO and Tech Lead.
Rather than spend time building a proprietary component library, I standardized the new interfaces around shadcn/ui. That gave design and frontend a shared foundation and let us spend more of the project on workflows and product behavior instead of rebuilding common UI patterns.
Across the rest of the marketplace
The same product direction extended to the student experience.
I redesigned the B2C mobile app and public website to create a more consistent path between companies publishing opportunities and students discovering and applying to them.
I would not attach an engagement metric to this work. Student growth also coincided with increased marketing and acquisition activity, so the available evidence does not isolate the effect of the redesign.


Reduced the company request-to-reservation cycle after structuring the internal KAM workflow.

Turned the PM/PO’s self-service concept into a complete product structure and interface that allowed companies to create and manage jobs directly.

More than 40 companies published jobs through Tasky, with approximately 20 operating as recurring company customers.

Connected company requests, Tasks, Taskers, payment confirmation, KAM operations, and the student marketplace into a clearer product model.
All Projects
Next Project
Message me on LinkedIn
Send an Email
Back to Home
Marketplace
Mobile App
B2B SaaS
ROLE
Product Designer
ROLE
7 months
ROLE
PM/PO · Product Designer · Tech Lead · Frontend Engineer
TOOLS
Figma, Figjam
5 → 1.5 days
Company request to reservation
0 → 1
Branches decongested with app design
40+
Companies posting jobs through Tasky

THREE COUNTRIES WERE BECOMING THREE DIFFERENT PRODUCTS
Serhafen manages customs and delivery operations in Chile, Peru, and Argentina for high-volume e-commerce shipments.
Their internal platform was originally designed around Chile. As the company expanded, Peru developed as an independent workflow and Argentina was moving in the same direction.
But there was a bigger problem: no one had mapped the end-to-end operation.
Operations, Commercial, and Management departments each understood their part of the service, but there was no shared vision connecting customs, warehouses, airlines, delivery providers, service level agreements (SLAs), and the supporting systems.
Without that model, each new country risked becoming an independent product.

The manual workflow created a chain reaction.
Company requests took up to five days to move from first contact to reservation payment. KAMs spent time coordinating information manually, while delayed company payments could also delay Tasker payments.
That affected the student side too. When there were not enough active Taskers in the app, Operations returned to WhatsApp and social media to fill jobs, reinforcing the same manual process.
The opportunity was bigger than redesigning the existing interfaces.
Tasky needed to structure the operation behind the marketplace first, then move the parts companies could manage themselves into a B2B product.


01
Map the operation behind the Marketplace
Before redesigning the products, I mapped how a job actually moved through Tasky, from the first company request to student assignment and payment.
The Service Blueprint connected the workflows of companies, KAMs, Finance, and Taskers and exposed where the operation was leaving the product.
One dependency stood out: payment.
Companies often required purchase orders and internal approvals before paying Tasky. When that process was delayed, Tasky could not pay Taskers on time, turning what looked like a finance problem into a marketplace problem.

Service Blueprint - end-to-end service
What changed
We made payment confirmation part of the Task lifecycle.
A company could confirm a Task and upload its payment information. Finance could validate it before the Task became active.
This created a clearer operational state for everyone involved:
Company confirms Task→ Payment submitted→ Finance validates→ Task activated→ Taskers assigned
Instead of treating payment as something happening outside the product, it became part of the workflow the product needed to support.

02
Turn the manual workflow into internal software
Before companies could manage more of the process themselves, Tasky needed a better way to run the operation internally.
I redesigned the KAM platform around the core objects the team was already managing manually.
KAMs could now:


Designing around the task lifecycle
The key change was treating a Task as an operational object with a clear lifecycle rather than information scattered across conversations and manual coordination.
Company requirements could be structured when the Task was created and then carried through the rest of the workflow.
That reduced repeated coordination and gave KAMs one place to manage the job from request through reservation.
Outcome

The average cycle from a company’s first request to reservation payment dropped from approximately five days to 1.5 days after the new KAM workflow was introduced.
The KPI was tracked inside the KAM platform and validated against the team’s operational experience.

03
Move from managed service to B2B self-service
The PM/PO had already identified an opportunity to let companies manage jobs directly instead of routing every request through Tasky.
My role was to turn that idea into a product.
I mapped what companies needed to manage independently, defined the navigation and product structure, and designed the B2B SaaS end-to-end.


What companies could now manage

Companies could define headcount, schedules, locations, requirements, and other job details directly in the platform.

Companies could review and select Taskers for a job or preselect specific people before publishing it to the wider marketplace.

For jobs requiring preparation, companies could define training dates and schedules as part of the workflow.

The product structure accounted for companies operating across different offices or work locations rather than treating every Task as an isolated request.

Companies could confirm the Task and submit payment information for Finance to validate before activation.
This moved critical parts of the workflow from calls and WhatsApp conversations into a structured product companies could increasingly operate themselves.

We deliberately kept financial management outside the initial B2B scope.
A complete Finance area for managing Tasker payments would have added another layer of operational complexity before the core company workflow was established.
The priority was getting the essential loop right:
Create Task→ Configure requirements→ Select Taskers→ Confirm reservation→ Activate Task
Designing with a small team
I was Tasky’s only designer, working directly with the PM/PO and Tech Lead.
Rather than spend time building a proprietary component library, I standardized the new interfaces around shadcn/ui. That gave design and frontend a shared foundation and let us spend more of the project on workflows and product behavior instead of rebuilding common UI patterns.
Across the rest of the marketplace
The same product direction extended to the student experience.
I redesigned the B2C mobile app and public website to create a more consistent path between companies publishing opportunities and students discovering and applying to them.
I would not attach an engagement metric to this work. Student growth also coincided with increased marketing and acquisition activity, so the available evidence does not isolate the effect of the redesign.


Reduced the company request-to-reservation cycle after structuring the internal KAM workflow.

Turned the PM/PO’s self-service concept into a complete product structure and interface that allowed companies to create and manage jobs directly.

More than 40 companies published jobs through Tasky, with approximately 20 operating as recurring company customers.

Connected company requests, Tasks, Taskers, payment confirmation, KAM operations, and the student marketplace into a clearer product model.
All Projects
Next Project
Message me on LinkedIn
Send an Email
Back to Home
Marketplace
Mobile App
B2B SaaS
ROLE
Product Designer
TIMELINE
7 months
TEAM
PM/PO · Product Designer · Tech Lead · Frontend Engineer
TOOLS
Figma, Figjam
5 → 1.5 days
Company request to reservation
40+
Companies posting jobs through Tasky
0 → 1
B2B self-service platform

Tasky connects companies with students looking for flexible work. The product existed, but much of the operation behind it was still manual.
When a company needed students, the process started with a call or WhatsApp message. KAMs collected requirements such as headcount, locations, schedules, and protocols, then created and coordinated the job internally.
Finding students was also happening outside the product. Because the app had a limited pool of active users, Tasky repeatedly contacted previous Taskers through WhatsApp or recruited through Instagram and social media. Once students were found, they were asked to apply through the app so the team could continue managing the job internally.
A digital marketplace existed on the surface. Underneath, Tasky was still operating much of it as a managed service.

The manual workflow created a chain reaction.
Company requests took up to five days to move from first contact to reservation payment. KAMs spent time coordinating information manually, while delayed company payments could also delay Tasker payments.
That affected the student side too. When there were not enough active Taskers in the app, Operations returned to WhatsApp and social media to fill jobs, reinforcing the same manual process.
The opportunity was bigger than redesigning the existing interfaces.
Tasky needed to structure the operation behind the marketplace first, then move the parts companies could manage themselves into a B2B product.


01
Map the operation behind the Marketplace
Before redesigning the products, I mapped how a job actually moved through Tasky, from the first company request to student assignment and payment.
The Service Blueprint connected the workflows of companies, KAMs, Finance, and Taskers and exposed where the operation was leaving the product.
One dependency stood out: payment.
Companies often required purchase orders and internal approvals before paying Tasky. When that process was delayed, Tasky could not pay Taskers on time, turning what looked like a finance problem into a marketplace problem.

Service Blueprint - end-to-end service
What changed
We made payment confirmation part of the Task lifecycle.
A company could confirm a Task and upload its payment information. Finance could validate it before the Task became active.
This created a clearer operational state for everyone involved:
Company confirms Task→ Payment submitted→ Finance validates→ Task activated→ Taskers assigned
Instead of treating payment as something happening outside the product, it became part of the workflow the product needed to support.

02
Turn the manual workflow into internal software
Before companies could manage more of the process themselves, Tasky needed a better way to run the operation internally.
I redesigned the KAM platform around the core objects the team was already managing manually.
KAMs could now:


Designing around the task lifecycle
The key change was treating a Task as an operational object with a clear lifecycle rather than information scattered across conversations and manual coordination.
Company requirements could be structured when the Task was created and then carried through the rest of the workflow.
That reduced repeated coordination and gave KAMs one place to manage the job from request through reservation.
Outcome

The average cycle from a company’s first request to reservation payment dropped from approximately five days to 1.5 days after the new KAM workflow was introduced.
The KPI was tracked inside the KAM platform and validated against the team’s operational experience.

03
Move from managed service to B2B self-service
The PM/PO had already identified an opportunity to let companies manage jobs directly instead of routing every request through Tasky.
My role was to turn that idea into a product.
I mapped what companies needed to manage independently, defined the navigation and product structure, and designed the B2B SaaS end-to-end.


What companies could now manage

Companies could define headcount, schedules, locations, requirements, and other job details directly in the platform.

Companies could review and select Taskers for a job or preselect specific people before publishing it to the wider marketplace.

For jobs requiring preparation, companies could define training dates and schedules as part of the workflow.

The product structure accounted for companies operating across different offices or work locations rather than treating every Task as an isolated request.

Companies could confirm the Task and submit payment information for Finance to validate before activation.
This moved critical parts of the workflow from calls and WhatsApp conversations into a structured product companies could increasingly operate themselves.

We deliberately kept financial management outside the initial B2B scope.
A complete Finance area for managing Tasker payments would have added another layer of operational complexity before the core company workflow was established.
The priority was getting the essential loop right:
Create Task→ Configure requirements→ Select Taskers→ Confirm reservation→ Activate Task
Designing with a small team
I was Tasky’s only designer, working directly with the PM/PO and Tech Lead.
Rather than spend time building a proprietary component library, I standardized the new interfaces around shadcn/ui. That gave design and frontend a shared foundation and let us spend more of the project on workflows and product behavior instead of rebuilding common UI patterns.
Across the rest of the marketplace
The same product direction extended to the student experience.
I redesigned the B2C mobile app and public website to create a more consistent path between companies publishing opportunities and students discovering and applying to them.
I would not attach an engagement metric to this work. Student growth also coincided with increased marketing and acquisition activity, so the available evidence does not isolate the effect of the redesign.


Reduced the company request-to-reservation cycle after structuring the internal KAM workflow.

Turned the PM/PO’s self-service concept into a complete product structure and interface that allowed companies to create and manage jobs directly.

More than 40 companies published jobs through Tasky, with approximately 20 operating as recurring company customers.

Connected company requests, Tasks, Taskers, payment confirmation, KAM operations, and the student marketplace into a clearer product model.
All Projects
Next Project
Message me on LinkedIn
Send an Email