Systems thinking

32 funding combinations became one flow for Brand, Publisher and Finance

ROAS Target & Budget Tool · Associate UX Designer · With Brand, Publisher and Finance · 2025

32 → 1

Valid combinations, one flow

design fact

Roles served: Brand, Publisher, Finance

design fact

4 × 4 × 2

Target types × budget types × org levels

design fact

Org level

ROASDrive salesMax CPAMax conv. Fixed fee CPA Fee + CPA Open ended

1 of 32: ROAS target · Fixed fee budget · Affinity level

32 valid target, budget and org-level combinations. One highlighted cell is one configuration, not one screen. Try it.

The problem

Affinity runs campaigns across several ad products for three roles: Brand, Publisher and Finance. Each needs to set or check what a campaign is trying to achieve and how it is funded. Six rounds of design were drifting toward a separate screen for every combination.

The question was not which screen each combination gets. It was how many choices one person actually makes.

Two questions shaped the scope.

Question 1

What am I optimising for, and how is it funded?

Question 2

Can Finance invoice it?

Setting a target

What am I optimising for, and how is it funded?

Decision 01

Ask two questions of four, not one of sixteen

Tension: Each target type needs different inputs. A screen per combination means 16+ near-identical flows to build, test and re-teach.
Rejected: A wizard per target and budget pairing: the usual default, and 16× the engineering and QA surface for one underlying object.
Result: One create flow. Pick what to optimise for, then how it is funded. Fields appear only when they apply.

Add top-level target, step 1 of 3. Four target-type options as a radio list. ROAS is selected and reveals only its three fields; the others each list what they will ask for. — 1Only the chosen option’s fields appear2Other options say what they will ask forRefined mock-up, illustrative data.

Decision 02

Make uncovered tags the headline, before launch

Tension: With dozens of tags across many targets, a flat list cannot show which ones no target covers.
Rejected: A flat list or free-text field: the lightest build, and it hides the exact gap this system exists to prevent.
Result: One alert leads with the count of tags without a target, so orphaned tags show up before spend goes out untracked.

Split budget by tag. One alert says 45 tags have no target, with a View tags link. A progress bar shows how much budget is split. An empty state offers Attach tags. — 1One alert, with its consequence2An empty state that says what to doRefined mock-up, illustrative data.

Getting it billed

Can Finance invoice it?

Decision 03

Suggest a match instead of blocking the budget

Tension: A Fixed Cost budget needs a Deal-ID under a Masterbrand a new brand may not have. The person entering it rarely owns that mapping.
Rejected: A hard error that waits for another team to fix the mapping.
Result: Likely Deal-IDs appear as selectable rows, with the evidence behind each match. The note says plainly that it does not block.

Fixed-cost budget Deal-ID step. One notice says no Masterbrand is mapped and that this does not block. Three likely Deal-IDs are rated strong or partial match, each with an amount. — 1“This doesn’t block you”2Matches are rated strong or partialRefined mock-up, illustrative data.

Decision 04

Save unmapped targets as “Not invoiceable”

Tension: Finance cannot bill a target until it links to a Hubspot deal. When the target is created, that deal is often hard to find, or does not exist yet.
Rejected: A deal-ID text field, a required deal, and a quiet internal flag that surfaces at month-end.
Result: The form pre-filters Hubspot by the selections already made. With no deal yet, the target still saves and shows “Not invoiceable” on its row, visible to every role.

145 tags unmapped, with a Fix tags action2Not invoiceable, with a Map deal actionRefined mock-up, illustrative data.

Also shipped

Hubspot deal picker

Deals are pre-filtered by the target’s own selections, and the filter prints its criteria.

Target list status

Status carries real state, with the action each state implies.

What I did not build

Three separate dashboards, one per role. Brand, Publisher and Finance share one configuration surface with a role switcher instead, trading per-role customisation for a single source of truth on what a target and its budget mean.

Result

32 → 1

Valid combinations, one flow

design fact

16+ → 1

Flows to build, test and re-teach

design fact

Roles on one shared surface

design fact

Read the long version →UX audit and 21-law check →

Next: Pub inventory case study →