Keeping your data real –

Dangerous placeholder content

*This post is from another blog I wrote some while ago, but decided to revisit/update it and freshen it up. This is something which is still important to bare in mind.

Placeholder text can be unavoidable during development as a short term solution. For seeing how the page looks full of text. But how useful is ‘lorem ipsum’ and fake data to your overall build process? Spoiler… not very!

In an age where ‘content first design’ is a successful method of any design workflow, dummy content does little towards this. Content after all; is what people will be visiting the site for. Content shouldn’t be considered the ‘last layer of building a site’.

Whilst building or presenting to a client, you’ll learn little by using ‘lorem ipsum’, or any other form of dummy text for that matter.

“Without context what problem are we solving?”

We should allow the data to constrain the design and keep it content focused. This is why it’s so important to ensure that data is realistic; to ensure that we’re solving the correct problem.

I’m not only talking about lorem ipsum although it’s the obvious one, i’m referring to any dummy content used.

Source ‘’

Visually, it’s important to see any content actually in context with the page:

  • Does that content area need to be so large?
  • Can that content be split up into different sections?
  • Is that content even needed?
  • Is that content so important it may need to be in a dominant position?
  • How is that content going to respond on multiple devices?

None of these basic questions can be answered without real and ‘realistic’ content. Without context what problem are we solving?

It’s a similar philosophy whilst working with data items or tables. How can you be sure that your 6 column table will work responsively without having ‘real formatted’ data? Answer: you can’t.

“Content shouldn’t be considered the ‘last layer of building a site’.”

When it comes to tables, you can really benefit by using real data. Whether this be hard coded or just a simple .JSON file, make sure the data reflects the real content and any permutations it may have. For example have you considered:

  • One of the table cell’s may have 7/8 words?
  • Some of the data may have additional columns compared to others
  • Some of the content may have links
  • You may need currency symbols
  • How many decimal places do you need?

All of the above falls into information architecture, which faces it’s own difficulties during a build process let alone leaving this until the end of a project life cycle.

If the client hasn’t got any content written up yet, try to encourage them to supply a summary of what content and what format (lists, bullet points, quotes and paragraphs etc) the content will be in. This will help you define what kind of text presentation you will need to design for.

If you’re developing; try to identify what table data will be shown. You can then use a site like ‘Mockaroo’ which will allow you to define fields and produce a ‘mock’ file for you. These sites tend to give you options to export as .json, .csv and .xml as well as others. Although this is still classed as ‘dummy data’, by having relevant field names and data types it’ll still be a lot more useful than data with no context.

You definitely don’t want any of your dummy content to end up in production. Check out this hilarious, yet scary link: ‘Lorem Ipsum Gone Wrong

I totally understand that content will change, and additional content may be added going forward but it’s important to understand the real content and any formatting as early as possible

After all, as they say… ‘Content is King’.


If you liked this post, please hit both the follow and heart buttons below. You can also follow me on twitter at @paul3to to keep up to date with future posts.

Author: Paul Champion

Collect by: