Zalando's partner onboarding form was generating manual work for two internal teams on every submission. I redesigned the banking details flow and made billing modes visible to partners — cutting submission rejections by 70% and Partner Care tickets by 80%.
Zalando's Partner Program lets brands sell directly through Zalando's platform. Before going live, every partner sets up a business account — submitting banking details for each market they operate in, and getting assigned a billing mode that determines how they get paid. That process involved two internal teams reviewing every submission manually.
This was my first project after joining Zalando's Partner Lifecycle Management team as their sole designer. The domain was new, the design system was different from what I'd used before, and the problems were already well-defined. My job was to turn them into a form that partners could get right the first time — and that internal teams didn't have to clean up after.
User problem
The banking details form had unclear configuration options. Partners made predictable mistakes: currency mismatches, duplicate accounts, typos in fields that could have been filled automatically. They only found out something was wrong after the Master Data Management (MDM) team reviewed their submission, wrote a rejection note, and sent it back. There was no way to catch errors before submitting.
Business problem
The MDM team manually validated every banking detail. The Order-to-Cash (O2C) team reviewed those details to assign a billing mode — a decision invisible to partners that determined whether they were paid in local currency or EUR. On top of that, the Partner Care team fielded inbound questions from partners who didn't understand their options. Every submission had the potential to generate work across all three teams.
By the end of the first milestone, the redesigned form had cut submission rejections and cleared the backlog of manual work for two internal teams.
The problems were already defined — my job was to translate them into a form that removed the failure modes instead of just describing them.
The PM handed me research findings on day one. I mapped the partner lifecycle flow, understood what each downstream team depended on, and translated the findings into three design problems rather than jumping to solutions.
First iteration gave partners full control — expandable sections, country selection, all fields visible. Second iteration stripped it back: auto-fill what can be derived, validate what can't, remove what isn't needed.
The partner-facing form and the internal MDM tool had to work together. I delivered hi-fi wireframes for both, including all error states and alert messages.
The first iteration gave partners maximum control. The second gave the system more responsibility.
The expand/collapse pattern in the first iteration added navigational complexity without adding value — partners had to fill every section anyway. Removing country selection was a deliberate trade-off: rather than asking partners to specify a banking country that could conflict with their IBAN, we validated the IBAN itself and surfaced a note about operating countries. Less input, earlier errors.
The research had surfaced three distinct failure points. Each one had a direct design answer.
The O2C team had to guess the right billing mode from the banking details submitted — a manual step on every account. Partners had no visibility into how they were being paid.
Surface billing mode options directly in the form. Explain the difference between local currency mode and Euro mode. Let partners choose — and document that choice — so O2C doesn't have to.
Partners made typos in bank name and BIC/Swift — information that could be derived automatically from their IBAN.
Auto-populate bank name from the IBAN. Auto-fill account holder name from Zalando's legal entity database. Remove the fields entirely rather than asking partners to type what the system already knows.
The MDM team manually checked every IBAN for validity and operating country — a redundant step on every submission.
Introduce IBAN syntax validation. Surface an error immediately if the IBAN falls outside Zalando's operating countries. Move the rejection upstream — to the moment of input, not the moment of review.
The partner-facing form was one surface. The MDM team's internal tool was the other — and it had to be just as considered. Every alert message, error state, and edge case was designed and documented before developer handoff.
Asking partners to type information the system could derive from their IBAN was generating preventable errors. Removing those fields didn't take anything away — it just stopped the form from creating problems.
Partners weren't contacting support because they disagreed with their billing mode. They contacted support because they didn't know it existed. Making it visible — and letting them choose — removed the question entirely.
The partner-facing simplifications only held up because the MDM tool had matching error coverage. Both surfaces had to work together. Designing one without the other would have just moved the problem.
All three insights point to the same thing: the form wasn't failing because partners didn't try hard enough — it was failing because it was asking partners to do work the system could do instead.
New team, new design system, new domain — all at once. I couldn't wait until I felt ready. Making good decisions while still orienting yourself is something you only get better at by doing it.
The partner form and the MDM tool were two surfaces solving one problem. Treating them as a single scope — not a primary and an afterthought — was the right call. I'd make that explicit from day one next time.
When the HMW questions arrive with the brief, the risk isn't missing the problem — it's over-designing the solution. Stripping back the second iteration was harder than building the first one.