Realsitic Data in Wireframes/Prototypes/Mockups?

18 Jul 2011 - 6:09pm
3 years ago
20 replies
2236 reads
Chris Bobbett
2004

Hi All,

I have been thinking lately about the process for creating mockups and in particular, the data they display. I'm curious about whether the data should be more realistic or completely generic. Is one more effective than the other during client/stakeholders reviews? And so on...

I know you are all busy with work and life but if you can spare a moment and share your feedback regarding the questions below, I would be very appreciative.

  1. When you are creating UX/UI design mockups (e.g. static wireframe print-outs, basic HTML webpages or highly interactive prototypes), do you use realistic, representative data or generic placeholder data (e.g. [Full Name Here] vs Jeremy Reinholm)? And why?
  2. If you do use realistic data, do you make just one realistic sample and repeat it until you have enough to fill the space required in the UI? Or do you vary all of it so they look unique?
  3. Are edge cases in your data important to you (e.g. long email addresses, phone numbers with international codes, etc)?

 

Thanks again for your feedback and time,

Chris

 

 

 

Comments

18 Jul 2011 - 7:05pm
hassan.schroede...
2009

On Mon, Jul 18, 2011 at 4:15 PM, Chris Bobbett wrote:

> 1) When you are creating UX/UI design mockups (e.g. static wireframe >   print-outs, basic HTML webpages or highly interactive prototypes), do you >   use realistic, representative data or generic placeholder data (e.g. >   [Full Name Here] vs Jeremy Reinholm)? And why? > 2) If you do use realistic data, do you make just one realistic sample and >   repeat it until you have enough to fill the space required in the UI? Or >   do you vary all of it so they look unique? > 3) Are edge cases in your data important to you (e.g. long email addresses, >   phone numbers with international codes, etc)?

I consider data the basic raw material of a site/application.

So in the past when creating live-html prototypes the first thing I've asked for is a representative data dump from the intended sources for the live app (DB, XML, raw text, whatever) and incorporated it into the prototype.

Using that, you're

3) more likely to see those edge cases sooner rather than later 2) showing something realistic looking, and 1) eliminating any "lorem ipsum" cognitive dissonance on the part of the audience; they can explore the interface without having to pretend much. Which is apparently tough for a lot of adults. :-)

This does assume a client with existing data. In the absence of that I generate something equivalent; more work, though, and less likely to help with #3.

FWIW,

18 Jul 2011 - 7:30pm
krystaylor
2010

For me, it depends on the stage of the project, the purpose of the project, and the type of project.

For MOST projects, I like to use real worst-case data.  The minimum amount and the maximum amount.  Mostly, I'm lazy and in a hurry, so I'll alternate the two.  Special or important projects require realistic data for all your spots, though.

Some projects, or very early in a new project, it's important to have people not focusing on the details - and so I'll use lipsum content in approximate amounts.  This lets them pay attention to only the things I need to discuss.  This is the exception, not the rule though.  

Hope that helps!

18 Jul 2011 - 7:52pm
Paul Pinkney
2009

1. I'm uncertain about your definitions of 'realistic' vs. 'representative' data.  However, I use data samples that represent the real world.  Ha - does that confuse the issue?  The reason for using realistic data is to make sure your design handles real world situations.  I've read studies in which designers didn't use realistic data and, for example, their designs didn't accommodate an absolute file name such as ~montgomery/scripts/thirdparty/johnstownuniversity/common/favoritetools/handleit.ksh.  Users were forced to scroll within a text field to see the full path, and in some cases, didn't fit on the screen at all.  Imagine if these paths appeared in a data table that users scanned, the only screen real estate you designed for this information was 15 characters, and all of the user's paths began with ~montgomery/scripts/thirdparty/....  The UI would likely be very difficult to use.  If you're designing a Web app, this particular example in a data table could push the entire layout to the right (in Western cultures, anyway) due to the lack of white space and force users to scroll the browser window horizontally, which is generally a huge usability problem.

