Web application UI design means designing the shell around the work. That includes navigation, tables, forms, permissions, and the small affordances that make a tool fast on the thousandth use, not just the first.
Most advice under this heading is website advice with the words swapped in. White space, color palettes, "intuitive navigation" as a bullet point. It tends to skip navigation architecture, tables, the modal versus page decision, and permissions, and those make up most of the actual job.
Here is the thesis this post works from. A website is a place someone visits once or twice. A web app is a tool someone opens every day for months. That difference decides almost everything below. Getting this shell right matters most at the very start, when a product moves from 0 to 1 and these early architecture calls are hardest to undo later.
The visual layer of a dashboard, its grid, its cards, its number typography, its dark mode, lives in a sibling post covering that craft in full. This post covers the shell around that dashboard: how someone gets to it, what happens when they act on it, and who gets to see it at all.
Web application UI design: a tool, not a website
A website is built for the first visit. Onboarding, persuasion, a little delight to keep someone reading. Most of what people call good web design was built for that one moment.
A web app is built for the thousandth visit. The person using it does not need persuading. They need to move fast, and they need the screen to look the way it did yesterday.
This is where teams get it wrong most often. They ship an app and judge it the way they would judge a landing page, by whether the first screen looks clean and friendly. But the user who matters is not a first time visitor. It is the accountant who opens this exact screen forty times a day.
Here is the consequence nobody says out loud. Moving a button between releases is nearly free on a website. On an app, it is genuinely expensive, because you just broke muscle memory someone built over months. A redesign that moves the export button two centimeters left, for a cleaner toolbar, costs every daily user real time relearning where things are.
Stability is a feature. Treat it like one, even when that means shipping an app that looks a little less exciting in a portfolio screenshot, because it has not changed in a year.
Pick navigation for the app you will have in a year
"Intuitive navigation" is not a decision. It is a wish. Here is the actual decision, with the tradeoffs that matter.
Top tabs. Fine for a handful of destinations, maybe five or six. They fail past that point, because horizontal space does not scale. Add a seventh, and something has to shrink, wrap, or hide.
Sidebar. The default once you have more sections than fit comfortably across the top. Vertical space scales in a way horizontal space never does. A sidebar with twenty items is still readable. A tab bar with twenty items is a joke, which is also why a sidebar survives growth better: you can always add another line.
Command palette. Not a replacement for navigation, an accelerator on top of it. Once an app has more actions than any menu can reasonably hold (bulk operations, admin tools, search across records) the palette is how a power user actually reaches them, keyboard first. It does not excuse a bad menu. A palette bolted onto confusing navigation just hides the confusion from anyone who has not learned the shortcut yet.
Breadcrumbs. They only earn their place with real hierarchy, more than two levels deep: account, then project, then task. On a flat app, breadcrumbs are noise dressed up as orientation.
The rule that decides most of this: design navigation for the app you will have in a year, not the one you have today. Restructuring navigation on a live app is not a redesign, it is a migration. Every saved link and every trained habit breaks at once.
Tables are the surface nobody designs
Buttons and color get all the attention. The table gets almost none, even though it is where most work in a B2B app actually happens.
The rules that matter are their own subject: where the data lives decides what sorting and search can honestly offer, what the header checkbox means across pagination, whether the view has a URL, and when to buy a grid rather than build one. That ground is covered in ten decisions to make before you draw a row.
The one rule to keep here is the one that tells you whether any of it worked: if your users export the table to a spreadsheet to do their real work, the table failed. The export is a bug report, not a workflow. Before adding another column, check whether the screen even handles the loading, empty, and stale states a data screen has to get right.
Modal, drawer, or full page: the decision nobody names
Every screen in an app raises this question, and most teams answer it by feel instead of a rule.
Modal. Right for a short, focused task that must finish or cancel: confirm a delete, rename a file, set a due date. Losing the background context is fine, because the task takes ten seconds. A modal that scrolls, that has tabs inside it, that holds a whole workflow, is a page wearing a costume.
Drawer or side panel. Right for a detail or edit view where keeping the list behind it visible is the point. Someone working through forty support tickets wants to open one, act on it, and land back on the list without losing their place. A drawer keeps them oriented in a way a full page cannot.
Full page. Right for anything with real depth, anything someone might refresh, anything someone would want to share. An invoice, a project settings screen, a customer record. These need room, and they need to survive a refresh without losing state.
Here is the rule that settles most of these arguments: if someone would send a colleague a link, saying look at this record, it needs a URL, which means it cannot live only inside a modal. A drawer is the exception that proves the rule. Give the drawer its own URL, so opening a ticket from the list is shareable and survives a refresh, and the drawer stays a layout choice rather than a dead end.
Forms inside an app are not marketing forms
Most form design advice is really about lead capture: shorter forms convert better, fewer fields, one clear call to action. None of that applies once a form lives inside a product someone uses for work every day.
Forms inside an app have the opposite shape. They are long, filled out repeatedly, and completed by someone trained, not a stranger deciding whether to bother. The general craft that applies to any form, labels, input types, validation timing and accessibility, is covered in how to design any form well. This section is only what changes inside a daily use product.
A few things follow from that.
Autosave, not a submit cliff. Nobody wants to lose twenty minutes of entry because they closed a tab by mistake. Save as they go, and show a small, quiet confirmation that it saved.
Validate at the field, the moment something is wrong, rather than a summary at the top after someone hits submit. A summary at the top sends people hunting back through a long form for one bad field.
Support partial completion. People get pulled into a call mid form, or lose their connection. Let them return later and pick up exactly where they left off, not from a blank page.
Default sensibly. Someone filling out the same weekly report does not want to reselect the same options every time. If the last five entries used Team A and Priority normal, start there. A form someone completes weekly should remember what they did last week.
Permissions change what a screen means
Roles get treated like a formality bolted on at the end. In a real app, permissions change what a screen means to the person looking at it, not just which buttons are live. Once the role count climbs past a handful, that becomes its own design problem at enterprise scale.
For every gated element there are three honest options: hidden, disabled, or visible but explained. Picking the wrong one is exactly what support tickets get filed about.
Hidden is right when a feature has nothing to do with someone's role. A billing admin panel means nothing to a contractor account. Showing it, then locking it, is just a tease.
Disabled is right when the person could plausibly get access someday, through an upgrade or an approval. But a greyed out button with no explanation is a dead end. Add one line: ask your admin to enable this, or available on the Team plan. One sentence turns a wall into a door.
And an empty state has to differ by role. No results and you do not have access to see these results are two different messages. Rendering them the same way tells someone their data vanished, when really they were just never allowed to see it in the first place.
Power users live on the keyboard
Keyboard rarely comes up in advice on this topic, which is strange, since the people who use a work app hardest are usually the ones whose hands never leave it.
Give the actions people repeat a shortcut. Archive, assign, search, create, whatever someone does dozens of times a day deserves a key, not just a click target.
Focus states have to be real, not the browser default some CSS reset quietly removed. An app driven by keyboard with invisible focus is unusable for anyone tabbing through it, including anyone using assistive technology.
Tab order should follow the visual order on screen. If tabbing jumps from a field on the left to a button on the far right, someone loses their place and stops trusting the keyboard entirely.
Perceived speed in an app is mostly about optimistic updates. Do not block the whole screen while one row saves. Update the row immediately, then reconcile quietly if the save fails.
Pick the five actions your users repeat most, and give each one a keyboard shortcut this week. That is a higher return than a full navigation redesign, and it ships in days.
The fastest way to find out which of this actually matters for your app is not a guess, it is watching real sessions. A short audit that traces where real users actually stall will show you the exact step people give up on, faster than any list like this one can predict.
The thousandth use is the real test
Everything above comes back to one line: an app gets judged on the thousandth use, not the first. A first time visitor forgives a lot. A daily user forgives almost nothing, because friction that costs five seconds now costs five seconds times every day, for a year.
Get the shell right: navigation that survives growth, tables nobody needs to export, forms that remember what someone did last week, permissions that explain themselves. Once that shell holds, the visual layer, the dashboard itself, its cards, its charts, gets much easier to get right too.
If you are building the kind of dense, internal, or B2B product this post describes, that is the work our design engineering practice does.