The Button You Can't Click Is a Product Policy

Every interface contains a rulebook

You can usually identify a product's rules without reading its terms of service. Look at what people can and cannot do.

Who may invite another member? Can an owner delete a shared workspace without warning? Can someone reverse a mistaken payment setting? What happens when an account is suspended? Can a person export work before they leave? These questions are often implemented as permissions, defaults, eligibility checks, and disabled controls. To the user, they are the available choices.

There is a technical name for parts of this: access control determines who is allowed to perform particular actions. But permissions alone do not settle the broader product question. Two systems can enforce the same rule while giving people very different experiences of it. One might state the reason for a restriction, offer a safe alternative, and explain how to challenge an error. Another might show only a greyed-out button.

Researcher Nathan Schneider examined the governance structures embedded in major online-community tools. His article on “implicit feudalism” argues that dominant platform designs have often concentrated authority in administrators, even though alternative governance arrangements are possible. The argument concerns online communities and their administration; it is not evidence that every digital interface has the same power structure. Schneider, New Media & Society.

GoodScool's practical reading is simpler: the menu of possible actions is also a menu of whose judgment matters.

The missing action is often more consequential than the visible one

In the fictional community, the removal button is easy to notice. The missing appeal route is harder to see because it leaves no visible trace. The person simply stops at the edge of what the product permits.

GOODSCOOL JOURNAL / FIG. 01

Read full figure transcript

FIELD STUDY / 01 GOODScool · ORIGINAL TEACHING EXAMPLE A disabled action is a policy surface A / HIDDEN RULE ACCOUNT / ACTIONS Edit shared listing Edit listing · Unavailable No explanation, owner or next step is presented. B / VISIBLE RULE + REVIEW ACCOUNT / PERMISSIONS Editing is restricted This role cannot change a published listing. Request a review from the workspace administrator. View permission details → Responsible role · rationale · review path Fictional governance interface. The restriction, decision owner, and permitted review path must be specific to the product and applicable rules. This is not a description of a live service or a universal legal requirement.

The same problem can hide in mundane product flows. Consider a project-management tool where an admin can archive a project but contributors cannot retrieve their own work afterward. Or a learning platform where a mentor can mark a submission as invalid, but a learner cannot see the reason or request a correction. These are illustrative situations, not observed flaws in named products.

The design team might describe each case as an edge state. For the affected person, it may be the moment when the system matters most.

Nielsen Norman Group's usability heuristic User Control and Freedom recommends clear ways to exit unwanted actions and undo mistakes. That principle is valuable, but governance asks an additional question: what if the unwanted action was taken by someone else, using authority the product granted them? An Undo button for the moderator is not an appeal for the member. NN/g, Ten Usability Heuristics.

A more complete product review therefore asks not just whether a task is easy to perform, but whether the people affected by that task have a meaningful way to understand or contest it.

A fair product does not mean everybody controls everything

There are good reasons for some actions to be restricted. Moderators need to address harassment. Financial changes may require authorization. Shared records may need retention, and certain actions are deliberately hard to reverse for safety or legal reasons. Simply giving every person every permission is not a serious governance model.

The issue is whether restrictions are proportionate, understandable, and accountable.

A clear example exists in law, although it should not be generalized beyond its scope. Under the European Union's Digital Services Act, users have defined ways to contest certain content-moderation decisions by covered online platforms, including internal complaint mechanisms and, in relevant cases, out-of-court dispute settlement. The European Commission describes these rights on its official site. These obligations are jurisdiction- and service-specific; they are not a universal legal requirement for all products everywhere. European Commission, Digital Services Act.

The product lesson is not “add an appeal button to every screen.” It is that a consequential decision may need an explanation, an owner, a review path, and an appropriately scoped way to correct an error. Product managers, designers, engineers, operations teams, and legal or policy specialists may all be responsible for making that route real.

A decorative appeals form that nobody reviews would be worse than an honestly described limitation.

Who is allowed to change the rule?

Most teams think carefully about permissions at launch. Fewer spend equal attention on how those permissions can evolve after real people begin using the product.

