What We at 137Foundry Skip on Purpose When Shipping a Data-Heavy Dashboard Fast
The standard pattern for a "data-heavy dashboard" feature on a client project starts with a punch list of features the stakeholder wants on day one: column customization, saved views, advanced filters, multi-criteria sorting, conditional formatting, exports in three formats, scheduled reports, drill-down on every metric.
Most of those features have real users somewhere. None of them are needed in the first ship. When we are working against a real timeline, the work that gets cut to make the timeline is usually exactly this kind of feature, and the dashboards we ship without them perform better than the ones we ship with them. The cost of those features is real, the value is concentrated in a small power-user population, and the median user does not benefit at all from features they will never touch.
Here is the list we cut by default when shipping a dashboard fast, and what we ship instead.
What we skip
Column customization (show / hide / reorder). Build the right default columns. Maybe 5 to 15 percent of users will ever open a column picker. The other 85 percent live with the defaults. Investment in defaults beats investment in customization.
Saved views (named filter / sort combinations). Useful for the few power users who run the same multi-step query repeatedly. Not useful for the median user. Defer this to a later release; ship URL-shareable filter state as the lighter alternative.
Multi-column sort. Users who need to sort by "status, then priority, then date" are doing analyst-level work. The dashboard is usually for line-of-business use. Single-column sort is enough.
Advanced filter builder. "Status is X AND (priority is Y OR age > Z)" with a query builder UI. Almost no one uses this. The few users who do are usually better served by a separate analyst tool. The standard dashboard needs straightforward named filters, not a query language.
Conditional formatting rules. "Highlight cells where value > threshold in red." Useful at the spreadsheet level. The web dashboard equivalent (let users define formatting rules) is a complex feature with a small audience.
Multiple export formats. CSV is enough at first ship. XLSX, PDF, JSON exports are nice-to-have. Most users want CSV because it opens in Excel and they can do their own formatting from there.
Scheduled / emailed reports. A whole subsystem (cron, email delivery, attachment generation, opt-in management, rendering offscreen). Unless the dashboard's primary value is recurring delivery to non-users, defer this entirely.
Drill-down navigation from every metric. "Click any number to see the underlying records that produced it." Sounds great in design review. Requires backend support for record-level queries from aggregate metrics, which is not trivial. Ship the dashboard without drill-down, learn which metrics users actually want to drill into, add drill-down for those in the next release.
Customizable date ranges everywhere. A date picker on every chart and every metric. Usually a wrong instinct: most metrics make sense at a single shared time range. Ship one date range control at the top of the dashboard that affects everything below it.
Real-time streaming updates. Polling every few seconds, websockets, presence indicators. Almost no dashboard actually needs sub-minute freshness. Refresh on user action or on a 60-second interval is enough for almost everything.
What we ship instead
The list of what we do ship is much shorter, and it is the actual user-facing value.
Sensible default columns. Three to seven default columns for the primary task. Identity column leftmost. Numeric columns right-aligned. Status and category columns visible without horizontal scroll.
Sensible default sort and default filters. Match the most common user intent on landing. Recent items at the top, current user's items by default, status excludes closed by default.
A handful of named filters above the table. Three to seven visible filter toggles that cover the common task variations. Not a query builder, not an advanced filter panel. Just the three things users actually toggle.
Three distinct empty states. First-use, filtered-empty, load-failure. Each with its own copy and action. The cost is small and the support ticket reduction is large.
Keyboard navigation following the standard model. Tab in, arrow keys to navigate, Enter for primary action, Escape to cancel. Power users immediately stop reaching for the mouse.
CSV export. One action, exports the current filtered view. Covers 90 percent of the "I need the data elsewhere" use case.
One date range control at the top of the dashboard. All charts and metrics respect it. One control, not seven.
Refresh on user action plus a refresh-now button. No real-time streaming. The button is enough and the implementation cost is much lower.
Why this works
The cuts are not random. They are picked for two specific reasons:
Each cut feature has a long implementation tail relative to its user-facing benefit. Column customization is a week of work plus a permanent maintenance burden, and 85 percent of users do not use it. Saved views are another week of work plus storage and permissions concerns, and the audience is the power-user tail.
Each shipped item has high user-facing benefit at low implementation cost. Default columns and sort are decisions, not features; they cost a design conversation and a config change. Empty states are a half day of design and implementation each. Keyboard navigation is one well-tested file. CSV export is a small route that calls the same data query the table uses.
The pattern across many shipped dashboards is that the ratio of value-per-engineering-week is much better for the second list than the first. We ship the second list, the dashboard performs well, the team adds items from the first list later if usage data justifies it.
The Nielsen Norman Group research on dashboard usage in enterprise tools consistently supports this: feature-rich dashboards do not outperform default-quality ones at the median user, because the median user never reaches the feature-rich layer. The team's effort produces compounding returns from defaults and one-time returns from features.
The objections, addressed
A few common pushbacks when we propose this approach:
"But our power users will complain about missing X." Usually true. The power users are a small minority, often vocal, and they will indeed complain. The right response is to defer X to a later release and ship the dashboard now. Power user complaints are a signal worth responding to in iteration; they are not a reason to ship a worse dashboard for everyone else.
"But the contract says we deliver all features." Negotiate the scope before signing. Once signed, deliver what was promised. The argument here is about how to scope contracts, not how to break them.
"But the stakeholder asked for it specifically." Stakeholders often ask for features they assume they will use and then never use. Track the usage data after launch; the next conversation about feature priorities goes much better when you can show that the previous round's features are underused.
"But the competition has feature X." Maybe, maybe not. Feature parity is not always the right competitive strategy. A dashboard that loads faster and is more usable can win against a feature-rich slower one. Most dashboards in the category are bad enough that "better at the basics" is a defensible competitive position.
What this looks like in production
The dashboards we ship this way tend to look spare in screenshots. Few buttons, few menus, mostly content. The feedback from users is consistently that they feel faster and easier to work with than the alternatives. The support ticket volume is lower. The follow-up feature requests are different from what was on the original feature list, because actual usage surfaces different needs than the original assumption.
About six months in, we usually add two to four of the originally-cut features based on usage data. Sometimes column customization is one of them (when users have asked for it and we have signal that it would help). Sometimes saved views (when power users have demonstrated they would use them). Often a second export format. Rarely the advanced filter builder. Almost never the conditional formatting.
The longer treatment of the design choices we apply to data tables specifically lives at the 137Foundry write-up of data table design at scale. The broader pattern of skipping speculative features and shipping the well-designed core is what most of the 137Foundry services work is actually about, regardless of whether the deliverable is a dashboard or any other data-heavy interface.
The takeaway
When the timeline is real, what we cut is roughly the same list every time, because the features on that list are speculative for the median user. What we ship instead is the well-designed core: good defaults, empty states, keyboard navigation, simple export, one date control. The shipped dashboards perform better than the feature-rich alternatives in actual usage, and the iteration after launch builds the right features based on what users actually do, not what stakeholders assumed they would do.
For other clients running into the same scoping conversation, the pattern translates: look at what feature requests are speculative versus what is the well-designed core. Ship the core. Let usage data drive the iteration. The dashboards you ship this way are usually the ones users prefer.
For more practitioner UX guidance on dashboard design that aligns with this approach, the Nielsen Norman Group maintains the long-running research, and the W3C Web Accessibility Initiative covers the accessibility considerations that the cut-features-list happens to align with (fewer features means fewer accessibility audit cases at launch).
