Prototyping Dashboards With Real Data: Why We Stopped Showing Clients Placeholder Numbers

Placeholder dashboards are always beautiful. Every name is "Ahmed Ali", every amount is a tidy four-digit number, every chart rises gently to the right, and no table ever has an empty cell. Clients approve them happily. Then the real data arrives in development, and the dashboard that looked finished starts falling apart.

We've stopped showing clients dashboards built on invented numbers. Where we can, we prototype with a sample of the client's real data, cleaned and anonymized. It surfaces problems weeks earlier, when they're cheap to fix. And it's getting easier: in October, Figma connected Payload CMS to Figma Make and code layers, and published a Lufthansa Systems case study on prototyping with external data. Data-backed prototypes are quickly becoming normal.

Why placeholder dashboards get approved and then fail

A dashboard is a container for someone else's data. When you design it with invented data, you're really designing for the data you imagined. Designers imagine tidy data because tidy data makes the layout look good. Clients approve it because it looks good. Nobody is lying. Everyone is just looking at a best-case scenario.

The trouble starts in development. Real names are long. Real amounts have seven digits. Real tables have gaps. The developer has to make design decisions on the spot, usually truncating, wrapping or shrinking things, and the dashboard drifts away from what was approved. By the time the client sees it with their own data, fixing it means a redesign.

What real data exposes

Here's what I see every time we switch a dashboard from placeholders to a real sample:

Length

Arabic full names often include several parts, and companies have long registered names. A name column sized for "Ahmed Ali" won't fit a four-part name. Product names, branch names and addresses all run longer than designers expect.

Mixed scripts in one cell

Real data mixes Arabic and English in the same field: an Arabic customer name with an English company name, an Arabic address with a Latin building code, an English product name with an Arabic variant. These cells are where bidi issues appear, with punctuation and numbers jumping to the wrong side.

Dates

Some clients need Hijri and Gregorian dates side by side, especially in government or finance work. Even when it's only Gregorian, real data shows whether you need relative dates ("2 hours ago"), times, time zones, or ranges. Each one changes column width and alignment.

Numbers

Large amounts in riyals or dirhams, negative values, percentages over 100, and decimals that matter in one column but not another. Real data quickly shows whether your number formatting rules hold. If currency is involved, see my post on designing the new GCC currency symbols.

Outliers

One branch with ten times the sales of the others flattens every other bar in your chart. One customer with 400 orders breaks the "orders" column. Placeholder data never has outliers. Real data always does.

Empty and partial states

Missing phone numbers, unassigned tickets, new accounts with no history, filters that return nothing. These states are where users spend more time than you'd think, and they're almost never designed properly from placeholder data.

Tooling options now

You don't need a production backend to prototype with real data. Depending on the project, we use one of these:

• Figma Make with a data source. According to Design Compass, the Payload integration brings databases, storage and auth into Make and code layers. That makes it realistic to build a clickable dashboard on top of a small data set.
• Code layers. For dashboards that need real sorting, filtering or charts, a code-backed prototype on the canvas behaves much closer to the final product.
• A simple CSV-backed prototype. For early layout work, a spreadsheet of 50 to 200 representative rows pulled into a quick prototype is enough to find most problems.
• Static frames with pasted data. Not glamorous, but pasting real rows into your Figma table component still catches length and script issues before you build anything interactive.

The October Figma updates summary also points to Lufthansa Systems' experience prototyping with external data, which is worth reading if you're making the case to a client.

Anonymizing client data for prototypes

Real data doesn't mean raw data. Client dashboards often contain personal information, financial figures or commercially sensitive numbers. Before anything goes into a prototype, and especially into an AI tool, we:

1. Ask for a sample, not the database. A few hundred rows chosen to include the awkward cases: long names, empties, outliers.
2. Replace personal data with realistic substitutes of the same length and script. An Arabic four-part name becomes a different Arabic four-part name, not "User 1".
3. Scale or shift financial figures so the shape of the data stays true but the actual numbers don't leak.
4. Check the contract and NDA for rules on where client data may be stored and which tools may process it.
5. Delete the sample when the prototype phase ends.

The aim is to keep the properties that break designs (length, script, distribution, gaps) while removing anything identifying.

[Waleed: add an example of an issue real data revealed on a dashboard project, such as the Almenasa analytics dashboard, without client-sensitive details.]

A stress-test checklist for bilingual dashboards

Before a client signs off on a dashboard, we run through this list in both languages:

• Longest real name, title and address in every column, with no broken layout.
• Mixed Arabic/English values render in the correct order.
• Largest and smallest real numbers fit, with consistent formatting and decimals.
• Negative values and percentages over 100 display correctly.
• Charts still read when one value is an extreme outlier.
• Every column has a defined empty-cell treatment.
• Filters that return no results show a helpful empty state.
• Dates show in the agreed calendar and format, including ranges.
• Tables stay usable at the narrowest supported screen width.
• Exported data (CSV, PDF) matches what's on screen.

Closing thoughts

Showing clients placeholder numbers feels safe, because the dashboard looks its best. But it postpones the hard conversations to the most expensive moment. Prototyping with a small, anonymized sample of real data moves those conversations to the start, when changing a column is a five-minute job. The tools now make it practical. For the broader layout rules we apply to admin panels, see my eight rules for SaaS dashboards, and the Almenasa Arabic analytics dashboard project.

Sources: Figma brings code and planning documents to the canvas (Design Compass), Figma product updates, October 2026, including the Lufthansa Systems case (SpyingBee).

FAQs