A blog about user experience.

Communicating The Page Display Process to Improve The User Experience (Part 1)

Learn how to communicate content priority during the page load display process.


This is the first in a series of articles on how to communicate the user experience to developers and the team during the initial page request -- that is, what will the user see and when. This task currently left to developers to figure this out. However, since this is really about what the user sees, it makes sense that UX and design can collaborate on this. Seems to me that for too long, UX has left the burden to developers to figure this out on their own. Since we are supposedly the experts into user behavior and have the insights into user needs, it makes sense that we get more involved.

In this article, I will discuss the basics. Look for future articles with more info on how to enhance this documentation, including storyboards and interactive prototypes using Axure.

Current State

Typically UX typically doesn't visualise how a page should render in the wireframe process. For example, we don't specify what elements are important to the user and how long it should take to load. There are various reasons why this is probably ignored. I'll admit I made these faulty assumptions before I really got into understanding web performance. These included:

Why We Need To Change The Process

Now let's take a look at why it makes sense to communicate this.

Content Display Order is Variable

When a web page is being built, the browser attempts to download the files in order. However, at what point they actually display in the user's browser can vary. For example if the browser encounters JavaScript or CSS, content elements may not be displayed immediately. (this is a very simplistic explanation.) For example the footer might load first, which may not be what the user really wants to first se. This may cause user confusion, depending upon the page layout process.

DISCLAIMER: The examples below are not intended to suggest that the website rendered the elements in the wrong order. Instead, the examples are intended to show that content will not always render in the order as displayed in a wireframe.

The global nav and login element render first, followed by the hero image.
The footer is displayed first, followed by the global navigation, and hero image.
The footer and product feature content area is displayed first. The browser waits for the Open Sans font to load, then displays "Browse Top Categories". The product images then kick in, followed by the navigation. Once the images load, the product category content area pushed down the footer area.

Developers (And Project Team ) Need To Know This

Of course developers are smart enough to know that main content elements such as a hero image is important. However, as we've already seen above, the order may not be the way you think makes sense. To fix it, the developer will need to go into the code and look for ways to ensure that the content is rendered in the correct order. More often than not, this means added effort, which is not considered part of the project. As a result, this may not get worked on since there are no dev hours allocated to this. So, if we consider this important, we need to tell this to developers upfront and make sure that the team is on board.

Creating a Priority Wireframe

Creating a priority wireframe is simple, and won't burden your current wireframe process. They key is that this documentation is done at the beginning of the wireframe process -- way BEFORE you turn over the wireframes to developers. This will ensure that everyone is on the same page.

In the example below, I created a wireframe page blueprint that visually depicts the various page content elements. However, you may find that doing this in a spreadsheet is sufficient - you just need to remember the real purpose here is to communicate the suggested order of the page render process. Here are some suggestions.

Here's a simple priority wireframe created in Axure. In this example, the global navigation is followed by the hero text, then image.


One of the things to keep in mind about the render order is that it may not make much of a difference if all elements render quickly. For example, if the variations occur within a short period of time, the user may not actually notice that the footer renders first. Other factors which would affect the user's perception would include connection speed. A user with a 4G connection would see the page render more quickly, thus reducing the user's perception of these differences. This is why it's so important to test this on actual connections in a variety of browsers.


As we've seen, it's easy to create a wireframe that helps communicate the correct page render order. While this is a good start, this approach only considers the content elements as they are fully rendered. The problem is that in the real world, the elements will display progressively. Next time we'll examine wireframe storyboards that progressively depict the intended render order.

About · Contact

© 2016 Speedy UX. All rights reserved.