CONTEXT
A multi-sided marketplace connecting customers across Norway with independent tailors for repair and alteration. I owned the design direction for three roles in one ecosystem: customer, tailor and admin. I designed for a national network with pickup points established in Oslo, Stavanger and Kristiansand.
Mendi had paying customers throughout the redesign. The work below was done against a product in operation, with live orders moving through it while the new platform was built alongside.
CHALLENGES
When the company's capacity tightened I took over scope and priorities and stepped in as interim CEO. In that role I released 250,000 NOK in grant funding — 200,000 from Innovation Norway and 50,000 from Western Norway University of Applied Sciences — which kept the rebrand moving through financial constraints.
The development team was replaced twice, so the design work had to be documented well enough to stand on its own through each handover.
Customer, tailor and admin in one ecosystem. Different information at different times, in one architecture.
The development team was replaced twice, so the design work had to be documented well enough to stand on its own through each handover.
Lookup for an order in the admin dashboard, after I rebuilt it against the new database.
Insights
The brief I was given, and the brief I took
The CPO asked for a screen redesign. I started by testing the platform myself, with both a customer and a tailor account: placed an order as a customer, followed it as a tailor, and back to the customer again and following the flow from the admin dashboard.
Functional and security testing ran over several rounds, and I documented the findings for the development team in a flow diagram covering the whole platform. Alongside that I followed the feedback coming in continuously through a Slack channel with the tailor network and by email to customer service.
The problem sat somewhere other than the screens.
– THREE PATTERNs
Tailor side
On the tailor side, the flow depended on admin at every step. Assignments were filtered by postcode and shown to the nearest tailor, but tailors could not change their own postcode and got no notification when something became available. So admin handed jobs out manually. Once the tailor saw the assignment, they were still missing details to properly assess it. After accepting the assignment, the tailor had to contact customer service again to get the full assignment description.
Customer side
On the customer side there was a trust barrier. Customers chose the pickup point because it was the free option, but the same uncertainty came back in the Slack channel and in emails to support: they were reluctant to leave valuable garments without a receipt confirming that the garment was safely registered in the service.
Authentication
At authentication I found a critical stop. Users could not get into their own account to follow their order and update the status. I set authentication as the first priority ahead of all new build. Customers could not reach their own order, so nothing we built on top of that would be used. Attempts to fix it in the existing codebase did not hold, which is what led to decision 04 below.
The real problem was trust, in both directions, and admin was compensating for it by hand. I took that back to the CPO and CEO, and we agreed to expand the brief from screen redesign to flow work. The insights I gathered changed the scope of the project.
information architecture
For three roles
The old platform showed roughly the same thing to everyone, regardless of role and regardless of where in the flow the user was. Information belongs where the decision is made, and the three roles make different decisions at different moments.
Tailor
Needs the full picture before accepting a job: where the garment is, what needs doing, and what the customer expects.
Customer
Needs confirmation along the way: where the garment is, what happens now, and who they should talk to.
six decisions
01
20 % platform fee, up from 15
02
A new data foundation rather than a migration
03
A new admin dashboard, built in Retool AI
04
New authentication on Stripe Connect
05
All order information in one view
06
Direct dialogue between customer and tailor
They arrange delivery and collection between themselves, independent of pickup points. That meets the trust barrier where it arises.
business acumen
What the decisions mean for the business
SCALABILITY
Orders can grow without headcount following. Two manual actions per order fall away, and a small team gets that time back for the platform and the tailor network.
Revenue
Free pricing with a minimum as the floor opens up higher-value work such as bunad (national costume) repair and furniture textiles. Higher order value goes straight to revenue, and the minimum holds the price level up in the market.
unit economics
Payouts to tailors go automatically through Stripe Connect. Cost per order stays flat while volume grows.
Measurability
The measurement points are defined before the first order comes in. The team can follow the numbers from week one after launch and fix what stalls while a change is still cheap.
Specialisation
Customers can request quotes for work outside the service menu, and tailors can show previous work. The expertise already in the network becomes visible where the customer chooses.
Growth direction
Stripe Connect lets tailors sell their own garments through the same setup. Users can pull the product in new directions before a development cycle is started.
COLLABORATION
Delivering to three different teams
The development team was replaced twice. Each team built from its own preferred structure.
Between team 2 and team 3 we went a period without developers while orders kept moving through the old platform. A senior consultant reviewed the codebase and found it costly to work in. I gave a prospective team access to the stack so they could judge for themselves, and coordinated with the outgoing team myself, but getting there took longer than the answer was worth. Rather than keep spending time on understanding the old code, we rebuilt authentication and payment on Stripe Connect.
The lesson was to find out what foundation each team actually builds from, and deliver exactly that.
team 1
Worked from the component library I built in Figma. Their estimate for the order and payment flow came back at 300 hours. An independent read put it at 30. I took both numbers to the CEO and we changed direction.
team 2
Wanted the system to live in the code, so we moved to shadcn. Two internal hackathons took the order flow from sketch to near-complete, with timeboxing turning prioritisation into delivered progress.
AI moved the time and the risk
With Figma Make I came to the engineers with a working flow where I previously had static screens, so the discussion became concrete before anyone wrote production code. I built the admin dashboard myself in Retool AI against the database, relieving the development team of work that would otherwise have taken weeks.
deciding what not to build
The tracking I stopped
Customers wanted a receipt for the garments they sent. I built a tracking feature as a testable app in Databutton in three hours, without a developer, and tested it with potential customers.
They found it useful. I stopped it anyway. Tracking assumed someone registered the garment when it arrived at the pickup point. Some pickup points already did this, unprompted, and reported it to customer service. Others had no capacity. Without staffing settled, tracking would have shown nothing in exactly the cases where the customer was most uncertain.
Three hours let me test early, and learn that the question sat elsewhere: trust was failing in the information users were given, not in the absence of tracking.
In the new platform, tracking lives in the shared thread between customer and tailor. Both update status with one tap and can add a detail where it is needed. Customer and tailor see the status, the message and the assignment in the same place. Tracking became part of the dialogue they needed, rather than a separate tool to learn.
PICK THE RIGHT TOOL
I pick the tool according to what the decision requires: a testable app when the question is whether users understand the flow, a working prototype when the question is whether I share the same understanding as engineering. The question of what should be built comes before both.
– TRACKING IN THE DIALOGUE
The same order, seen by customer and tailor. Status, message and assignment sit in one thread, so tracking is part of the dialogue rather than a separate tool.
FROM TEST FINDING TO DELIVERED SOLUTION
Plain language when the question occurs
Mendi's promise was a platform by and for tailors, and overview was what they needed most. Production testing was meant to answer whether the new platform kept that promise. I ran it myself, in qualitative interviews where tailors shared their screen so I could see where they stopped.
Four of five tailors stopped when the form asked for an IBAN — even with a test IBAN pre‑filled. The ask itself was the blocker: they never remember where the number lives, and being asked for it feels stressful. The form asked for the most sensitive detail without explaining why or how to find it.
I kept IBAN in registration because payouts run through Stripe Connect — tailors need a working payout account before their first paid order. Moving it later would interrupt shop setup instead. So I answered both questions in place: three short steps, the reason stated in the payment step, and a guide to finding the number next to the field. I prototyped it in Figma Make; the developer implemented it directly. The relaunch will show whether it works: the share of tailors who publish a shop within seven days.
Shop and service setup I moved out of onboarding and into the dashboard. It was too much to take a position on before tailors had seen the product, and it was blocking registration. At the same time they needed help getting started, so recommended price ranges, delivery options and ready-written service descriptions sit where the choice is made, ready to copy and make their own.
A strategic cut
Shipping: unprioritized
Delivery was where tailors were least certain. The shipping options cost 160 NOK return regardless of distance, so customers chose the free pickup point, and the cost landed on the tailor without being covered in the price.
An integration with the shipping provider would have solved it, but the cost didn't work in any version of the model we looked at. I deferred it. Instead, the new platform lets tailors set their own pickup points — at home, at work or somewhere else — and price shipping into their own rate. The customer sees which area the tailor works from. That solves the problem on the tailors' terms, and the integration can come when the economics work.
ResultS
Admin designed out of the flow
The new platform was built and tested in parallel with the old one running live, with a new visual identity and new flows for all three roles. Feedback from tailors described the new communication flow as clearer and better structured. The flows are designed so customer service handles exceptions only. In production testing, payouts reached tailors automatically through Stripe Connect. The admin dashboard collects each order on one screen instead of four.
I redesigned and rebuilt the landing page in Framer, and it is live today against the old platform. It is set up so the customer and tailor dashboard logins can be connected without developer help as soon as the last critical issues I have documented are closed.
All together, the changes are designed so each role can act on its own, the goal the old platform never reached.
relaunch metrics
Tailor managing their shop without admin help
The new platform is under the last iterations before relaunch. This is what I would have steered by for the first three months: tailors running their own shop without help from admin.
80 %
of new tailors publish a shop within seven days of registering.
90 %
of orders completed without customer service involved.
< 24 hours
Median response time on requests.
Alongside that I would have measured whether free pricing lifts revenue, through average order value and the share of jobs above the minimum price. After three months I would have added the share of tailors with at least one order per month, and whether anyone drops out of registration once the fee is explained.
handover
A product I have owned should be able to run without me
Once the rebrand was tested and documented, I handed the product over rather than sitting on the knowledge. The handover document collects deadlines, subscriptions and access, remaining issues sorted by severity, and the order they should be taken in.
A product I have owned should be able to run without me. That goes for the users, it goes for the team, and in the end it goes for my own role.