ME
DÖ
P
UYOfferwall platform, partner onboarding
Sixty settings nobody could explain
The settings that decide how Playtime behaves sat behind a single dropdown, carrying whatever name their developer chose. Fifty four of them had no description or tooltip. Several of the people who wrote them had left the company. Before I could restructure anything, I had to work out what they did.
Sixty settings grouped by the decision they serve. Each section opens on its own instead of sharing one long page.
Context
Setting up a publisher application is the moment the entire Playtime experience gets decided: how rewards behave, what the end user sees, how payouts reach them. Most of that lived in one dropdown holding sixty plus options. Requirements originated on the business side, but the link between that intent and the eventual label was loose, so engineers named each config however made sense inside the backend. The company onboards around five new publishers a month, so every week of setup friction is a recurring cost rather than a one off.
Tension
Three problems compounded. Comprehension first: 54 of the sixty plus configs had no description or tooltip, so account managers skipped anything they had not been explicitly told to enable, because guessing wrong on a live integration is expensive. Second, there was no rule about where a new setting belonged. When Playtime Studio launched it arrived as one toggle in the first section, then later gained its own configs, some of which went to rewards while others stayed in the dropdown. Third, and worst, several config owners had left and nothing was written down, so the behaviour of those settings existed only in backend code. I could not restructure a system nobody could currently describe.
Insight
The labels were written for the person implementing each setting, not the person deciding whether to use it. Once that was clear, the work stopped being a grouping exercise and became a translation job, and the deliverable became an explanation rather than a form. The evidence for that reframe arrived later: after release, 17% more configurations were in active use. Nothing new had been built. They had simply become legible.
Every label answered a question the engineer had. None answered the question the person configuring it was actually asking.
Decisions, and what each one cost
Impact
Measured over a two month monitoring period after release. A single month would not have been enough: with a seven week baseline, one cycle barely completes, so a two week improvement could easily be noise from deal size or publisher readiness. The two week reduction compounds: at five new publishers a month, that is roughly ten publisher weeks of release velocity recovered every month. The 17% figure is the one I find most telling, because nothing was added to the product. The same configurations simply became findable.
More: the system underneath, screens, leadership and step by step
The system underneath
Integration type is chosen first, because it determines which configurations are even relevant. The three sections after it are ordered by who answers the question, not by how the data is stored.
- SDK
- Web
- API
- Playtime Studio
- Payout system
- Data we return
- Push to own servers
- Reward types
- Offer mix
- Currency naming
- Verticals, custom events
- Apple relay
- DRM protection
- Fraud tolerance
- Internal only
Section one is everything happening outside the end user experience, answered by an engineer. Section two is where the publisher shapes what their users actually see, and belongs to a commercial owner. Section three is visible to us only: a publisher wanting to extend a fraud rule needs a business agreement first, so the interface reflects that boundary rather than hiding it.
Before, and what replaced it
The flow that shipped. Integration type is chosen first because it determines which configurations are relevant, then three sections ordered by who answers the question.
The original dropdown. Sixty plus options carrying the names their developers gave them, no descriptions, no grouping. Fifty four had no tooltip of any kind.
Grouped configurations with tooltips written for the person deciding, not the person who implemented it. Eighteen dependent configs were consolidated into six groups.
Inline feedback at the moment of enabling. Toggle cashback and it asks for the ratio and the cap immediately, rather than failing silently after submit.
Leadership and ownership
- Recovering knowledge that had left the companySixty plus configs mapped across ten plus alignment sessions with tech leads, developers, and both technical and growth account managers. Fifty four had no documentation. I read backend implementation notes to establish real behaviour rather than inferring it from labels.
- Deleting what should not have been thereEight configs had already been removed from the system endpoints but were still rendering in the frontend. They did nothing and had been offered to publishers as real options. I removed them, which is the clearest evidence the audit was worth doing.
- Bringing data to a taste argumentI asked BI for per config publisher usage so decisions about what to bury rested on adoption and revenue rather than my sense of what looked cluttered.
- Letting the users overrule my preferred directionI favoured the searchable side panel. Five of eight testers chose visible grouping, so that is what shipped. The tidier design was the wrong one.
How it works, step by step
- Choose the integration typeSDK, Web, API or Playtime Studio. This used to be a toggle buried in the first section, which is why Studio specific settings ended up scattered across three places. It now comes first and filters everything after it.
- Integration and payoutHow payouts work, which system to use, what data we return, and whether the publisher wants the data we collect pushed to their own servers.
- Rewards and offersReward types, offer mix, currency naming, verticals, custom event names. Where the end user experience actually gets shaped.
- System and security, internallyApple relay, DRM protection, fraud tolerance. Configured by us, and only after a business level agreement where fraud rules are being extended.
- Inline feedback before submitEach group states what is still incomplete at the moment you enable it. Toggle cashback and it asks for the ratio and the cap immediately, rather than failing silently after submission.
Looking back
The visible output is a cleaner form. The real deliverable was an explanation. Sixty plus settings that only made sense to their authors now state their purpose in the interface, and 17% more of them are in use as a direct result. Two of those months produced no design at all, which was the part that mattered.