2. I try to include a variety of data, especially when users need to scan the data to find what they need.  You might have a look at the design and notice that, for example, you need to group the data or some such so items people are looking for are easy to find.  Also, sometimes usability testing or reviews are hampered by people asking why the same row appears twice, in the case of data tables, when it shouldn't, which really detracts from the review/study.  I've occasionally tailored data for a particular customer to ensure the focus wasn't on the data but was on the design.  Perhaps that's the bottom line for this point:  try to ensure the focus ends up on the design and not the data.

3. See my answer to item 1, but I'd also say that if it's an extreme edge case, and if you'd have to degrade the design in favor of, say, 1% of the cases, but the product can still be used by the 1%, I'd design in favor of the 99%.  (Was that a roundabout sentence?)  It's probably controversial, but for example, it really annoys me when a DVD automatically has subtitles on, which I find really distracting.  I have to return to the main menu and go through a series of other menus to turn this "feature" off.  For the vast majority of people, subtitles don't need to be on and, in my opinion, shouldn't be on, because it detracts from the user experience.  And I'm someone who designs for accessibility all the time!  As always, keep in mind your audience, ethnographics, etc.

I've found that good ol' lorem ipsum works for paragraphs of text and such, but even lorem ipsum raises eyebrows and people ask what language that is.  *sigh*  So again, I'd design as much as possible for real-world situations and allow usability reviews and studies to focus on the design and not on the data.  I guess that's my mantra for the day.

I guess I'd mention one last thing, which I alluded to before:  If you're representing a list or table of data, by showing a fair amount of and a variety of representative data, you might reveal weeknesses in the design.  You might need to provide capabilities for grouping, sorting, search, facetting, or otherwise narrowing the results.  Perhaps there are other ways you could make it much easier on your user.  Perhaps you don't need to show all that data in the list, but only in the detail page for the hard-core users.  And so on.  Personally, it helps me think more critically about the information before my audience ever sees it.

Hope this is helpful.

18 Jul 2011 - 9:05pm
a2slbailey
2010

I use realistic data, especially in prototypes. I think it gives a more accurate sense of how the interface will perform in real life; I've definitely had participants in usability be confused by [Full Name Here]. If the prototype is supposed to be personalized (as with a portal) and I can't support personalization, I have resorted to things like "Welcome, Participant" which I prefer to Welcome Jane Doe.

This is a helpful site:
http://www.fakenamegenerator.com/

sb

20 Jul 2011 - 12:05am
shetty
2010

But what when you don't have data in your hand? Data suppose have to aligned with relevance? I usually go with relevant data if there's no actual data available.

20 Jul 2011 - 5:05am
Louise Hewitt
2010

Yes- I like to test edge cases and get clients/stakeholders thinking about what is actually going to fill those spaces. If I know actual data, I'll shove in some examples, If I don't I'll try to use something sort of likely (e.g. a international phone number for an international site, a variety of currency indicators for an ecom shop). 
Invariably this results in a lot of huffing and the response from all parties that I've "got it wrong". This is good. This is where you learn what it should be and the people involved start to realise that they have to think about this shit too! What will need to go in this box? How will it need to be validated. Will it fit? Who's going to write it?
But beware. I've done this too soon for some clients and ended up with a conversation that is solely focused on this micro data, and completely failed to get them to consider the broader concept being proposed.
Working with visual designers I've noticed the use of Charlie Brown style hashing to represent text (you know, like when Woodstock is talking). In sketch concepts I think this is great. Combine this and paper, and it becomes really hard for any one but the most pig-headed stakeholder to nitpick over the detail, allowing you to get engagement around the concept. When that's been honed, it's easier to craft a more specific digital wireframe or prototype and, yes, this is probably a good point to get content discussed and requirements for edge cases, validation, design etc.
Apply the mantra... It depends. ;)
Lou.

It usually results in On 19 Jul 2011, at 12:27, a2slbailey wrote:

I use realistic data, especially in prototypes. I think it gives a more accurate sense of how the interface will perform in real life; I've definitely had participants in usability be confused by [Full Name Here]. If the prototype is supposed to be personalized (as with a portal) and I can't support personalization, I have resorted to things like "Welcome, Participant" which I prefer to Welcome Jane Doe.

