Please note: This site's design is only visible in a graphical browser that supports Web standards, but its content is accessible to any browser or Internet device. To see this site as it was designed please upgrade to a Web standards compliant browser.
 
Signal vs. Noise

Our book:
Defensive Design for the Web: How To Improve Error Messages, Help, Forms, and Other Crisis Points
Available Now ($16.99)

Most Popular (last 15 days)
Looking for old posts?
37signals Mailing List

Subscribe to our free newsletter and receive updates on 37signals' latest projects, research, announcements, and more (about one email per month).

37signals Services
Syndicate
XML version (full posts)
Get Firefox!

The Challenge of Designing the "Blank Slate"

19 Sep 2003 by Jason Fried

We’re currently working on a web-based application that will start off with no data, but will grow and “organize itself” quickly as more and more people use it. When we designed the UI, we designed it as if it was flush with data. Data everywhere. Data in every list, every post, every field, every nook and cranny. And it looks and works great.

However, the natural state of the app is that it’s devoid of data. When someone signs up, they are basically starting with a blank slate. Much like a weblog, it’s up to them to populate it — the overall look and feel doesn’t quite take shape until it full of posts, data, comments, sidebar info, etc.

Unfortunately, the customer will decide if they like the application at this blank slate stage — the stage when there’s the least amount of information, design, and content on which to judge the overall usefullness of the application. In other words, they won’t know what they are missing because everything is missing.

Over the years I’ve noticed that most designers and developers take this blank slate stage for granted. They never really spend a lot of time designing for the blank slate because when they develop/use the app, it’s flush with data (for testing purposes). Sure, they may log-in as a new person a few times, but the majority of their time is spent swimming in an app that is full of data. Unfortunately, every single customer sees the blank slate before they see the “full slate.” They base their opinion of the app/site on the blank slate. Ignoring the blank slate stage is one of the biggest mistakes a designer/developer can make.

We’ve decided to use the blank slate stage as an opportunity to insert quick tutorials, help blurbs, and even links to example screenshots to get people started. If you haven’t posted anything yet, we briefly explain how to get started, what a post will look like, etc. We’ve found that these little vignettes really help people get started. They set expectations and help reduce frustration, intimidation, and overall confusion. They work.

How have you handled the blank slate stage on your own projects?

18 comments so far (Post a Comment)

19 Sep 2003 | birdman said...

More importantly: A *prospective* customer usually sees the populated state of an application -- and is then suddenly faced with a blank slate after buying -- which can be very intimidating and may cause the person to wonder if s/he made the right choice.

19 Sep 2003 | Ryan Mahoney said...

Man, my application framework suffers from the same problem. A few times new clients login for the first time and tell me (over the phone) that they are seeing a blank screen. I start thinking - oh no, maybe the HTML or CSS has a bug and they are getting nothing! But then I find out the screen isn't blank (it has navigation) - there is just no content to see so the customer feels totally lost.

Althought I have experienced this numerous times I had not yet identified the problem (or solution...). The "Blank State". I need to address the blank state.

And I thought I was going to get the weekend off ;)

19 Sep 2003 | Matthew Oliphant (formerly fajalar) said...

This makes me think about Google (I know, I know too much Google everywhere). But Google's start page is, essentially, a blank slate; it is up to the user to fill in the content by providing a search term.

The only blank slate project I have worked on, we did what you did. Take the opportunity to tell the user why they are there, what they can do, what it will be like. Definitly better than what some sites do: a splash page with grpahics, little to no text and a link Enter.

It starts out being about orientation, then about goes on to be about expectations. If you can orient the user, set expectations (that you intend to and can meet of course) right from the beginning, you will hold people longer and keep them from "feeling dumb" about the choices they make.

19 Sep 2003 | Brad Hurley said...

Nick Bradbury's RSS reader, FeedDemon, comes with a bunch of RSS feeds pre-installed. I've read at least one software review that commented on what a wise move this was, as it allows the user to dive right into using the software without having to first learn how to subscribe to an RSS feed so they have something to look at.

19 Sep 2003 | Scrivs said...

I have put some thought into this (a whole 2 minutes) and was thinking that your solution is probably the best method to go about it. However, what happens after the user posts to the site and then all that helpful information disappears? Then I figured that the "blank slate" page would just be a reproduction of the "help" page or something.

19 Sep 2003 | JF said...

However, what happens after the user posts to the site and then all that helpful information disappears? Then I figured that the "blank slate" page would just be a reproduction of the "help" page or something.

We're still playing with some ideas, but what we're considering is removing a "help nugget" once someone has completed that action. So, if there were 5 things you could do, and you did 2 of them, the help nuggets related to the remaining 3 would stay until you completed those.

19 Sep 2003 | alan taylor said...

One route I've taken a few times is to put a brief summary of what to expect in the blank space, like a small friendly invitation to 'step inside, this will work just fine'. If you front-load the UI with a ton of data, I've found that the user reaction tendws to be 'ugh' - as in too much data, all at once. Let the functionality flow in and build as the user might need it.

As an example, I recently made a re-work of Amazon Light using XSL/CSS and ran into the problem of 'what to put on the homepage'? I'm not going to market anything, and can't guess why the end user may be there, so I ended up using a generic invitation/explanation. I don't know if it's the best solution in the world, but it suits the goals of the site.

19 Sep 2003 | Antonio Cavedoni said...

