Case studyMarketplace Web · B2BLead Designer19 months

goLance: the money and the people

A freelance marketplace where companies could not see their contractors or their money. I led design on the company management module, rebuilt the navigation, and built the design system.

Product

goLance, a global freelance marketplace. Competing with Upwork, Fiverr and Freelancer

My role

Lead Product Designer.
Team: 3 designers, 2 BA, 2 PM, 4 FE, 6 BE, 2 QA

Timeline

19 months,
2021—2023

Scope

2,000+ unique frames and states. Platform grew from 600K to 1M users in that period

29%

of companies use the dashboard weekly — 37% among those running several contracts at once

Amplitude · 3 months after launch

−24%

support tickets about finding financial reports and payments

Support tickets · 3 months after launch

72→82%

task success rate on the key flows in usability testing

2 rounds · 8 participants

The problem

goLance competed with Upwork and Fiverr for the same customer: a company that hires a team rather than one freelancer. It kept losing them at the same point. Once a company had signed a few contracts, it had no way to see its own people or its own spending.

Matching a client with a freelancer worked well. Everything after the hire did not. Who is working on what, how much we spent this month, where the contract is: all of it sat in tables spread across different sections. A company with twenty contractors was using an interface built for someone with one.

No company management

You could not create separate profiles for a freelancer, an agency and a company. There was no hierarchy at all. A company was just a user with a lot of contracts.

No financial control

There were no tools for tracking transactions. The question every client asked first, how much do I have and where did it go, had no answer anywhere in the interface.

Navigation built for the system

Duplicate links, pages doing the same job, section names taken from how the product was built. New users got lost, and they told us so.

Data you could not read

To understand where a project stood you had to visit four screens and assemble the picture yourself. The tables showed rows. They did not help anyone decide anything.

What clients actually told us

The platform had a big and fairly loud community, so we did not have to guess much. We talked to people who ran into this every day and read what they sent to support.

Why is it so hard to get a financial report? I spend most of my time just looking for the numbers.

Rajesh K. · client

I can't track what my freelancers are doing, and I keep making mistakes when I add them or change their roles.

Ethan R. · client

I can't find the documents I need. Everything gets lost between too many tabs.

Elena H. · client

What I did, and what the team did

There were three designers on this project. Here is where my work ended and theirs began, because without that line a case study says nothing.

Mine

Direction. I owned what the company module became. Structure, priorities, what shipped first, what never shipped.
The hard parts. I kept the pieces I could not hand off: the roles and permissions model, the finance section, the navigation map for the whole platform.
Research. Competitor teardowns of Upwork, Fiverr and Freelancer. Client interviews. Reading support tickets. Usability testing on prototypes.
Design system. Built it from zero. Components, states, documentation.
Review and delegation. Split the work across three designers, reviewed what came back, kept one quality bar.
Selling the work. Defended decisions to PMs, BAs and the client. Argued when I disagreed with them.

The team

2 designers — screens against the agreed direction, states, responsive layouts, keeping the library in order.
2 business analysts — requirements, business logic, documentation.
2 product managers — priorities, timelines, talking to the client.
4 frontend, 6 backend, 2 QA — implementation. I reviewed the front-end work myself.

Constraints

A live marketplace moving real money is not a blank canvas. The walls we had:

No hard deadline, but time cost money

Nobody set a date. But every week without company management was another week clients spent on Upwork. Speed was never written down as a requirement. It came up in every scoping call anyway.

Don't break what works

Hundreds of thousands of users and real payments moving through the product. The new module had to fit into a live system without breaking the flows people already depended on.

Four frontend developers, 2,000+ frames

Engineering was the bottleneck. So we queued the work by what would pay off first, which is not the same as what we wanted most.

We had data — and used it

Amplitude for behaviour, funnels and navigation paths, plus internal analytics and support tickets. What we never did was agree on a success metric before starting. That was a mistake and I come back to it at the end.

The calls I made, and what they cost

Three forks where this project could have gone the other way.

Decision 01

Extend the tables we already had — or build a dashboard?

Clients asked for "freelancer management". We already had contract tables, so adding filters and roles to them was fast, cheap and close to risk-free. Building a management hub from scratch was slow, expensive, and could easily miss what people actually needed.

✓ What I chose

A dashboard as the company's home

The interviews kept pointing away from search. Clients were not opening the platform to find one contract. They opened it in the morning to check that nothing was on fire. You cannot filter a table into that answer. So we built a summary: team, money and contracts on one screen, with the buttons sitting next to the thing that makes you press them.

✕ What I rejected

Filters and roles bolted onto the old tables

Two sprints, and everyone stays where they were: go and find it yourself. The duplicate links people complained about were a symptom. The structure underneath was the actual problem.

What it cost

Speed, mostly. The cheap version would have shipped months earlier and clients would have had something in their hands. It also cost us consistency. We rolled out in stages, so the old tables and the new dashboard sat side by side for a while, and for several months there were two ways to look at the same data. Not great. Still better than making a million users relearn the product in one release.

How I checked

Two rounds of usability testing with 8 people: business owners, company admins, team managers. All of it on the prototype, before engineering touched anything.

