Every screen is an allocation decision

The product I work on is a loyalty engine that can do almost anything through its API. Points, tiers, rewards, referrals, campaign logic of nearly arbitrary shape: all of it reachable as pure API calls, no interface required. The same product ships a campaign workflow for people who will never call an endpoint in their lives. Most of my hardest design decisions live between those two facts, and the honest version of this article is that a lot of them did not feel like design decisions while I was making them.

A product with two front doors

Loyalty platforms in this segment are sold headless first. The pitch to an enterprise buyer is that the engine slots into whatever stack they already run: their commerce platform, their CRM, their data warehouse. An integrator can stand up an entire program, earning rules, reward catalogs, member tiers, without one person ever opening our interface. That is not an edge case. For some deployments it is the whole deployment.

And then there are the people who run the program after launch. Marketing teams who think in campaigns and segments, not in endpoints. For them the interface is the product, and the measure that matters is whether they can get a promotion live without filing a ticket. Both audiences pay. Neither is the fallback.

The standard advice says pick a primary persona and design for them, and it is good advice for most products. It quietly assumes the personas want versions of the same thing. Here they do not. One audience wants the engine fully exposed and maximally composable. The other wants most of it hidden. A platform does not get to choose between them once; it has to decide, surface by surface, which one it is currently serving.

The interface is a curated subset

When everything is achievable through the API, the interface stops being a window onto the product. It is a curated subset of it, and the curation is the design. The question I actually spend my time on is rarely how a screen should look. It is whether a capability deserves a screen at all, at what depth, and for whom.

There are two naive answers, and I have seen both fail. Expose everything and you get an admin panel for the database: technically complete, operationally hostile, and a support burden forever. Expose only the easy path and the product reads as a toy in exactly the conversations where a sophisticated buyer is stress-testing it. The right cut sits between those, and it moves per capability, which is why it cannot be settled once as a principle. It has to be decided, repeatedly, as cases.

It does not help that the workflow and the engine do not share a mental model. A marketer thinks in campaigns, audiences, and offers. The engine thinks in rules, events, and transactions. The interface is a translation layer between the two, and every translation is lossy in a direction somebody chose. Which concepts survive the translation, which get merged, which stay internal: that is the design, considerably more than the layout is.

The tempting compromise is an advanced mode: keep the simple flow, hide the rest behind a toggle. Sometimes that is right. More often it is a deferral pretending to be a decision, and it quietly doubles the surface you maintain, test, and document, because two modes are two products sharing a menu. I reach for it last, and only when both audiences genuinely need the same surface at two depths, rather than two different surfaces.

Sophistication and simplicity are the same backlog

Some clients run business cases that stretch the engine. Multi-brand programs with different earning logic per market. Reward economics that finance has to sign off on. Campaign conditions that read like small programs, because that is what they are. Each of these is real revenue attached to a real argument for more surface area in the interface.

And every accommodation taxes the easy workflow. Not dramatically; one field, one toggle, one advanced tab at a time. The tenth accommodation is invisible in any single review and unmistakable in a usability session six months later. So the question is never whether the sophisticated case matters. It is where the sophistication should live, and that depends on things no screen can show you:

• ·How often the logic changes. Configuration touched once at implementation belongs at implementation, or in the API. Anything operated weekly belongs in the workflow, however complex it is.
• ·Who fixes it when it breaks. If the answer is a developer either way, an authoring interface mostly manufactures confidence in people who will still need the developer.
• ·How many accounts share the need. One flagship client's requirement is a services conversation. The same request from a third of the base is a roadmap item wearing one client's name.
• ·What an error costs. At loyalty volumes a mispriced reward is a budget line, not a bug, and inputs with that blast radius cannot be handled like cosmetic ones.

None of those are aesthetic judgments. All of them decide what the design turns out to be.

Where an easy workflow actually comes from

The campaign workflow is not the engine with features removed. It is the residue of decisions about which questions a marketer should never be asked, and where those answers went instead: into defaults, into implementation-time configuration, into the API for whoever genuinely needs to override them. Simplicity in a platform is not omission. It is placement.

