Context
Affiliate operations at volume
In affiliate marketing, merchants run programs with tracked links; publishers promote those links to earn commission. FMTC aggregates and cleans those deals so publishers can use them. Internally, Data Processors (DPs) work through large queues under timer-based KPIs; DP Managers triage and assign work to keep queues light. It's an efficient system when every moving part works smoothly.
Our team was me (lead designer), our PM, FMTC stakeholders, and their developers.
Problem Statement
Dense queues, scattered actions
Actions on each deal form where all over the place, literally scattered around the screen, so DPs wasted time scrolling up and down to fill things in. Queues varied by status, producing inconsistent tables and forms that were jarring to work with quickly; important info couldn't be hidden or truncated so some tables were just not easy to scan. Even a few seconds lost per deal processed, at thousands of deals per day, added up negatively in terms of KPIs.
Constraints
Speed-first, system-bound
Speed rules were explicit: no extra clicks anywhere, which meant no dropdowns or action menus (except for a couple legacy dropdowns that remained). Columns with decisive data couldn’t be truncated. We had to make sure our designs fit on the smallest laptop possible first.
On the customer-facing portal, project time/budget required a UI-first uplift with minimal net new UX.
Approach & Strategy
Highest priority was to make the deal form fast and predictable, then make the queues fast to scan and act on, and finally carry that clarity to external pages. We paired tightly with developers, sharing wireframes and lightweight proposals since large part of the team were non-designers, and iterating quickly as constraints came up. We made sure our proposals were solid before showing any colours and new UI.
The focus was clear: fewer decisions per screen, fewer context shifts, and less back-and-forth.
Iterations & Experiments
We validated the unified actions and header concept in grayscale first, since our audience were non-designers. Stakeholders reacted to our thinking rather than the look and feel, which let us iterate without the bias or distraction of a new UI. We tuned hover-overs and iconography until recognition felt instant without needing labels.
On forms, we tested pills vs dropdown, and we found search-in-dropdown plus visible selected pills was the right mix for large sets. It was a balance between introducing a change we knew had value but could scare DPs that had been used to a specific component for so long.
On queues, we went through multiple iterations to apply best practices while always showing was needed to be seen at a glance.
Key Design Decisions
We redesigned the deal's header and made it fixed-as-you-scroll: there lived not only the deal's metadata but every action that could be taken on it (including the final submit), which meant it had to be referenced often. Inputs were modernized and tightened; for selection, large sets use searchable dropdowns with selected pills; small sets use fast multi-select pills.
Across tables, predictable fields (e.g., date/time) get fixed widths while priority fields (e.g., label) stretch; action affordances mix icon-only and short labels to keep scan speed. Across the product we standardized components, filters, and a calmer palette introducing a design system devs could maintain.
Final Experience
Processing a deal now starts with a stable, informative header and a unified action bar that stays with you. You move down the form once; you don’t scroll back up to submit. Selections are faster because the control matches the data set: pills for short lists, searchable dropdowns for long lists, and visible selections as pills where it helps. A careful balance between a modernized, clean UI that also fit FMTC's constraints and needs.
In queues, the table is dense but readable, with mixed action bars that respect scan speed and a column strategy that prioritizes what DPs actually use to decide. The UI tone is calmer, the components are consistent, and the customer.-facing portal carries the same system.
Outcomes
Less time scrolling up and down and hunting actions across the screen means a smoother, seconds-quicker flow for DPs that really compounds over thousands of people and deals processed every day. Managers can trust that queues read the same way across statuses and tables have a consistent behaviour, so triage is quicker.
On the customer-facing side, pages are consistent, easier to extend, and ready for scale with a shared component library and style guide. The app as a whole also enjoys a much needed, calming and modernized UI facelift.
Learnings & Final Thoughts
This whole project was an exercise in striking a balance between what was "correct designing and UX principles" but most importantly what FMTC actually needed. In the end, how they worked day-to-day; their habits, needs and constraints went before what we would have considered best practices, and we had to make some choices we wouldn't have in a different context.
The main goal was always clear: make things smoother for our DPs to use repetitively and daily, which in turn would allow them to take on a higher volume of that work. In the end that was what the business was after.
