01 - Overview
Create
Building a financial workspace for Pakistan's creator economy
Create is a financial platform designed to help creators and freelancers manage the business side of their work, from projects and invoices to payments and their wallet.
I joined Create during its early product stage and worked across the product from initial flows to an MVP-ready experience. My focus was turning complex financial workflows into simple, connected experiences that creators could understand and use with confidence.
My role
Product Designer
Timeline
12 months
Scope
8 interconnected modules, 400+ screens
Platforms
Mobile + Web
02. The Problem
Creators are speaking up. Nobody was listening.
Before Create, the workflow looked like this: agree on WhatsApp → deliver work → invent an invoice → chase payment → reconcile bank SMS → hope the math is right.
Broken journey
Brief in chat
→
Work delivered
→
Invoice DIY
→
Follow-up loop
→
Bank guesswork
→
Cash anxiety
01
No management tools
Creators run businesses without a single place to manage income, invoices, or obligations.
02
Invisible to banks
No salary slips, credit history, or formal classification c, apital is structurally blocked.
03
Payment delays & disputes
Campaign payments are fragmented and delayed. Creators chase; brands absorb admin cost.
04
WhatsApp as CRM
Briefs, revisions, and payment nagging live in the same noisy thread.
05
No financial literacy framing
Most creators don’t identify as businesses, poor money habits and tax surprises follow.
06
No local alternative
EasyPaisa/SadaPay are consumer. Walee is brand-side. Upwork is export. Domestic creators had no one.
03. Where I started
When I joined Create, the product was still in its early stages.
The team had already explored the initial concept and built an early prototype in Lovable. It helped us explore the product direction quickly, but as the scope grew, we needed a more structured experience that could support the complexity of the product.
Create wasn't simply a collection of independent features. Projects, milestones, invoices, payments, and wallet activity were connected, so a decision in one part of the product could affect another.
At the same time, we were working toward an MVP while requirements, APIs, and technical constraints were still evolving.
My role was to take those early explorations and turn them into a coherent product experience that could move toward implementation.
From exploration to implementation
Explore
Use rapid prototyping to
validate the initial product
direction.
Structure
Move the experience into
Figma and establish clearer
flows, patterns, and states.
Build
Prepare the product for
implementation across mobile
and web.
Loading…
04- Product Vision
8 interconnected modules
Projects is the spine. Everything else hangs off the same money story. Screenshot slots below are ready for the module images coming next.
Onboarding
Dashbaord
Projects
Clients
Invoices
Accounts
Calendar
Profile
05. Designing a connected financial workflow
The core challenge was understanding how all the pieces fit together.
A creator might start with a project, divide it into milestones, generate an invoice, receive a payment, and eventually see that money reflected in their wallet.
Project
→
Milestone
→
Invoice
→
Payment
→
Wallet
This meant we couldn't design each feature in isolation.
For example, approving a milestone could trigger invoice generation. Rejecting a milestone could require changes before payment could continue. A delayed or unpaid invoice could affect what the creator expected to see next.
The interface had to make these relationships understandable without requiring users to understand the underlying financial system.
Designing around states, not just screens
I started thinking about the product in terms of states and transitions rather than individual screens.
For each workflow, I considered:
·
What state is the user currently in?
·
What can they do from here?
·
What happens after they take that action?
·
What happens if something goes wrong?
·
Which other parts of the product need to reflect that change?
This became an important principle throughout the product:
Design the system behind the screen, not just the screen itself.
06. The problems we needed to solve
As the product evolved, three challenges became especially important.
01
Turning project work into a predictable payment flow
Creators don't think in terms of financial systems. They think in terms of work they have agreed to deliver and the money they expect to receive. The product needed to connect those two stories.
02
Making financial states understandable
Projects, milestones, invoices, and payments could all exist in different states. The challenge was communicating those states clearly without making the interface feel complicated.
03
Designing an MVP while the product was still evolving
We didn't have every requirement, API, or research insight available from the beginning.
We had to make informed assumptions, validate what we could, and continuously adapt the experience as the product and technical constraints became clearer.
These challenges shaped how I approached the design work.
07. Deep dive, Projects
Turning project work into a payment workflow
Projects became one of the foundations of Create.
A creator could work with a client through different payment structures, including a single payment, milestones, or recurring work.
The challenge was making these options flexible enough for different types of freelance work while keeping the experience understandable.
Starting with the creator's mental model
Instead of starting with payment terminology, I approached the flow from the creator's perspective:
What am I working on?
↓
What have I agreed to deliver?
↓
How will I get paid?
↓
What needs to happen before I receive the money?
This helped us structure the Project experience around the work itself, rather than exposing users to financial complexity too early.
08. Designing milestone states
Projects introduced another layer of complexity.
A Project have different status and these status directly effect the invoices and Payments
The biggest change wasn't simply the number of screens.
·
Projects had to connect to milestones.
·
Milestones had to connect to invoices.
·
Invoices had to connect to payments.
·
Payments had to connect to the wallet.
It was the shift from designing individual features to designing the relationships between them.
Each part needed to make sense on its own while still behaving consistently as part of the larger system.
But the happy path wasn't enough.
·
What happens when the client rejects a Project Agrement, then what the current status of the project?
·
What happens when the project due date has passed?
·
What happens when the project is in dispute ?
·
What happens when the creator needs to communicate outside the platform?
These edge cases shaped the experience as much as the primary flow.
09. Designing the Wallet
The Wallet was where the financial story came together.
A creator might have money that had been earned, money that was still pending, and money that was available to withdraw.
These states needed to be visually and conceptually distinct.
Instead of treating the wallet as simply a balance screen, I considered it as the final destination of the workflows that started elsewhere in the product.
Project
Work is created.
->
Milestone / Invoice
Payment becomes due.
->
Payment
Money is received.
->
Wallet
Money becomes available.
This relationship helped establish a consistent mental model across the product.
10. Designing for constraints
Create was being built while the underlying product infrastructure was still evolving.
That meant design decisions were sometimes constrained by APIs, third-party services, or functionality that wasn't available yet.
One example was invoice generation.
At one point, the ideal experience depended on wallet and payment infrastructure that wasn't yet available. Rather than designing an experience that could not be supported technically, we had to adapt the flow around what the product could reliably do at that stage.
A good product design has to survive contact with engineering.
The design wasn't finished when the Figma file looked right. It had to work with the actual product architecture, APIs, timelines, and implementation constraints.
12. Working across mobile and web
Create was being designed for both mobile and web, but the two experiences couldn't simply be treated as different screen sizes.
I approached the mobile experience first, then adapted the underlying patterns and workflows for larger screens.
The focus was on maintaining the same product logic while allowing the interface to take advantage of each platform.
The result was a shared product experience with platform-specific layouts and interaction patterns.
13. Collaboration and implementation
Designing the experience was only one part of the work.
I worked closely with the designer and engineering teams to move ideas from exploration into implementation.
My workflow included:
Figma
for flows, high-fidelity design, components, and prototypes.
Lovable
for rapid product exploration and early validation.
Cursor and Claude
for exploring implementation and understanding how designs could translate into working interfaces.
14. Prototype
Withdraw Money (Wallet)
Onboarding
Calendar
Clients
Profile
Invoices
14. The tradeoffs
Good product design isn't about finding a perfect solution.
It is often about deciding what matters most under the constraints you actually have.
Core-flow validation vs. design-system consistency
Early in the MVP process, we prioritized validating core workflows over perfecting every component. This allowed us to move quickly, but it also created inconsistencies as the number of screens grew. Later, I had to consolidate patterns and strengthen the design system.
Designing with assumptions vs. waiting for complete research
We didn't always have enough research to answer every question. Waiting for
perfect information would have slowed down the product, so we made explicit
assumptions, designed around them, and identified areas that needed validation later.
Ideal experience vs. available infrastructure
Some experiences depended on APIs or third-party infrastructure that wasn't ready. Instead of hiding those constraints, we adjusted the experience around what the product could reliably support at that stage.
These tradeoffs helped me understand that product design is as much about prioritization and constraints as it is about interface design.
15. What I shipped
Over 12 months, I worked across the product from early flows to an MVP-ready experience.
8 interconnected modules
Projects, Invoices, Clients, Wallet, Dashboard, Calendar, Profile, and Onboarding.
700+ screens
Across mobile and web, including primary flows, edge cases, empty states, errors, and different product states.
Mobile MVP
The mobile experience was brought to an MVP-ready state across the core product modules.
Web experience
The desktop experience was developed alongside the mobile product, with the core experience progressing toward implementation.
Design system
Reusable components and patterns were established and scaled as the product grew.
Implementation
I worked through design QA, Dev Mode, technical constraints, and implementation details with engineering.
Add any real product metrics, beta-user numbers, adoption data, usability results, or implementation milestones here if you can disclose them.
16.The outcomes
Proof of Concept, then Open beta
A sprint-based Closed beta validated the core product feature before wider lauch. Numbers below are from that january 2026 POC, not projected revenue.
31
Freelancer
92
Project Created
PKR 3.27M+
Project value
outcomes
Some need time tracker , Some need personal assestnant , some need differnet creteria wit differnt approch and scope .
16.The outcomes
Close beta
A sprint-based Closed beta validated the core product feature before wider lauch. Numbers below are from that january 2026 POC, not projected revenue.
31
Freelancer
92
Project Created
PKR 3.27M+
Project value
16.The outcomes
Maxpanled.com
flow valideations
Feedabck
Project , client , onbaording
Finacing , Forree , usability ,
1. Beta 32 freealceer interacitonal are the wrong Audience - wrong actiong
2. 32 Local pakistani Content Creators - Wrong Actiong
Validation of flows
32
Downlaod
92
Project Created
PKR 3.27M+
Project value
17. Reflection