This is also why make it simpler is not actionable feedback on a platform interface. Everything still in the flow is there because somebody's business case needs it. Making it simpler means moving something, and moving something means deciding whose convenience it costs. That is a decision, not a design iteration, and treating it as an iteration is how teams sand the same screen for a quarter.

The API is an interface too

It would be tidy to say design owns the workflow and the API belongs to engineering, and it would be wrong. The API is an interface with everything that implies: naming, consistency, learnability, error states. An integrator reading endpoint documentation is having a user experience, and a confusing one costs the product in exactly the way a confusing screen does. Except the person being confused is the one wiring the engine into a client's stack, during the weeks that decide how the whole account will feel about the product for years.

The harder requirement is that the two interfaces agree on what things are. A campaign in the workflow and a campaign in the API have to be the same object, obeying the same rules, or the two audiences cannot talk to each other. The marketer describes what they want, the integrator builds it, and if the product's vocabulary diverges between surfaces, every one of those conversations needs a translator. Keeping the concepts identical across surfaces is design work, even though no screen changes when it is done well. It is some of the least visible and highest leverage work on the roadmap.

The strongest design input rarely arrives as a design

Here is the part that took me longest to internalize. The inputs that most changed our interface did not arrive as critique, research readouts, or a better mockup. They arrived as business arguments: what implementation partners actually configure at onboarding, which roles touch the product weekly and which touch it once a quarter, how the structure of a deal decides who operates the program at all.

A designer's first instinct is to evaluate an argument like that at the solution level, as if it were feedback on the screen. It is not. It moves the constraint set. And once the constraints move, defending the existing design against the new argument means answering a question nobody is asking anymore. The design did not get worse. The problem it answered stopped being the problem.

Judging an argument you did not make

This only works if the arguments get interrogated, because commercial urgency and commercial evidence are not the same thing. The discipline is symmetrical with design critique. What is the claim standing on: something measured, something modeled, or something asserted with confidence in a meeting? Does it generalize past the account it came from, or is the loudest client being mistaken for the market?

Arguments that survive that interrogation have redirected work I believed in, and they should have. Arguments that do not survive it get declined on exactly the grounds a weak design does. Not because a designer outranks anyone, but because the evidence was not there. Holding both kinds of input to the same standard is what makes the deference credible when it happens.

When design struggles, that is information

Some screens resist resolution for weeks. Every version is a compromise, every review reopens the same tension, and iteration stops converging. I used to read that as a craft problem and respond with more variants. Usually it is not a craft problem. It is two constituencies contesting one surface, and no volume of iteration settles a question that is actually about who the surface is for.

The way out is rarely an eleventh version. It is a decision: this surface serves the operator, and the integrator's version of the need is served by the API, or by an implementation-time setting, or by nothing for now. The difficulty was the diagnostic. A screen that will not settle is usually pointing at a decision nobody has made yet.

Deferral has a format

Which brings up the least glamorous artifact in this whole story. When a direction loses to a better argument, the work gets parked, and parked work decays into lost work unless the parking is written down. Three things, recorded where the next person will actually look: the rationale it lost to, the conditions under which it re-enters, and who owns noticing when those conditions are met.

Without the record, six months later nobody can tell whether the gap in the product was a decision or an accident, so nobody touches it, and the next person routes around it. It is the same failure mode that kills design systems through undocumented deviation, wearing product clothes. A deferred design with a written re-entry condition is an asset. A deferred design without one is just a file.

The unit of output is the decision

I do not measure my contribution by how much of the shipped interface I drew, because on a platform that number can go up while the product gets worse. The unit of output at this level is the decision: what got a surface, what stayed in the API, what got deferred and on what terms, and whether the strongest argument won regardless of which discipline it came from.

None of this is an argument against craft. The screens still have to be excellent; the details still carry the product's credibility in every demo and every daily session. It is an argument about sequence: allocation first, then craft, because polishing a surface that should not exist is the most expensive kind of polish there is.

Enterprise is the background here, not the subject. The stakes happen to be enterprise-shaped: implementation partners, compliance review, reward budgets with real money in them. But the mechanism travels. Any product whose engine can do more than its interface should show is making allocation decisions, with or without a designer in the room. The engine can do almost anything. The screens are where the product commits.