This is a helpful site:
http://www.fakenamegenerator.com/ [1]

sb

19 Jul 2011 - 1:58am
regiskuckaertz
2009

Hi Chris,

You might find useful a document published by Dan Brown addressing this very topic.

http://blog.greenonions.com/2009/05/01/poster-representing-data-in-wireframes-ia-summit-2005/

The answer to all your questions is more nuanced than one might think, and I think this document gives a very good overview of the pros and cons of each technique.

Hope it helps.

—Régis

19 Jul 2011 - 4:05am
Alan James Salmoni
2008

Hi Chris,

1) Yes and no. It really depends. I've done research where I've tried to populate wireframes with realistic data. One recent example was populating a series of wireframes with account data that was quite close to what the participant actually had (they were existing users) just to provide a context that was similar to their own - it seemed easier for them to just accept the data and work as normal. There is the danger that the participant will focus on that rather than the issues you will want to focus on. Most wireframes, however, have used generic data.

The important thing is the research question: does providing realistic data help me to answer the research question?

2) Again, the research question and users' context is key - if I'm testing with an existing user, I try to make the test match their 'life context' as closely as I can (if it fits the research question), but this isn't always possible (e.g., registration for a new user). If I cannot, I'm happy to repeat data which means less work for me and one less uncontrolled variable / confound.

3) Edge cases: definitely. I like to stress-test a design with extremes just to ensure the design can cope (e.g., a search returning thousands of matching document with the same title: how can the design help users discriminate between them? Or what about if someone has multiple phone numbers or addresses?)

Alan

Thought Into Design Ltd (http://thoughtintodesign.com)

On Tue, Jul 19, 2011 at 7:24 AM, Chris Bobbett wrote: > Hi All, > > I have been thinking lately about the process for creating mockups and in > particular, the data they display. I'm curious about whether the data should > be more realistic or completely generic. Is one more effective than the > other during client/stakeholders reviews? And so on... > > I know you are all busy with work and life but if you can spare a moment and > share your feedback regarding the questions below, I would be very > appreciative. > > 1) When you are creating UX/UI design mockups (e.g. static wireframe >   print-outs, basic HTML webpages or highly interactive prototypes), do you >   use realistic, representative data or generic placeholder data (e.g. >   [Full Name Here] vs Jeremy Reinholm)? And why? > 2) If you do use realistic data, do you make just one realistic sample and >   repeat it until you have enough to fill the space required in the UI? Or >   do you vary all of it so they look unique? > 3) Are edge cases in your data important to you (e.g. long email addresses, >   phone numbers with international codes, etc)? > > > > Thanks again for your feedback and time, > > Chris > > > > > > > > (((Ple

19 Jul 2011 - 4:23am
uxgrace
2010

 

When creating mock-ups people want to see as many screens as possible with life-like data but it is impossible to keep everybody happy and look out for every detail that you know that is going to be scrutinised.

I create a single screen for each "main section" with as many diverse data possible and then I isolate different components to show their behaviour separately. It is like focusing on areas of interest omitting the behaviour of the rest of the application. That would mean that I should have done a great job in componentising and patterning first.

In this way, stakeholders see what they expect to see on main screens and they are allowed to scrutinise  while on secondary screens their mind fills in the blanks and focus is on functionality.

 

25 Jul 2011 - 11:29am
Chris Bobbett
2004

Hi uxgrace,

Quick clarification...when you isolate components and let the reviewer "fill in the blanks," is the UI devoid of all data? Or is it just generic placeholder data e.g. [Fullname]?

Thanks!

19 Jul 2011 - 9:36am
adamgrabo
2011
I believe it really depends upon who is your audience for these deliverables. Ipsum Lorem or placeholder data seems to work best for people who have previous experience with lower fidelity deliverables; they seem to be better able to look past the data and look at the big picture. On the other hand, people who are seeing mockups or wireframes for the first time can get hung up on the quality of the data, even momentarily. When I used Ipsum Lorem in the past for user research I would get a LOT of questions about "What language is this?" Most of the time the question was brought up jokingly but it just became a common distraction for myself and the participants. For that reason, I try to use realistic-looking data only when doing user research.
21 Jul 2011 - 9:28am
vutpakdi
2003

I've found it depends as well.

I generally use data of about the right size/content, but not necessarily realistic if the distribution is limited to people used to working with me.

If I am showing things to people who aren't used to working with me or the distribution is pretty broad, I prefer realistic data because some people can get hung up on unrealistic data.  Our users and domain experts are highly technical, so, sometimes, if I show an unrealistic value in, say, "pressure" they get stuck on that detail rather than seeing the interface as a whole: "the pressure would never be that high with that flowrate!"

21 Jul 2011 - 6:05pm
Jean-Anne Fitzp...
2004

I agree that unrealistic data can be distracting, particularly for a technical audience. We recently did some usability testing related to IPv6, and some of the participants told us far more than we'd ever wanted to know about why our example addresses were nonsensical! 
But of course, it does depend on context and your audience :)
   J.A.

