How to demonstrate complex products without empty states

Imagine you’re managing a complex digital product that has quite a few customers and a lot of features. Your users can input different kinds of data into your system, that gets sorted, formatted, and visualized. The latest feature you’re working on is close to finish, and you get a question from the marketing department:

The way of showcasing your feature is an essential question, regardless if it’s for an internal or external demo. If you’ve worked hard to develop something, you should show the new capability in the context of meaningful data, not just how it looks with an empty state.

If you would like to infuse your product with data, there are two main ways to do that: you either generate demo data or you use data mocking.

In this article, I will use three different expressions related to showing data, and before we dive in, I want to clarify what I mean with each phrase.

  • Real data: Real, user-generated data, sitting in your database. This kind is manually produced by certain activities, such as visiting pages, using features, clicking around, and creating new information.
  • Demo data: Data automatically generated to your system. The information is planted to your database by an automatic mechanism, a piece of code recurringly creating new values.
  • Mocking data: Fake data inserted artificially into your product. Here, the information is not coming from your database, but baked into the software layer, like every time pulling in a static XML file.

For complex applications where “dogfooding” (the practice of an organization using its own product) is not easily achievable, real data is out of the question. In those cases, you have two main options: you either generate demo data, or you start faking information.

The argument for Demo Data

Demo data is better than real data in case of sensitive details. If you’re generating data automatically, you won’t have any confidential corporate or personal information there. You’re using false names, numbers, titles, and descriptions. This way, it’s easier to show your software to just anyone, you don’t have to worry about showing something that can get you in trouble.

If you’re taking the demo data approach, the information shown would be consistent everywhere in your product. As it comes from a real data source, all the pages, lists, charts, and other visualizations would get it from the same database, creating unity. In addition to this, if you’re inputting figures manually to your application, that would amend the data that was previously generated.

Data generation, then database, then back-end, then front-end, then user interface
How demo data is going through the flow to be displayed on the user interface

Utilizing demo data also makes it easier to spot bugs, system errors and other inconsistencies. If something breaks in your frontend, backend, or underlying architecture, you’ll likely notice it. It’s especially true for calculated fields, when you’re taking real values from your database and processing through algorithms to generate a result.

Another advantage of demo data that it requires maintenance only from a few people. This activity includes checking the data generation from time to time, adding new demo accounts to a list, or fixing bugs in the automation. The only time you need to configure new data fields is when you’re building a new capability to your product that requires new sets of information.

The argument for Mocking Data

By mocking data, you can visualize every kind of information, especially where you don’t have control over the data. That includes technical response coming from 3rd parties, like from an API or other integrations. Additionally, mock data makes it possible to simulate circumstances that would be very difficult to create in a real-world environment.

With mock data, you’re able to display the same things again and again. As static information is pulled in in every case, you’re able to show the same information in various environments and on different days. Beyond that, accidental deletions, edits, or database issues can’t affect what is presented.

Fake data, then front-end, then user interface
How fake data is getting pulled into to be shown on the user interface

Fake data views are also simple to build. When your team is building a new functionality, they’ll be aware of what information it can display, so that they can program believable fakes. The simplicity also comes from the fact that they won’t have a dependency on other teams, and they don’t have to wait for central data setups.

One more advantage of mocking data that it doesn’t require a central governance. While demo data needs agreement on certain principles within the organization, mocking data usually happens on a page or component level. That means every team can come up with their own execution locally, and it doesn’t need synchronization with others.

Demo Data vs. Mocking Data

There are a couple of advantages to both approaches; nevertheless, they also come with a few sacrifices. I’ve collected five aspects to compare the two, so you’re able to see which would work better for you.

  • Consistency: Demo data is uniform across your product. As it comes from a real data source, you’ll see the same information in multiple different views. On the other hand, it’s possible to align on consistent fakes with mocking data but probably doesn’t worth the extra effort.
  • Organizational alignment: Showcasing demo figures needs internal principles on how to generate, maintain, and extend the data. In consequence, it requires more initial effort to kick off a similar project. The more teams you have, the more complex it will get to do the groundwork. In contrast to that, mocking data needs only a minimum agreement. If everybody knows which feature switch is used for the demo mode, then the teams can already start the development.
  • Effort: While demo data requires a notable initial effort, after that’s done, it doesn’t require too much work for maintenance. In contrast, mocking data doesn’t need an initial investment; however, it requires a constant development effort for new user-facing components.
  • Coverage: Demo data is compatible with all use cases that require your internal database, but that’s also the limit of the approach. With external integrations, you’ll probably need to use some data mocking anyway.
  • Troubleshooting: When testing your application, troubleshooting is easier with demo data, as it uses your technical infrastructure to power the user interface. By mocking data, this is simply not possible, and some of these fake data views might hide underlying technical issues.


There is no one size fits all. If you would like to showcase your product without empty states, your strategy will depend on your product and organizational setup. Altogether, it’s likely that you’ll need to take a mixed approach to serve the various needs.

To go ahead with a decision, think about the complexity of your product, the development team size, how your processes are managed, and how much authority your teams are having.


Please enter your comment!
Please enter your name here