Nobody at Hummingbirds had ever drawn the full system.

Admins knew their own approval rules. Brands knew what they wanted to see. Product knew the technical constraints. The whole process lived in five or six people's heads and no two of those heads agreed on the shape of it.

I interviewed admins to surface every rule and every step, asking why each decision got made rather than just what the decision was. I read every scrap of documentation I could find. Then I traced each creator scenario through the existing toolchain end to end.

The hardest knot wasn't the tools. It was time. Which flows a creator could access changed depending on where the campaign was in its lifecycle, and nobody had written that down either. A cancellation request means something different in week one than it does the day before content is due.

Once the picture took shape, the actual problem showed up. The flow was overcomplicated, and inside that complication every admin was choosing their own adventure. Three findings came out of the mapping.Finding 1


Several scenarios were already deterministic. Admins were following a set of rules that already existed, they just existed informally. Good news. Easy to systematize.
Finding 2

The admin tool had no integration with the third-party chat software. Not good news.

Finding 3
The rest of the scenarios had no rules at all. No criteria, no precedent, nothing written. Admins winged it, every time. Medium news.

The presenting problem was operational. Too many tools, too much manual work. The real problem was that half the decision logic had never been written down, and you can't automate a judgment nobody has articulated. Design work couldn't start until that logic was explicit.

With the problem defined, I set three constraints before opening Figma. They existed to keep scope from expanding in four directions at once, and I pointed at them constantly.

Protect judgment where it matters. Automate everything and you remove the oversight that protects the brand relationship. Require admin review for everything and you've rebuilt the manual system with a nicer interface.

Surface data where it's needed. Any decision made in the admin tool propagates to the creator and the brand portal automatically. No secondary steps, no one chasing a status.

Focus on the end user. Creators in these flows are already having a bad day. We don't get to make their job harder in order to make our internal workflow easier.

In a multi-surface system the information architecture is really about data ownership. What lives where, who can act on it, and what fires downstream when they do.

Five creator-initiated scenarios:
• Cancel Participation
• File an Extension
• Can't Find Product In-Store
• No Product Nearby
• Product Arrived Late

Four surfaces, each handling all five:
• Creator mobile app — where the flow starts
• Internal admin tool — where humans make judgment calls
• Brand platform — where brands track campaign performance
• Admin workflow logic — the decision tree behind what gets approved and rejected

A cancellation is never only a cancellation. It's an admin notification, a brand analytics update and a campaign adjustment, all at once. Mapping that before any screen work meant the dependencies were visible while they were still cheap to change.

I worked through every scenario with admins. The question was never "when would you approve this." It was "what makes this a yes or a no without you in the room, and what genuinely needs you."

That distinction is the whole system.

Automated: product availability. Can't find it in one store, no nearby store carries it. Defined resolution paths, no judgment required, no reason for a person to sit in the middle adding delay.

Kept with admins: cancellations and extensions. Both need context only a human can weigh — creator history, brand sensitivity, how close the deadline is.

With the logic codified, content structure followed from it directly. Every label and status message came out of the decision rules rather than UI convention. The naming was precise because the rules were finally precise.

With the logic settled, I built each flow from the existing design system, adding components only where the system genuinely didn't have an answer.

The admin tool had one job: let someone make a good decision fast. Every review needed full context in a single view, no tab-switching. I mapped what was actually load-bearing for each decision type and surfaced only that — the request, pre-populated decision criteria, creator campaign history, and a one-click approve or reject with a required note. That note went to the creator and the brand platform automatically.

The creator flows all started from one entry point and branched by scenario. Three rules held across all five: acknowledge the request before asking for anything, collect only what's needed to route or resolve it, and close every flow with a defined status. Resolved now, under review with an ETA, or escalated with a contact. Never ambiguous.

Accessibility review happened here rather than at handoff. Dense internal tools fail on contrast and keyboard navigation, and both of those matter more when someone is moving fast in a low-attention environment.

Creator workflows went into our regular user research calls and got tested the way any consumer flow would.

The admin side was the bigger risk. Changing how someone does their job is harder than changing how someone uses an app once a month, and internal users are the ones most likely to get handed a tool without ever being asked about it. So I sat with admins individually and ran usability tests exactly as I would for any other user — tasks, observation, no coaching — and documented every issue and every change that came out of it.

The work only counts if it survives contact with engineering.

Every interaction, every fork in every flow, and every condition that changed behavior got documented. For a system where the same screen behaves differently depending on campaign state, that documentation is the product as much as the screens are.

Every project has complications that don't show up in the kickoff deck. Two of them shaped this solution more than the original brief did.

When the rules run out. Several scenarios never resolved into a clean yes or no, and forcing one would have stripped out the admin judgment that protects the brand relationship. The answer was approve/reject controls plus override capability for the edge cases. The system handles what it can determine. Humans handle what it can't. That's a smaller automation win than the brief wanted and a better product than the brief described.

Getting the org to let go. Admins loved the new flow. Customer service leadership liked it on paper and were nervous about actually making the change — and CS had final say, so nervous was enough to stop it.

Alignment there had nothing to do with selling the solution. It was about working out what specifically scared them and designing around that. Walkthroughs, documentation and a lot of patience. The thing worth knowing is that the objection was never the one stated in the meeting, and you don't find the real one by presenting harder.

I left the company before engineering picked the project up. What existed at the end were design goals validated through usability testing and stakeholder review, plus something that hadn't existed before: a complete, shared, written picture of how customer service actually worked and how it could work.

Admin tool — workflow automated where the rules allowed it, judgment preserved where they didn't, data surfaced where decisions get made.

Brand platform — campaign performance, individual content and creator activity in one place, so brands could see the shape of what was happening without becoming responsible for managing it.

Creator mobile app — every customer service request begins and ends in the app. No external tools, no waiting on a human to notice.

For a company moving from agency operations to product infrastructure, that map was the prerequisite for everything after it. You can't scale a process nobody has drawn.