On Thu, Jul 21, 2011 at 7:36 AM, Ron Vutpakdi <vutpakdi@acm.org> wrote:

I've found it depends as well.

I generally use data of about the right size/content, but not necessarily realistic if the distribution is limited to people used to working with me.

If I am showing things to people who aren't used to working with me or the distribution is pretty broad, I prefer realistic data because some people can get hung up on unrealistic data.  Our users and domain experts are highly technical, so, sometimes, if I show an unrealistic value in, say, "pressure" they get stuck on that detail rather than seeing the interface as a whole: "the pressure would never be that high with that flowrate!"

(((P
25 Jul 2011 - 2:05pm
Dan Brown
2004

Hi Chris,I wrote about this (a helluva long time ago) and identified five different approaches to incorporating content and data in mock-ups:
http://boxesandarrows.com/view/representing_content_and_data_in_wireframes_special_deliverable_10


These days, we tend to use real content whenever possible.
Hope this helps,-- Dan

On Mon, Jul 18, 2011 at 7:38 PM, Chris Bobbett <cbobbett@gmail.com> wrote:

Hi All,

I have been thinking lately about the process for creating mockups and in particular, the data they display. I'm curious about whether the data should be more realistic or completely generic. Is one more effective than the other during client/stakeholders reviews? And so on...

I know you are all busy with work and life but if you can spare a moment and share your feedback regarding the questions below, I would be very appreciative.

1) When you are creating UX/UI design mockups (e.g. static wireframe
  print-outs, basic HTML webpages or highly interactive prototypes), do you
  use realistic, representative data or generic placeholder data (e.g.
  [Full Name Here] vs Jeremy Reinholm)? And why?
2) If you do use realistic data, do you make just one realistic sample and
  repeat it until you have enough to fill the space required in the UI? Or
  do you vary all of it so they look unique?
3) Are edge cases in your data important to you (e.g. long email addresses,
  phone numbers with international codes, etc)?

 

Thanks again for your feedback and time,

Chris

 

 

 

