True. But a warning… acquring truly real data may actually violate privacy provisions of a client. And even if it doesn’t, you just never know where some presentations may end up. Is this a big problem? Probably not. Still, the wrong stuff in the wrong place and you could have a crazy large liability problem that started with a totally innocent and well-meaning plan. I’d suggest if you pull real data, you switch about the fields from record to record so nothing represents a real record.

Is greeeking useful in wireframes? Totally depends on the project, your team and the audience for the wireframe.

A stakeholder or a designer may be able to relate to it more when it’s real content, a stakeholder needs to understand the consequences of their decisions. But also for the person creating the wireframes, I find that even when you have done a full content audit and it all appears simple, working with real data while you are working on the wireframes highlights how the layout could work under the strain of real content.

However when you do wireframes that go to the development team greeking is pointless and realistic text is misleading, so best then to either annotate the Greek text or give them the attribute field in brackets (or content tags as mentioned above). How to annotate the wireframes? This then depends on the complexity and scale of the project. The top layer of the presentation of these attributes/content tags can be listed on the wireframe itself and then could reference the content object (metadata) model field which is often another document in itself.

Great thoughts!

I like to use actual data, data from my client when possible. (Though it’s not hard to find “real” names, addresses, and phone numbers if that’s all you need.) Making this request often reveals who on the team is closest to the real users, which is a good thing to know.

Working with a small set of real data lets you find out about the real state of the data, for example the addresses might be in all upper case, or the name field is combined, or the part numbers won’t really be available until a big data entry project takes place.

Real data leaves less to the imagination. For example, “GP 3000 700X23C RED/BLK” is obviously a popular road bike tire manufactured by Continental to anyone in the bike industry, but I bet some UI designers or developers would say it’s a “confusing” description of a tire, since it doesn’t even use the word tire. By leaving it as a label, “[Description]“, people will fill in the blanks with their own assumptions, postponing decisions about how actual data will eventually appear. This may or may not be a good thing: sometimes you don’t want to get hung up on examples, but sometimes, that’s the best way to spark the right discussion.

A tip: Use Google Sets when you can only think of a few examples of something.

(btw, my favorite long name for wireframes is Jonathan Balasubramanian.)

But when it comes to usability testing on a paper prototype (or selling the designs to non-technical clients) they find the placeholders a distraction – they don’t get a view of the application in a real world context.

To get around this I convert the ‘ContentTags’ into human-readable content (dummy data). This way the users are not distracted by tech-speak -improving the accuracy of the usability test.

So in my experience your technique is right-on, but the use of dummy data is still valuable in certain situations.

See you in Montreal!