#ui design

A few months ago we shipped a dashboard rebuild for a client whose users were filing tickets that all said some version of the same thing: "the app feels slower than it used to." The odd part was that our own performance instrumentation said the opposite. Median load time had actually dropped by about 15% compared to the previous version.

We spent a week convinced the metrics were lying before we figured out the metrics were fine. The interface was lying.

Where We Started Looking

The first instinct on a project like this is to distrust the monitoring, so we spent the first couple of days re-verifying our own numbers before we trusted them. Real user monitoring, synthetic tests from three different regions, server-side timing logs, all of it agreed: things had gotten faster, not slower, on every dimension we were tracking.

That's a genuinely uncomfortable place to be as an engineering team, because "the users are wrong" is rarely the right conclusion, and "our metrics are lying" was demonstrably false once we'd checked it three different ways. The only remaining explanation was that we were measuring the wrong thing entirely, that the users' experience of speed and our instrumentation of speed had quietly diverged.

What Was Actually Happening

The old dashboard had a full-page spinner that appeared the instant you navigated to it and stayed until every widget on the page had finished loading, sometimes six or seven separate data fetches. The new version was objectively faster in aggregate, but it rendered its first content later relative to when the spinner appeared, because we'd restructured the data fetching to be more efficient in total but less front-loaded.

Users don't experience total time. They experience the interval between "I did something" and "I saw something happen." We'd made the first number better and the second number worse, and the second number was the one people actually felt.

The Fix Wasn't a Backend Change

We replaced the full-page spinner with a skeleton layout matching the dashboard's actual grid: placeholder cards in the exact positions the real widgets would occupy, each one resolving to real content independently as its data arrived, instead of waiting for all seven fetches to finish together.

This meant the page started looking "alive" within a few hundred milliseconds, even though the slowest widget on the page still took the same amount of time it always had. Nothing about the backend changed. What changed was that the interface stopped hiding its own progress from the user.

Nielsen Norman Group's research on response time thresholds was a useful gut check while we made this call. The window between one and ten seconds, where most of these individual widget loads fell, is exactly the range where interface design determines whether a wait feels managed or ignored.

What We'd Do Differently Next Time

The one thing we underestimated was how closely the skeleton shapes needed to match the real content. Our first pass used generic rectangular placeholders that didn't account for the fact that one widget rendered a chart and another rendered a short text summary. When the real content swapped in, the layout shifted more than we expected, which reintroduced a smaller version of the same "something feels off" complaint we were trying to fix.

The second pass matched the skeleton shapes to the actual rendered dimensions of each widget type, checked against web.dev's Cumulative Layout Shift guidance, and that fixed it. It's a detail that's easy to skip under deadline pressure and expensive to skip in practice.

How We Verified It Actually Worked

We didn't just ship the skeleton version and assume the problem was solved. We watched a handful of session recordings from before and after the change, specifically looking at what users did in the first two seconds after navigating to the dashboard. Before the change, a meaningful number of sessions showed a click on the browser refresh button within the first second, a strong signal that the blank spinner state read as "nothing is happening" rather than "loading."

After the change, that refresh-click pattern dropped close to zero. Nobody was refreshing a page that was visibly already rendering content, even partial, placeholder content. That single behavioral signal told us more about whether the fix worked than any aggregate timing metric did, because it captured exactly the thing we were trying to fix: the moment of uncertainty where a user decides whether to trust that something is happening.

Ticket volume mentioning "slow" or "frozen" dropped by roughly half over the following month, without a single additional backend change. The lesson generalized past this one project: for any product where users describe something as feeling slow despite metrics saying otherwise, the fix is very often in how the wait is communicated, not in the wait itself.

The Part That Took Longer Than Expected

Building the skeleton layout itself took about two days. Getting the skeleton shapes to actually match the real widget dimensions took closer to a week, because it meant going back through every widget type in the dashboard, measuring its real rendered dimensions across a range of realistic data (a chart widget with three data series looks different from one with twelve), and building a matching placeholder for each variant rather than one generic block reused everywhere.

That ratio surprised us. We'd budgeted the project assuming the skeleton implementation itself was the hard part. It turned out the shimmer animation and placeholder markup were trivial. The actual work was in the audit: figuring out what the real content shapes looked like across enough realistic scenarios that the skeleton didn't introduce its own layout shift once real data arrived. If you're estimating a similar project, budget the audit time separately from the implementation time. They're genuinely different kinds of work, and treating them as one estimate is how this kind of project ends up running over its original timeline without anyone being able to point to a specific reason why.

"The lesson that keeps repeating on projects like this is that perceived speed and actual speed are two different engineering problems, and most teams only budget time for one of them." - Dennis Traina, founder of 137Foundry

A few weeks after this project wrapped, a second client asked us to look at a strikingly similar problem on a completely different codebase, a mobile-first booking flow where the reported complaint was "the app hangs when you tap search." Same root cause, a blank screen during a genuinely brief wait, same fix, a skeleton preview of the results list shape. It's become one of the more reliable diagnostic shortcuts we reach for now: when the metrics and the complaints disagree, check what the user actually sees during the wait before assuming either one is wrong.

Have you ever thought that a game's UI would be perfect for real world working software? What could industries learn from game UI?

also partly to study the new UI stuff in 4.7 and learn how to build somewhat complex UI.

We at 137Foundry recently spent a week on what was supposed to be a small piece of work: review every empty state across a customer's mature product, and ship the fixes that took less than a day each. We expected to find five. We found thirty-one. Twenty of them were one-line fixes. A few were genuine product decisions that needed real design work. The week of work surfaced a much larger pattern about how empty states get neglected, and we wrote up our notes because the pattern is consistent across the products we have audited since.

This is what we found, and how we changed the way we look at empty states in our own work.

