User experience
and interface design
in Redwood City

Enterprise software is full of moments where one person has to look at what another person did and decide yes or no: approve an expense, release a document, sign off on a configuration change before it goes live. The screen that carries that decision gets far less design attention than it deserves, and a weak one slows down exactly the people the software is meant to help.

The first job of the screen is showing what actually changed. A wall of raw data forces the approver to reconstruct the change from memory or from a separate tab. A before-and-after view, or a simple diff, does that work instead. It should be possible to see what changed without opening anything else.

Context belongs next to the decision, not behind it. Who is asking. Why. What happens if the answer is no. A requester field and a short note, visible on the same screen as the approve and reject buttons, cut down the back-and-forth that otherwise happens over email or chat once a decision gets made without enough information.

Reject needs a reason. Approve, most of the time, does not. Forcing a comment on every approval trains people to type something meaningless just to get past the field. Forcing a comment on a rejection gives the requester something to act on, and gives the record something useful for later.

Batch approval is where careless design causes the most damage. A list of items with a single select-all checkbox invites someone to approve twenty things without reading any of them. Slowing that path down slightly, with a confirmation naming the count and the type of item, is a reasonable cost for the drop in accidental mass approvals.

Status needs to stay visible everywhere the item can be found again, beyond the approval screen itself. A requester who cannot tell, from a list view, whether something is pending, approved, or rejected will keep asking. A clear badge next to the item removes most of that traffic on its own.

The requester should hear back without asking. A notification the moment a decision is made, carrying the reason if there was one, closes the loop the screen opened. Silence after a rejection is the single most common complaint about approval flows, more than the wait itself.

None of this needs to be elaborate. A clear diff, a short reason field, a visible status, and a notification cover most of what an approval screen has to do. The usual failure in this part of a product is not too little design. It is a form thrown together late because nobody treated it as a real screen.

Reviewers who handle the same kind of decision every day also benefit from a short summary line above the diff: one sentence stating what is being asked, written in plain terms rather than a field label. It saves a re-read on the busiest days, when a queue runs into the dozens.

Button placement deserves the same care given to any destructive or committing action elsewhere in a product. Approve and reject should never sit close enough, or look similar enough, that a fast reviewer clicks the wrong one. A distinct color, a slight gap between them, or a brief pause before a rejection is final all reduce that specific mistake.

Search across past decisions matters too, for anyone who needs to check what was approved last quarter and why. A reason field that gets indexed as well as stored turns the approval history into a record someone can actually use, rather than an archive nobody opens again.

Many enterprise products serve many customer organizations from a single codebase, and the design challenge sits on top of that engineering decision. The interface has to make it obvious, at every moment, which organization a person is currently looking at. That context has to stay constant. It also has to stay quiet, without repeating itself on every screen until it becomes noise.

The most direct pattern is a persistent, unmistakable indicator: an organization name, a small logo, or a color swatch, placed somewhere it cannot be missed. A name works. A logo works better. Pair it with a fast way to jump between the organizations a person manages, without losing what they were doing on the screen they came from.

Color and shape can carry the scoping cue on their own. A subtle background tint, a fixed label bar, or a colored edge that changes per organization works well. A support agent moving between ten accounts in a morning needs a signal felt at a glance. Reading a dropdown every time is too slow.

Per-tenant customization deserves a clear boundary. Draw the line early. Letting a logo, a name, and a small set of brand colors surface inside the shell keeps a product feeling like it belongs to the organization using it. Letting individual organizations restyle layout or navigation turns every screen into a one-off that has to be tested and supported on its own.

Destructive or bulk actions need extra care in this setting. A generic warning is not enough. A confirmation that names the organization outright matters most for the people who manage several accounts at once, since they are the ones most likely to act on the wrong one without noticing.

The first screen a brand new organization sees, before anyone inside it has added data or invited a colleague, deserves its own design pass. An empty table says nothing useful. Clear next steps here save a support conversation later.

Internal staff usually need a view the customer never sees. Search and reporting that spans every organization at once, built from the same components as the scoped view. The permissions behind it are different, and stricter.

A simple list of organizations breaks down once a person manages more than a handful of them. At that point the switcher needs its own search box, recent organizations pinned near the top, and grouping by whatever the internal team already uses to sort accounts, a region, a plan tier, a sales owner. Without that, the switcher itself becomes the slow part of the workflow, defeating the reason it was built.

The discipline here is less about drawing new screens and more about a small set of rules applied everywhere the interface can be entered. A multi-tenant product gets opened from many places: a link in an email, a bookmark, a support ticket. Each entry point has to reestablish context immediately. None of them can assume the person just arrived from the dashboard.

Getting this pattern right once, in the shell every screen inherits, is far cheaper than fixing it screen by screen after launch. The shell is worth the extra care up front.