Putting “placeholders” in the application user interface is a bad practice that conflicts with Agile development methodology, confuses users, gives engineers a false sense of accomplishment, and should be banned. If a feature or object isn’t serving some purpose today, it shouldn’t be in the user interface at all.
Image courtesy Kriss Szkurlatowski
User Interface Placeholders Cause Many Problems
User interface placeholders cause a long list of problems that you will quickly encounter if you do usability testing with a good service such as UserTesting.com or put the pre-release application in the hands of actual prospects and customers.
- UI placeholders create extra communication overhead when writing scripts for usability testers or emails to known beta testers. You don’t want to blindside pre-release product testers by failing to disclose the presence of non-working functionality in the user interface and forcing them to figure out what’s a placeholder by trial and error. Therefore, if you’re giving usability testers or beta testers access to pre-release software and it has placeholders, you’ll have to document for them what the placeholders are. This creates extra work for whoever writes the usability testing scripts and product release notes and extra complexity for whoever reads them and tries to remember their content.
- UI placeholders force users to waste time distinguishing between intentionally non-working placeholders and unintentional application bugs. When users are using software for the first time, they need to figure out what each feature and user interface object does as well as how they are intended to work together. If every user interface object is expected to perform a useful function (or at least inform the user, as with UI messaging), anything that doesn’t work immediately stands out and is recognizable to the user as an application bug. If the user interface has placeholders, each time the user encounters one and tries to use it, they will respond with surprise when it does nothing and will have to stop several seconds and try to figure out why the object didn’t respond to their action. Intentionally-created user interface problems called “placeholders” also provide camouflage for unintentionally-created problems called “bugs.”
- UI placeholders make it harder for everyone (including the development team) to spot bugs. It isn’t just external users who are harmed by UI placeholders. When the application UI is cluttered up with intentionally non-working UI placeholders, members of the development team have to remember in their own heads “Oh right, this is SUPPOSED to not do anything; it’s just a placeholder.” This increases the mental burden on development team members. Plus, when they encounter something that is not functioning, they may wrongly assume or misremember it to be a placeholder and then fail to file a timely, needed bug report as a result.
- UI placeholders confuse users. Users will sometimes see a menu item or link in the user interface and think it means something other than what the designer intended. If the object is functioning, the user can try it out and quickly discover its true function and realize that the need they have must be addressed by a different feature. But when the object is a non-working placeholder, the user has no way to discover through experiment that the object is intended to perform a different function. The user may wrongly conclude that the non-working placeholder was intended to address their current need and is failing to function because of a bug. In turn, they will then give up searching for the working feature elsewhere in the product that is actually supposed to address their need.
- UI placeholders distract users, slow them down, and interfere with usability and beta testing. The more objects there are on the screen, the longer it takes for users to find the particular object they are looking for. UI placeholders are clutter by definition. They take up space on the screen but perform no useful function. This wastes precious seconds or minutes during 15-minute long online usability testing sessions.
- UI placeholders are incompatible with Agile development methodology. In Agile development methodology, the team should release a potentially shippable version of the product at the end of every sprint. By definition, shippable products don’t (or at least shouldn’t) include placeholders for future work. Therefore, a development team that puts placeholders in the user interface is violating one of the core disciplines of Agile development methodology. They are getting away from the discipline of regularly returning the product to a fully working state. This increases the risk that the product’s true state will become unknown over time. In addition, putting a placeholder in the user interface is “programming ahead.” It presumes that what the development team will do in the future is known in advance and well-understood enough for a placeholder to be constructed in the first place. That’s a bad practice because one of the core observations motivating Agile is that decisions made in the future are more likely to be correct since you’ll have more and better information in the future. So why prejudge the future by building a placeholder now?
- UI placeholders are incompatible with the conversational model of software development. When developing with user stories, someone writes a user story which is the basis for a conversation between the engineer and the product owner. That conversation is the basis for what actually gets built. Engineers stick in placeholders in a hurry and never in my experience talk to the product owner about that decision in advance. Therefore, using placeholders lures the engineer away from the “talk first, code second” model of development that yields better products sooner with less effort.
- UI placeholders tend to remain placeholders longer than originally expected. An engineer who puts a placeholder in the user interface may expect that they will work on that area of the application soon. They may be wrong, in which case what was expected to be a placeholder for a brief period may linger as non-working clutter in the user interface for weeks or months on end.
- UI placeholders clutter up screen shots and force the documentation team to document non-working features or produce incomplete documentation. As development proceeds, the documentation team will take screen shots of the application UI to include in the product documentation. If there are placeholders on the screen, they will appear in the screen shot. The documentation team then faces a bad choice: they can either document that the user interface serves no purpose (which is extra work for them that will have to be undone later), or they can ignore the presence of the placeholders (which causes their documentation to be incomplete and the user to have no explanation).
- UI placeholders give engineers a false sense of accomplishment. Engineers work hard and are understandably excited about sharing with users their vision of where the product is going. Sticking a “coming soon” placeholder in the user interface may give them a false sense of accomplishment as if they’d actually built a working feature. This causes their internal sense of where the application is to get out of synch with the true state of the product and corrupts their technical souls. Engineers should save that special feeling of accomplishment for when a feature is functioning, not for when they put a placeholder in the user interface.
Reasons People Give for Putting Placeholders in the User Interface
Since user interface placeholders have all these bad effects, why do people put them in? I have heard people give the following reasons for putting placeholders in the application user interface.
- It shows users what’s coming. This may be true, but the benefits of showing intent in this way are slight and greatly outweighed by all the problems outlined above. There are many better, less problematic ways for a product development team to communicate its future plans to users. It can post them on a blog or on a message area within the application. It can mention future plans in the help documentation. It can explain future plans in email greetings to new users. It can solicit input for the product road map in discussion forums and talk about future plans there. The best way for a team to show its direction is to efficiently add useful working functionality as quickly as possible over time, not to clutter up the product user interface with non-working features.
- It saves time for engineering. When an engineer is building a menu that is intended to have six items and only has the working code for four items, it may save the engineer a small amount of time to put in all six menu items at once. But once again, the benefits are slight and are greatly outweighed by the disadvantages listed above. When engineering convenience conflicts with user convenience, user convenience must take precedence.
The Occasional Benefits of Placeholders Are Outweighed By the Downsides
When an engineer has put a placeholder in the user interface, I have occasionally seen users attempt to use the placeholder in an unexpected way that has in turn provided the team with an idea for future product development. For example, one of my development teams once had a placeholder user interface for a non-working faceted search feature. During usability testing, we saw a usability tester attempt to click on the name of the object in the faceted search UI in order to navigate to a presumed list of that kind of object. Watching that, we realized that making the faceted search items clickable links might be a good idea, so we resolved to try that in a future product release. I’m not saying that user interface placeholders never have any good effects. Rather, I believe that their negative effects vastly outweigh the positive ones. In that instance, for example, we could have waited until the basic faceted search was working to put the faceted search interface in the product, run the usability test at that point, and then have discovered the new idea as a side effect of a working basic faceted search feature instead of as a side effect of a non-working user interface placeholder with all the attendant downsides.
Acceptable Related Practices to UI Placeholders
If you want to reserve space on the page so that it lays out as intended until a planned future object is added, using CSS or an invisible GIF as a “spaceholder” to reserve whitespace on the page is perfectly acceptable. What users can’t see won’t hurt them. It’s simply whitespace on the page, which is neither distracting nor confusing. Users’ eyes will glide right past empty whitespace on the screen and they will focus on what is actually implemented.
Putting placeholders in a user interface mock, and even doing paper prototyping sessions with the mocks, is fine as well. User interface mocks are the right place for a placeholder because they help the team to see the intended finished user interface before they start coding. Companies ship products, not mocks, so the Agile practice of regularly releasing a potentially shippable product is not violated.
Partially implementing a feature so that some useful functionality or information (though not all intended functionality) is provided may also be acceptable. The partially-implemented feature is providing some utility, so the cardinal rule of “every object in the user interface must perform a useful function” is not violated. But realize that there are risks to this approach. For example, if you put words on a page as informational updates that are intended to become clickable navigation links in the future, people may wrongly assume the words are links and attempt to click on them, slowing them down.
Declare Yourself a User Interface Placeholder Abolitionist!
Using placeholders is a bad approach to software development that interferes with numerous best practices including Agile development, the conversational model, and frequent usability testing as needed. Free your users from the tyranny of user interface placeholders. Abolish placeholders from your application user interface! Marketing and product management will be able to write shorter, simpler instructions for testers. Usability testers and beta testers will be less distracted and confused and will move faster through the user interface. The documentation group will not have to deal with the placeholders when making screen shots and writing text. Everyone will be focused like a laser on testing and using what actually works, not on what might be coming in the future. Everyone wins!
voximate
RSS