Suppose the fictional community introduces a second review for removed posts. Who decides which cases qualify? Who can override the first decision? Does the original moderator see the appeal? Can members suggest rule changes, and what response can they expect? How will people know if the rule is revised?

These questions belong in a product's operating model, not merely in its UI kit. A button must connect to a decision-maker, a process, and a record. The workflow behind it can be as important as its placement.

The GOV.UK Service Standard calls for the capacity to improve services throughout their lifetime, using feedback and changing user needs, rather than treating launch as the end of design. Its guidance is written for public-service teams; the broader operating principle is useful elsewhere. If a system cannot learn from the consequences of its rules, a beautiful interface will not make it responsive.

There is a business cost to ignoring this. Requests move into support tickets, exceptions become manual work, and people leave without an explanation the analytics can interpret. These are plausible risks, not claims backed here by a GoodScool study or a quantified industry benchmark.

Design the decision and the correction together

For any consequential product rule, map two journeys: the ordinary decision and the path when that decision might be wrong.

In our hypothetical community, the normal path is simple: a moderator reviews a post, applies a policy, and the member receives a notice. A correction path adds something essential: the member can understand the action, request review where appropriate, and receive a decision; the team can identify recurring rule failures and revise its policy if warranted.

GOODSCOOL JOURNAL / FIG. 02

Read full figure transcript

FIG. 01 / EXPLAINER ILLUSTRATIVE / ORIGINAL GOODScool ARTWORK Figure 1. Two journeys belong in one product design: exercising a rule and correcting it. Original illustrative framework; no measured outcomes.

A useful handoff record for that work is a rule review card. It has six fields:

This is a proposed GoodScool teaching instrument, not a certified compliance checklist. Different products will need different safeguards. A medical system, payment service, and hobby community cannot share one appeal policy by copying the same component.

The critical test is whether each row has a real answer. “Support handles it” is not enough unless support has authority, information, and a defined path for acting.

When the user cannot edit the system, the team must stay reachable

Individual customization is sometimes valuable. People may want to arrange a workspace, change notification preferences, or choose how information appears. But not every governance problem is solved by more settings. A member cannot fix a biased moderation process by changing the color theme. A user cannot reverse an incorrect account restriction by moving a panel.

Participation also costs time. Requiring every person to join committees, master policy language, or argue with a chatbot can shift the organization's responsibility onto the people it serves.

The design goal should be appropriate control at the point of consequence. Give people direct control over personal choices where safe. Make consequential restrictions legible. Provide human or otherwise accountable review when warranted. Let feedback reach the owners of the rule rather than disappear into an inbox.

That also means accepting trade-offs. Abuse prevention can require confidential signals; privacy can limit how much is disclosed; organizations need consistent policy enforcement. Good governance design cannot guarantee agreement. It can make the process less arbitrary and the route to correction more credible.

Try the rule review before the next sprint

Choose one feature your team is building that can remove access, deny an action, change someone's work, or make a decision on their behalf. Do not begin with the happy path.

Ask the product manager to state the rule and its purpose. Ask the designer to show what the affected person sees. Ask engineering or operations who can reverse the action. Then ask who reviews complaints about the rule itself.

If the team cannot answer, do not add a vague “Contact support” link and move on. Decide what authority and response the contact will actually have. Where an appeal is inappropriate, explain the limitation and identify the safest available alternative. Make the decision log sufficient for internal review without collecting or exposing unnecessary personal information.

Finally, test the correction path with the kinds of people who would need it. The GOV.UK guidance on making services simple emphasizes testing the whole service people encounter, including offline elements, rather than treating individual screens as the complete experience. Use the same discipline here: a review path is only real if it works after a decision goes wrong.

Return to the fictional community. Its product team originally shipped three confident moderation buttons. Maybe all three were necessary. But the member whose post disappeared needed something the menu did not include: a way to understand the decision and, where appropriate, challenge it.

A well-designed product does not need to make every decision reversible. It needs to make its power visible, its restrictions defensible, and its mistakes correctable.