Photo by cottonbro studio on Pexels

Almost every empty state was shipped once and never touched again

The first thing we noticed when we started cataloging the empty states was how old most of them were. About three-quarters of the empty states in the product had not been touched since the feature they belonged to shipped. The features had matured, the capabilities had expanded, the user base had changed, but the empty states still said "Create your first widget!" or "Welcome to the dashboard!" in copy that was clearly written for a launch audience.

Returning users see that copy and feel slightly insulted. New users see it and notice immediately that the rest of the product is more sophisticated than the empty state suggests. The mismatch between the welcoming-but-shallow empty state and the otherwise polished product made the empty states stand out as the lowest-effort UI in the application.

We have started writing empty-state copy as if the user might see it on visit fifty, not visit one. The copy works on both, and it stops feeling like a launch screen that nobody refreshed.

Almost every empty state was the same UI for two or three distinct cases

The next pattern was the one we wrote about in the longer guide on empty states that earn trust instead of apologizing. The new-user case and the temporary-empty case looked identical. The filter-narrows-to-empty case looked identical to the temporary-empty case. The integration-broken case looked identical to the no-data case.

This was the source of the largest support burden in the product. Users would hit a screen that should have shown them their data, see "no results," and not know whether the problem was their filter, their account, or the backend. They would page support. Support would discover that an integration was broken, or a filter was set strictly, or the account had never had data. The fix was rarely complicated. The diagnosis was where the time went.

We changed every empty state on the product to be specific about which of the four cases it was rendering. The change took about three days of engineering time. Support tickets in the "your data looks wrong" category dropped meaningfully in the next month. We have since brought this discipline to other customer engagements and the same numbers come back.

A surprising number of the empty states were lies

This one took us by surprise. Three of the empty states we audited were technically untrue in the moment they rendered. The most egregious was a dashboard that said "No data for this period" while a backend integration job had been failing silently for forty-five minutes. The product knew the integration was broken. The product was the thing reporting "no data." The empty state did not tell the user that the no-data condition was the product's fault, not the data's.

The fix in that case was to expose the last-successful-sync timestamp on the API response, detect when it was older than the expected interval, and change the empty state copy accordingly. Twenty lines of code, half a day of engineering, and a real reduction in the support burden.

We have stopped treating "no data" as a leaf-level UI message in our work. It is now a question we ask the data layer. The data layer is allowed to say "no data because the source has not synced," "no data because the filter excludes everything," and "no data because there has never been any data." The UI renders accordingly. The principle is similar to the discipline that the Site Reliability Engineering book describes for monitoring: a silent failure is worse than a loud one, and the empty state is one of the cheapest places to make a failure loud.

The filter-empty case was the highest-leverage fix

If we had to pick one fix from the audit that paid back the fastest, it was the filter-empty case. The product had filter controls on most of its data-driven screens, and the filters could combine in ways that excluded the entire dataset. The empty state did not tell the user which filter was responsible.

The fix was to render the active filter set as removable chips inside the empty state itself. Each chip showed the filter key and value, with a small X button to remove it. A "Clear all filters" button sat next to the chips. Implementing the chip rendering took less than a day. The chip pattern itself is well-documented in the Material Design 3 reference for chip components, so most of the work was wiring up the existing filter state to a chip component the design system already had.

After the change, the support tickets in the "the data is missing" category for filter-related cases effectively went to zero. Users could see what was active, remove the offending chip, and self-serve their way back to a populated screen.

We started treating empty states as a tracked KPI

The most enduring change from the audit was a small internal one. We started counting the number of distinct empty states across the product and assigning each one to a specific user state. The product has, in our internal docs, a four-by-N grid: four user states (new, populated, filter-empty, error) by N primary screens. Each cell has either a populated row or an empty state, and each empty state has a small audit checklist.

The grid is a living document. New features add rows. Refactors collapse cells where two used to be the same. The grid sits next to the design system documentation and gets reviewed when any team touches a relevant screen.

This is small infrastructure that pays back the first time someone almost ships a feature with a missing empty state and the grid catches it in design review. We did not invent this practice; it shows up in some form in the Apple Human Interface Guidelines for native apps and in some of the patterns documented by the Nielsen Norman Group. But the discipline of writing it down for a specific product, on a specific quarterly cadence, is what made it useful.

Photo by Melih Can on Pexels

What this changed about how we ship features

Auditing the existing empty states changed how we ship new features at 137Foundry. The change is small in code and large in habit.

Before we write the new feature's main screen, we sketch the four empty-state variants on a single page. New-user, populated, filter-empty, error. Each one has a one-paragraph description of what it shows. By the time the engineering work starts, the empty-state design is already done, and the developer building the screen does not have to choose what to render in each of the four cases.

This is the discipline we now bring into 137Foundry's web development service by default. The four-state sketch takes an extra hour during design. It saves a day of rework during engineering and a quarter of support volume in production.

A short version of the audit checklist we use now

If you only have an hour and want to do this on your own product, here is the short version.

Pick three of your most-used screens. For each, walk through four user states: new account with no data, established account with normal data, established account with filters set strictly, and established account with a broken integration. Look at the screen in each state.

Note where any two of the four states show the same UI. Each one is a candidate fix. Note where any state shows copy that was written for a launch audience and does not work for a returning user. That is another candidate fix.

The list usually has ten items by the end of the hour. Pick the three that the most users will hit. Ship them in the next sprint. The pattern after that is to do this audit once a quarter for every major screen.

The short version

Empty states accumulate. They get shipped once at launch, the product matures around them, and they quietly become the lowest-effort UI in the application. An audit takes an hour per screen, and the fixes are mostly small. The payback is in support volume and user trust, and it is consistently larger than the engineering teams expect when they start the work.