How to govern remote UI changes across teams

Build, buy & decideOpinionNov 1, 20263 min readMiniwall team

Part of the series: Ways to change a live app without shipping a release

When changes stop going through the release, they also stop going through the process that came with it. You don't need a heavy new process to replace it. You need three small ones: sort changes into tiers, decide who approves each tier, and agree how to undo a change before you need to. Most of governing remote UI is writing those down.

This is an opinion, not a compliance framework. If your company has regulatory requirements, treat this as the part you do before talking to the people who know them.

What the release used to do for you

A release did several jobs without anyone naming them. It gave changes a review, a test pass, a date, a record of what shipped and a way back. When a screen can change without a release, each of those jobs needs a new home, or it quietly disappears.

Sort changes into tiers

Not every change deserves the same care. A typo and a new offer are different risks. A simple version:

Tier	Example	Who approves	Before it goes live
Small	A wording fix, a swapped image	The author	Preview
Medium	A new layout, a changed order of options	A second person in the team	Preview on phone and desktop
High	A new price, an offer, legal or regulated text	Product or legal, plus the owner	Preview, a written note, and a time when someone can roll it back

Swipe sideways to see every column.

The tiers matter more than the exact lines. They let the small changes stay fast, which is the point of the whole approach, and they put the attention where the damage would be.

Decide who can publish

Drafting and publishing are different permissions. Let more people draft than publish. Write down who may publish each tier, and keep that list short enough that you could name everyone on it.

Plan the way back before you need it

Every change should have an answer to "how do we undo this, and how long does it take?" In a good setup that answer is a previous version you can make live again, not a developer's afternoon. Then do a rehearsal: pick a harmless change, roll it back on purpose, and time it. A rollback nobody has tried is a guess.

Also agree on a stop switch for the worst case. If you can turn a screen off and the app falls back to something safe, you can stop an incident while you work out what happened.

Keep a record

Ask what record you have of what was live and when. At the least you want the history of versions that went live, in order. If your tools can also tell you who published each one, even better; if they can't, a short note in your team channel for tier-three changes costs almost nothing.

Test in a place that isn't production

Use a separate project or environment for trying things, with its own keys, and don't point your test app at the live one. It's the same reason you don't test a price change on real customers.

What this doesn't solve

A process doesn't make a bad screen good. It makes bad screens rarer and quicker to undo. And a process nobody follows is worse than none, because it makes you feel safe. Start with the tiers, and add more only when something goes wrong that the tiers didn't catch.