Why this way

The structure follows the question a client walks in with every morning. That is why the overview sits at the top, and team, finance and contracts became tabs of one object instead of separate corners of the platform.

Decision 02

Who inside a company is allowed to see the money?

Once a company has twenty contractors, access stops being a detail. Show the balance to everybody and you have a leak, plus arguments inside the client's own team. Show it only to the owner and the owner has to approve every small thing.

✓ What I chose

Teams with a manager on limited rights

Contractors sit in teams, grouped by profession or project. Each team has a manager who sees their team's contracts and work but not the company balance. The owner sees all of it. One model covered two separate complaints, which is why I went with it.

✕ What I rejected

A flat list and one role for everybody

Easier to build, and fine for a company with three people. It breaks down exactly where our target customer begins. Twenty names in a flat list is not management.

What it cost

Simplicity. A permissions matrix means a lot more states, a lot more QA, and a longer build. Small companies also got a mechanism they never asked for, so the interface had to fall back to a plain list when there were only a few people.

How I checked

We ran the main scenarios for all four roles: Owner, Admin, Team Manager, Member. The question was not whether it looked right. It was whether each person saw what they should and nothing else.

Decision 03

We could have left the navigation alone. We rewrote it.

New features do not help if people cannot reach the old ones. Users complained about duplicate links, pages doing the same job, and a long walk to their reports. Rewriting navigation on a live marketplace is risky though. People have already learned the old one, and you pay for the change in confusion and support tickets.

✓ What I chose

A menu built around the user's job, not the system's shape

Split by role: client and freelancer. Money in one place instead of three. Labels written as actions, "View contracts" and "Manage payment methods" rather than "Finance" and "Billing". The two things people actually come for, money and access to work, went in the middle.

✕ What I rejected

Cosmetics: remove the duplicates, keep the structure

Quick and safe. But the structure copied how the system was built, and it would have stayed that way. The duplicates would have grown back within a year.

What it cost

Habit. Everyone who already knew the product had to relearn part of it, and you always pay for that. We softened it with a staged rollout, both menus running in parallel for a while, and keeping the old names on the sections people used most often.

How I checked

The same usability sessions covered the menu. The first version did not pass. People could not find things, so I regrouped several items and we tested again.

The work

Company dashboard

Why this way

The balance goes first because money was the loudest complaint, louder than the people problem. Actions sit next to the data that causes them: you see a contract about to expire and you extend it there, without walking to another section. The screen is meant to answer "is everything fine" before anyone clicks anything.

Money: contracts, jobs, transactions

Why this way

The contract table shows the fields people actually decide on: who, when, how much, what state. Transactions export to a file, because clients were re-entering them in their own accounting software anyway. We were never going to build accounting properly, and pretending otherwise would have cost us a quarter.

Design system

Built from zero, and not just for this module. Every component was drawn in all of its states: default, hover, disabled, focus, pressed, loading. Most of the work in a component library sits in the states, not in the screen where everything goes right.

components in the library, each one with its full set of states

other client products reused the system, changing only the styles

designers worked in one library without it drifting apart

Why this counts

Two other products at the client picked the system up and only had to swap the styles. That is the real test for a library, and it passed it.

Results

Numbers from Amplitude and support tickets, three months after launch. The usability figures come from two rounds of testing with 8 participants.

Dashboard adoption

Share of companies opening it at least once a week

29%

All companies

37%

Several active
contracts

Amplitude · 3 months after launch

Usability testing

Task success rate on the key flows

72%

Round 1

82%

After changes

2 rounds · 8 participants · time on task −20%

Navigation depth

Average clicks to Finance, Contracts and Members

3.2

Before

2.7

After

Amplitude · time to section −23% · back-navigation −18%

Support tickets

Requests about finding reports and payments

100%

Before launch

−24%

After

Support tickets · 3 months after launch

What I won't claim as a win

Three-month retention for companies went from 66% to 68%. Two points. Over three months that could be seasonality, marketing, or one of the other releases, and I am not going to pretend design did it. What is interesting is that most of the increase sat with companies that actually used the dashboard. That is a hypothesis, not proof. It is what I would have tested next.

One result no metric really captures: two other products at the client took the 40-component system and changed nothing but the styles.

What I'd do differently

The mistake worth naming

My first navigation followed the logic of the product: how the system was built. It looked clean on paper and from the inside it felt right. Then we tested it, and people could not find anything, because they were looking where they expected things to be rather than where we had filed them. I redid the information architecture and regrouped the menu. It is obvious in hindsight. It was not obvious at the time, and that is the part worth writing down.

We should have agreed on the metric first

We had Amplitude the whole time. What we never did was agree, before the work started, on the number that would tell us the module had worked. So some of the impact had to be reconstructed afterwards, which is a bad way to work. Now I settle the success metric with the PM before I open Figma.

Where AI would fit today

There was no AI in my process on goLance. It was not part of how I worked then. It would be now: synthesising eight interviews took weeks by hand and would take hours today, and the same goes for component states and first drafts of interface copy. The decisions above are a different matter. What to build, what to cut, what to trade away, that part stays with me. AI is fast at producing things and bad at choosing what to give up.