(((Please
26 Jul 2011 - 5:21pm
Chris Bobbett
2004

Hi Dan,

Thanks for the link. Another reader pointed me to your article as well. It covered much of what had been floating around in my head.

Thanks again,

Chris

26 Jul 2011 - 11:05pm
Eric Scheid
2006

One last link to round out the thread ..

http://www.fakenamegenerator.com/

Generates culturally appropriate names, addresses, phone numbers etc. Very nifty.

You now have no excuse for writing this:

John Q. Smith, 123 Somewhere St, Anytown, 90210 John Q. Smith, 123 Somewhere St, Anytown, 90210 John Q. Smith, 123 Somewhere St, Anytown, 90210 John Q. Smith, 123 Somewhere St, Anytown, 90210*

  • as a non-US person I can validly claim this is the only US ZIP I know of, and yes this is showing my age =P

e.

25 Jul 2011 - 6:05pm
JRinDC
2010

I'm glad to see that most folks are responding that they tend to use realistic (if not real) data for their wireframes. I know the conventional wisdom has been that too realistic a wireframe too early in the design process will distract users from the issues you want them to focus on, but I have found that many adults seem to have a hard time with -- and are more likely to be distracted by -- too vague a wireframe or non-realistic data. E.g. I got the same questions about why I used foreign language text when I used lorem ipsum text in a mockup. With real(istic) data, I have found that some customers are more willing to look past the data and focus on structure and layout, features, etc. Of course, some do get side-tracked, and I have to remind them that the data and the design are separate for the purposes of the meeting.

J.R. Key

26 Jul 2011 - 5:16pm
Chris Bobbett
2004

Hi Everyone,

Thank you for your feedback!! I appreciate you taking time out of your day to share your thoughts. It has been very helpful. I can tell you we have had very similar experiences (highly technical individuals who explain how our values used in the UI mockup are not possible, clients getting distracted by the data instead of focusing on the concept or key functionality). We have had many fewer problems with clients getting tripped up by the use of lorem ipsum. Most of our mockup review hiccups revolve around singular data points.

As most of you noted, and I would agree, the most important factor in determining the level of realism needed in a mockup is the audience reviewing the design and their familiarity with the Design process and its deliverables. I do still however have a strong prefer for realistic data whenever possible. I think it does a better job of providing proper design constraints early in the process so my chance of creating a successful, long term solution is significantly increased.

Thanks again for your responses.

Have a good one,

Chris

26 Jul 2011 - 11:05pm
tonyzeoli
2008

I'll chime in here and say that, in my experience, using realistic data gives the client the ability to assess how their data is going to look. Armed with that information, they can make decisions to expand, revise, or retract. For me, it's better to make the prototype as real as possible. For example, I try and make my wireframes as pixel perfect as I can, down to the gutters, padding, leading, and kerning. Most of my work is in media with content, so it's important that they see their content in the prototype, as editorial direction and advertising may be based on layout and functionality. I find when it's not pixel perfect, that leads to ambiguity, but I also agree that I may inadvertently lock them into a direction and lock out other ideas. It's a risk that I'm willing to take.

On Tue, Jul 26, 2011 at 8:07 PM, Chris Bobbett <cbobbett@gmail.com> wrote:

Hi Everyone,

Thank you for your feedback!! I appreciate you taking time out of your day to share your thoughts. It has been very helpful. I can tell you we have had very similar experiences (highly technical individuals who explain how our values used in the UI mockup are not possible, clients getting distracted by the data instead of focusing on the concept or key functionality). We have had many fewer problems with clients getting tripped up by the use of lorem ipsum. Most of our mockup review hiccups revolve around singular data points.

As most of you noted, and I would agree, the most important factor in determining the level of realism needed in a mockup is the audience reviewing the design and their familiarity with the Design process and its deliverables. I do still however have a strong prefer for realistic data whenever possible. I think it does a better job of providing proper design constraints early in the process so my chance of creating a successful, long term solution is significantly increased.

Thanks again for your responses.

Have a good one,

Chris

28 Jul 2011 - 8:05am
whitneyq
2010

I agree with everything everyone has said about the value of sample text that reflects what will really be in the app. But there's one more reason to use realistic text - it's a great way to make sure that the people who will be writing the text are part of the design process.

Isn't that what the content strategy people have been trying to say?

I worked on a project to collect research information on a particular technical subject into an online site. The goal was to help medical researchers make better use of evidence-based clinical practices. It would have been pretty easy to just design this with greeking text, and treat it as a UI problem.

But, when we started to work with users on early prototypes, we found that they simply could not discuss what they were experiencing except in relationship to the content and form of the information.

"Did they want to be able to comment?" we asked. They replied "What would I be commenting on?"

We involved the content managers and started prototyping different ways of writing the abstracts, not just different boxes to put them in.

We tried different variations. We did head-to-head comparisons. We let users show us what to keep and what to cut.

In other words, we took the design of the information as seriously as the design of the UI and interaction.

Not surprisingly, we learned a lot about the quantity, voice, layout, and technical emphasis that affected how the content team approached the ongoing work of this site. And, we learned a lot about how to engage this audience with the kind of content they would actually use in a format they understood.

One of the effects of this site has been to bring together a community of specialists in a small field in a new way, so the value has gone well beyond a few bits of HTML and database code.

Syndicate content Get the feed