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.
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:
- UX doesn't control it - This is something that's handled by developers, so why bother?
- The display order is based on layout - Elements should render based on the order so why do I need to visualize this.
- Added burden -UX and designers are now expected to be more than just that. The role has evolved to add more responsibilities - who has time for this added burden?
- Developers should already know this - Come on, any developer should know that the hero image is really important - why do I need to tell them this?
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
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.
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.
- Identify which content elements should display in what order. Make sure that have agreement from the entire team - especially senior management. Typically, we'd want to display the navigation first, followed by the hero image.
- Create page outline. You don't need to have high fidelity - just something that shows the main content blocks.
- Add numbers. Simply add a number to each content element.
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.