Faster, faster, faster

It's not a secret that I work in what to most people is known as web development - of course, some of us prefer to call it User Interface Engineering (and the people who perform this engineering User Interface Engineers, or UIEs) - for more than one reason...but that's a different discussion.

What some people won't know is that for the past 7 years (plus a little) I've worked in the payment industry. Basically, I write web pages that take a customer's money when they buy stuff. For those of you who are wholly unfamiliar with the industry, I'm going to first talk about some terms before discussing today's topic; otherwise we'd all be talking in our own language and a common understanding would be difficult. So, here are some of the terms you'll need to know:

• page weight is the amount of HTML, CSS, and JavaScript delivered in the response; 
• response time is the amount of time taken between when the user requests a page (e.g. by clicking a submit button) and when the page is actually loaded and usable;
• page load time is the measure of time it takes for a page to be requested and rendered in the user-agent (browser)
• reaction time is the amount of time taken during user interaction, e.g. the time between when a user completes entry in a field and tabs to the next field; 
• interaction time is the amount of time a user interacts with a page before moving on to another page
• server load is the amount of traffic (i.e. the number of requests) on a server at a given time
• server capacity is the measure of how much traffic (i.e. how many requests) a server can process at a given time

When coding a user interface, a good engineer will take page weight, response time, page load time, and reaction time, into consideration because, as a generally accepted rule, faster pages are a better user experience. Of course, as a UIE, there are several things that we can do to affect page weight (which affects both response time and page load time) and reaction time (which affects the interaction time and overall user experience) - some of which are related to the HTML and CSS on the page, most of which are related to the JavaScript on the page. For a typical page, these basic measures are enough, and UIEs, in practice, measure them in seconds. Seconds is a pretty good measure, after all, it generally takes a quarter of a second to simply respond to stimulus[1] without evaluating content. However, for a process, like paying a bill or buying merchandise, we need another measure - one that takes into account a series of pages.

Why the difference? Because, aside from the obvious (that one is page and one is a process), in the first instance, with a single interaction point, the measure of throughput is generally a function of server capacity. Note: this, by the way, is the basis for a Denial of Service (DoS) attack, or in its more advanced form, a Distributed Denial of Service (DDoS) attack, where computers request pages until the server can no longer respond (the server load has exceeded server capacity) - roughly the equivalent of stimulus overload in humans.

Time for a few more terms - those related to a process, and more specifically to the checkout process.

• completion time is the amount of time taken to complete a process, measured from the time the process starts (e.g. the checkout button on a shopping cart is clicked) until the last page (process completed - e.g. a receipt) is shown;
• conversion is the measure of transactions that have completed payment (think of this as the number of customers who actually pay you) and is the complement to abandonment;
• abandonment is the measure of users who have started the payment process but stopped before actually completing the payment (think of this as the number of customers who got into the checkout line but decided they didn't want what they were going to buy);

For single interaction point pages page weight, response time, and page load time are going to the be primary factors affecting their use. For a process, however, it is the combination of these factors for each of the pages in the process that contribute to the completion time. While each page individually contributes to the server load (and therefore affects server capacity), and we can relate measures like page weight (and to some degree response time) to server capacity, there isn't a comparable measure for completion time, and instead we measure how many times a process is completed (or not) once it's begun in conversion or abandonment - meaning our measure is not a function of server capacity, but of the user's willingness to complete the process. Note: the number of transactions completed or abandoned are measured in conversion and abandonment respectively, the amount of money collected for converted checkout transactions is measured as Total Payment Volume (or TPV).


Now, it's no secret that although there are a number of factors that affect conversion, the largest single factor affecting conversion is the completion time - there is a direct relationship between completion time and abandonment and an inverse relationship between completion time and conversion. Since we know that completion time is tied in some ways to the number of pages (or steps) in the process, we could potentially identify a conversion number with an individual page (or step) in the process; however, even though not all pages are equal, such a practice treats them as equal. Therefore, the final page in the process that simply displays a confirmation number or receipt and has a lower interaction time than a page that collects information is treated the same as the data collection page, even though the data collection page affects completion time to a much greater degree.

Rather than looking at the number of pages (or steps) in the process, a better approach is to look at the interaction time of the pages (or steps) and how it affects the completion time. There are a large number of factors that can affect the interaction time, including the complexity of both the data collection form(s) and content (and we certainly have a responsibility to address those issues); however, an often overlooked factor in the overall user experience is the JavaScript. Typically, we think of JavaScript performance in terms of milliseconds, and add substantial interactions on a page giving a rich experience. However, since there are typically multiple steps (or pages) in a process, it is no longer adequate to think in seconds as we would for a page. We must consider each addition to a step (or page) to consider its impact, but further than that, we must begin to think in terms of milliseconds and sometimes even shorter periods. Only by doing this can we begin to see the completion time in seconds as we currently do single pages, and only by doing this are we truly going to be engineering engaging experiences that consistently yield a higher conversion.

[1] Reaction Time Statistics, http://www.humanbenchmark.com/tests/reactiontime/stats.php