Speaking of something that should really need a blank state redesign, the new http://www.upcoming.org/ website is a pretty good example.

19 Sep 2003 | Jack said...

Inserting tutorials and the like is definately a good move - wikis tend to do this, I think. I remember first coming across wiki type sites, and not really getting them. Downloading and installing one (I forget which) immediately clued me in - a blank wiki would've confused me further, but one populated with pages that simultaeneously provided information on using the wiki and demonstrated the format's capabilities got me started quickly.

As others have mentioned, it's a fine line - too much extant information is overwhelming/downright irritating, so help nuggets that react to initial use is probably a good plan too. Although it should be user-sensitive, otherwise you risk a new member of the team logging in to find a data-rich site with no indication of how he should add content.

20 Sep 2003 | Will Parker said...

Our company - or at least the small division I work for (which here shall remain nameless to protect my paycheck) - uses the blank slate areas to post text coaching the user regarding the kind of content that will be presented in the area, along with a statement of how the user can start the process of filling the blanks.

For example, "Click the Foo widget to create a new Foo object".

Once the user has taken the action, the coach content is replaced by the real content, never to return. Since we have a fairly comprehensive help system in our apps, we assume that the user can use help to jog their memory when necessary. We're only trying to get past that initial 'Now what do I do?' moment.

BTW, if the UI with which the user is supposed to interact hasn't tested out as being particularly discoverable, we might include a small screenshot in the coach text to help orient the user, but under no circumstances would we go beyond two or three simple sentences conveying a single directive.

This is not an appropriate entry point to the help system, nor should you attempt to make up for unclear design by cluttering the opening view of the interface with a lot of expository text.

20 Sep 2003 | Steven Garrity said...

We've run into the "Blank Slate" problem ourselves when designing The silverorange Intranet. We're opting for easily removable example content.

20 Sep 2003 | Geof said...

The only problem with example content is that people will then use that example content as a guide for developing further content. If you've got a more open-ended design--and from reading Jason's post, it seems to me that you've got a powerful toy sitting there that would make a "Hello, world" post a bit like using your brand new Ferrarri to drive down to pick up the paper at the end of the driveway--you either need lots of varied example content or a member of your team who's willing [and paid] to sit with the customer for a couple days and point out possible ways to do stuff.

This reminds me of last summer when I was looking for a new car when I thought my truck had been totaled. I test-drove a sports car, and the saleswoman rode with me. She actually had to encourage me to open up a can of turbocharged fury and really put the car through its paces. Had I driven it by myself, I'm not sure that I would have tried to open up and left fly with that little WRX. Sad, no?

21 Sep 2003 | mike said...

I had the experience of... experiencing a certain 'networking' site recently and found just what you are talking about. The blank slate left me feeling like things were, well, not very well done really. There were 'sections' here and there on my screen that were empty, that I needed to 'populate' and all in all, in a weird way, it was both overwhelming and underwhelming.

Populating with help-style content can work well, but alas it can inhibit creativity, as has been mentioned, however for the non-experienced it can be quite useful. Take osCommerce as an example - for the uninitiated it tries to make it easy to get a web-store up and running, those with imagination and know-how can take it much further though.

It reminds me of learning a coding language - not until you get to know the ins and outs do you begin to see the possibilities - perhaps you need a 'zengarden' for your new app? Or form of 'product tour' - maybe that's why you posted that request a while back?

All in all, looking forward to seeing misto... if that is what this is all about!

21 Sep 2003 | Randy said...

Great call, JF. This is a big issue and I've found it's ignored more often than not. I guess it's a lot like Contingency Design. Most people don't see errors when they test their sites ('cause they know how to use 'em), so they don't pay attention to the design of the errors.

21 Sep 2003 | iva said...

We have the same dilema in our web based CMS. We've tried solving the 'blank state' issue by prepopulating client start sites with easily removable/modifiable template-based placeholder content that shows the structure of the content most likely to appear in different areas. For example, if we know what the site structure will be like, we may create a few dummy pages to show article content structure, with place holder text like: title here, paragraph 1, paragraph 2 and so on. We also add some automated features like all navigation, site index, page counters, snail trails, error pages and such. If design is available, it's often implemented in our templates before content contributors begin as well. If not, projects look like a prototype with default bare-bones styling. This process has worked very well for us. We've thought about tutorials or things like "click here to add content" but decided to stay away because, as someone else mentioned, clients may wonder why those features dissapeared once they start populating with their own content.

22 Sep 2003 | Andy Baio said...

As Antonio pointed out, I'm having the same problem with Upcoming.org. Even though I designed it with a blank slate with almost no example data, I admittedly didn't focus on providing examples or tutorials for people at all (mostly because of lack of resources; it was done entirely in my spare time for personal enjoyment).

If anyone wants to help me improve the site, please e-mail me. I could badly use the feedback from some experienced UI gurus.

24 Sep 2003 | Ron Phillips said...

I like to put obviously fake (hopefully, mildly entertaining) data everywhere. That "blank slate" is intimidating for a designer, let alone a new user.

It's kind of like "greeking" in graphic design, except with some cognitive value so it serves as an example of what could be for the user.

I find that people treat that silly data kind of like "easter eggs" that lure them into involvement with the app. They get a mild giggle, it relaxes them (none of this is that important) and they explore more freely.

Comments on this post are closed

 
Back to Top ^