CROSSPOST: This article was originally posted as part of PerfPlanet Calendar on December 12th, 2019

Many of us are facing the challenge of promoting the idea of speed of user experience within our organizations and crave any support data to help “sell” it to business stakeholders, product managers and engineers.

Real User Measurement (RUM) is a great tool to capture speed from actual users in the wild, measure their engagement and with one swift gesture point at an A/B test comparing speeds of two versions of the app or even use awesome “what-if” diagram to predict the impact the planned improvement.

Unfortunately, sometimes we just didn’t fund the purchase of a RUM tool, did not integrate it or simply don’t have A/B test set up and did not roll out new code to any of our user yet. This leaves us without data and therefore without a powerful convincer and visualization tool.

I was struggling with some of these problems on multiple occasions and at one point I realized that many conversations do not require actual user data.

• some of these conversations were just about training team members who needed better grasp in statistics of web speed, distributions, percentiles and effect variability plays
• some of them needed showing the reasoning behind prioritization of speed and visualization of known industry trends like conversion rate decay or increase in bounce rate as experiences slow down
• and some other conversations were about supporting the very purchase of a RUM solution so business decisions could be made with real data

One day in early spring, frustration of luck of data overpowered lazy opensourcerer’s brain and I spend couple weekends coding up a visualization tool that lets you ~pretend you have the data~ simulate data and visualize it to drive your point across.

The tool is called “UX Speed Calculator” and you can use it at https://ux-speed-calculator.netlify.com/ and contribute to it on Github – it is open source and you can help add bells and whistles to satisfy your inner data geek.

UX Speed Calculator does a few useful things:

• it calculates a log-normal distribution based on base speed and variability so you can simulate your page’s distribution and show how it is different from a normal, “bell curve” distribution people media truly assume

• shows median, 90 and 95 percentiles so you can try and match your existing stats or simply educate engineers on what those numbers are

• calculates bounce rate distribution and let’s you adjust the slope of degradation to your hearts desire to help explain to marketing teams the impact of speed on their marketing campaigns

• calculates exponential decaying conversion rate distribution and helps you explain conversion poverty line and why running experiment by slowing down pages is not necessarily predictive of how much savings you’ll get by speeding them up the same amount

• it also tries to shine light on the phenomenon on of low conversion / high bounce rates on the very left of the chart (near the zero) where despite the logic of “faster means more business” we often see unexplainable data. Many RUM experts believe it is due to the low numbers which do not produce statistically significant results, but my work with UX metrics and general lack of understanding of statistics always made it hard for me to accept that as the whole story so I postulate that is is caused by a high percentage of errors in that part of the chart and experiences that are measured as “fast” were actually incomplete, functionally broken experiences or outright error pages. So in the tool you can adjust decaying failure rate distribution. Charts also show theoretical bounce and conversion rate distributions as dotted lines and distributions that reflect error rates as solid lines

• based on a combination of failure rates, bounce rates and conversion rates, charts also show color-coded bars for each of the populations to make it sleazier time relate to each pixel as a user who had different experience and help consumers of this visualization empathize with the data.

• if so many lines and labels confuse you and your stakeholders, feel free to click on the legends on the right to hide those that do not matter for your story

• and if you need to share a chart, just copy a URL and send it over, it updates as you tweak the knobs and dials so you can always jump to the right chart and don’t need to re-create perfection from scratch

• ohh yes, it also shows you the $$$ all these conversions amount to so those of your peers who don’t like math or can’t bear the cognitive load of charts can still translate the value of speed to something tangible. Substitute $ for €, £, ¥ or even ₽ if that works better for you.

Hope this tool will help you with your creative story telling and you’ll be able to push the limits even further.

Happy #webperf-orming!

And remember, there are lies, damn lies and statistics! So don’t overuse this or other scientific data tools in your battles for the better within the fuzzy world of user experience!

CROSSPOST: This article was originally posted as part of PerfPlanet Calendar 2016 on December 7th, 2016

Speed needs to be designed

Speed of User Experience (UX) is important for your web sites and mobile applications, but it often takes a back seat to functional improvements and is always thought of as purely technical exercise – proactive at best, but more commonly coming after a newly released product fails to perform.

While technology plays a big role in delivery and rendering of user experiences in modern applications that depend heavily on networks and on-demand content and functionality, it only provides solutions and often has serious constraints.

In order to create products that deliver great experience, it is critical to start designing speed and planning on how it can be delivered at the very early stages of the process.

Movies or paintings?

Unfortunately, today’s deliverables that are passed from product people to designers and from designers over to development teams are inherently static.

Both early product wireframes and more elaborate Photoshop (or Sketch) comps/mockups only depict the final view of the user experience and do not articulate the inherently progressive nature of web medium.

In his talk, Speed vs. Fluency at Velocity New York 2015, Kent Alstadt asks if today’s web designers are more like film makers who direct “short films” of digital experience or if they are artists who paint beautiful oil paintings that show final picture. He argues that human’s brains enjoy experiences with higher “processing fluency” and web pages that are designed/directed to achieve it would be more effective in meeting their goals.

Performance Choreography

Tim Kadlec in his WebPerfDays NY 2014 talk about Performance Choreography also draws parallels with movie making and cartoon animation where transitions and “in-between moments” are given a lot of thought as they heavily impact perception.

He points out the importance of concentrating on techniques like skeletal designs that focus on progress instead of using spinners and other artificial progress indicators that emphasize waiting.

Revealing Features

In order to achieve a smooth transition between different views/pages of our interface it is critical to concentrate design thought on this transition.

It’s important to ensure that the sequence in which features are revealed to the user is natural and follows user’s incremental needs as they wait comfortably for all the information and interactive functionality to be shown.

Rendering Stages

The whole universe of views and pages is very diverse and unifying all the experiences is impossible. What we can do instead is concentrate on user’s needs as they experience information in human-computer interaction on the web.

If we step back from specifics of individual pages and experiences and look at the wider problem, we can group rendering into several important stages.

Identifying these stages for their digital experience would help product and design teams come up with appropriate visual solutions and create smooth transitions.

1. Verify Destination

First step of any web navigation from one page to another or interaction within website interface is to assure the user that the action they performed was the one they intended to do so they can comfortably wait while it loads without wondering if they need to click the Back button.

This applies equally well to navigation from a search engine results page or external listing page where a link to a competitor’s site can be right next to your own as well as navigation within your own site with many alternative navigation paths.

If the user is waiting too long for any piece of interface to show, they can cancel their action out of sheer frustration and leave. This means that we need to identify the minimum amount of User Interface that we need to load as quickly as possible to reduce the uncertainty and to keep them interested.

Here are the most common UI components that are relatively easy to quickly show to the user:

• Core branding elements like logo and brand colors as part of top navigation
• Breadcrumbs and page headline/title for specific detail pages

2. Provide Primary Content

After the immediate feedback was provided, it is most critical to show the user the primary content we intend them to experience.

One challenge that we have here however is to separate core, primary pieces of content on the page from all content that we’d like to provide.

It’s important to narrow down the set of components so they can be loaded as quickly as possible and users can immerse themselves into content while waiting for the full experience to load.

Primary content is usually easy to identify in today’s design process because it is naturally given the most attention in product conversations and has the most prominent place on the pages.

Here are a few examples:

• Leaderboards/hero images on marketing pages and the home page of the site
• Article text & photo for the news articles
• Product title & image on e-commerce product detail pages

3. Allow Interaction

Usually, the most important part of user experience on the web is user’s action; almost all design concentrates around soliciting an action from the user.

It is critical to show points of interactivity to the user as soon as the primary content is shown and the user was able to make a decision to act upon it.

Calls to action (CTA) are quite different from business to business: “Add to cart” buttons for e-commerce or “Play” button on a video player are good examples.

Keep in mind that even though an action is probably the most important goal of each page, it cannot be performed until the user consumes the content to convince themselves to perform such action.

Same as in primary content, it is critical to ensure that primary actions are prioritized and included in this stage as we all have great temptation to put everything we, as builders of the UI, envisioned and you will have many opinions in the room with various product stakeholders.

Good news again is that business teams probably have a great grasp on what the primary actions are and they spend plenty of time in those conversations so it’s relatively easy to identify and isolate those components during the design phase.

4. Show Secondary Content

There is always something other than primary content and actions on the page, find this content and secondary CTAs and load them early in case the user is not interested in primary ones.

It is somewhat harder to do that as one can argue that everything that is not primary goes into this secondary category, but it is important not to lump everything into this group and leave things that are not as important to load in the next stage.

Good examples of secondary content and calls to action include:

• Sidebars, secondary headlines or content blocks
• Additional navigation
• User-generated content, sharing buttons, ads

5. The Rest & Invisible Tasks

Once you’re done identifying the first 4 stages, you are left with many other parts of the content and listing them would help you ensure that you don’t have any unaccounted items and avoid the desire to add any of them to the earlier stages.

There are always elements that are there for some political or legal reasons, like majority of footer content, for example, as well as interactions that you don’t have any business owner for and are slowly dying out, but you still don’t want to remove (you probably should).

This stage/group is also for elements that are not within user’s viewport and cannot be viewed or interacted with simply because they are literally invisible.

This applies to elements “below the fold” on search results pages that are already a consideration for “lazy-loading” or “post-loading” after initial page is rendered, especially if interface calls for “infinite scroll” or some other interaction that requires unbounded amount of data to be loaded over the network.

One particularly tricky category of element to identify as part of this stage are subsequent slides for the “carousel” widget that are not visible initially, but are shown either automatically after period of time or upon user interaction. It is very important not to prioritize these as they are often quite heavy and require significant amount of code and page manipulation and will delay more important components.

In addition to elements that are visible later, it is important to include all elements that are never visible, like analytics beacons or other tracking software. Luckily it’s already rarely discussed during design sessions so listing them here can be left for this last step, just don’t forget about those non-visual requirements that still warrant code download.

6. Acknowledge Action

This stage is the last, or the first, in the whole human-computer interaction model depending on how you cut the user path into distinct chunks we call pages or views.

In default page-to-page interaction users just wait until the page starts to load and only get first clue that they did successfully perform an action after viewport is cleared and replaced with next page.

Sometimes it is very hard to speed up these processes as heavy network operations happen at this point and complex server actions might also take significant time (e.g. calculating search results for an arbitrary query over large dataset).

What we can do to give the user an acknowledgement of their action is to provide visual feedback. Historically first examples included disabling form elements upon form submission (reducing double-submission).

More creative ways were discovered over the years, including the following:

• Providing “loading…” label on the form or next to submit button
• Transition overlays spelling out that user’s acction is accepted and app is hard at work to perform it
• Erasing content area of the current page emulating next page’s initial render before request even went through to the server
• Animating-away the current view while next one is rendered
• Rendering skeletal layout of the next view within single-page app

This is only possible for interactions that are initiated when user is already on your site, but can provide a good flow once user is already engaged.

IMPORTANT NOTE: Please avoid using spinners and design good progress indicators that feel natural and don’t require users to concentrate attention on interpreting them.

Progressive Storyboards

When you include this work within your product design process, it is only natural to start thinking about how to adjust the established deliverables to better represent the results.

You can start by simply isolating the components of the “final” mockups that are currently used as deliverable and producing a sequence of views by simply whiting out the elements of the original mockup that are not supposed to be represented at particular stage of rendering.

Here’s an example for a CNN Home Page (screenshot of final view):

And corresponding sequence of rendering stages depicting identified steps as a Progressive Storyboard:

You can also go into more detail for more complicated transitions acknowledging user’s actions, as they are in your full control and can significantly help mask slow server-side and network performance.

Having these deliverables as a result of product design work can help the tasks of graphical design, animation and development teams; clearly stating expectations and making it clear what needs to be achieved.

Establishing Technical Constraints

Performance work can never be done by one team in isolation, it is always a collaboration between product and design teams who know the experience they try to create and technical implementation and operations teams who know technical realities of web medium.

It is easy to answer the question of how fast the experience has to be with a quick “very fast” and to expect that everything will be loaded and rendered in-front of the user immediately without realizing the costs of accomplishing that or hard technical limitations that do not allow for arbitrary wish granting.

To help both business teams with high-level cost assessment and technical teams with creating solutions for each stage of rendering, it can be practical to establish a series of technical constraints that map to stages we identified.

Here’s an example of such mapping:

You can notice that optimizations that are higher on the list are at the same time more complex and provide more aggressive constraints, for example fitting a lot of code and content into 14K of payload is not possible and only limited functionality is possible without JavaScript during primary content stage.

A good rule of thumb to have is that each stage is 10x more expensive as previous one in terms of time for development, testing and maintenance. So putting some element into secondary content can cost $1K while moving it up the chain to primary content can convert to $100K and to first stage would cost you $1M. This can give more structure to prioritization conversations and allow to pick only most important components to be promoted.

Design, Implement, Measure

I really hope that this approach to designing for speed early on can help your team establish better performance practices and account for the complicated nature of the web performance across all the stages of experience creation.

Make sure to keep paying attention to speed and measure each stage as closely as possible to ensure that users have smooth experience.

Let’s reduce the amount of frustration in the world and make our sites fast!

Anyway, doesn’t matter how long something lasts, there will be a moment when it’s time for a change and now is that moment for me. I am leaving truTV/Turner to join Keynote Systems as consultant for their Insights team that helps company’s clients with Web Performance needs.

Needless to say, I’m proud of the team at truTV Web Services that has a grasp of their tech, can both innovate and know when to stick to proven solutions and more importantly, is a bunch of great and passionate people! I’m positive they will only be pushing the boundaries of what can be done by a small team within a large organization and be able to sustain rapid pace required by media industry!

As you can imagine joining Web Performance-centric team is an important step for me personally and a chance to do what we do at NY WebPerf meetup – speeding up the web, but now on a full time basis. Obviously, I will continue to run New York meetup, help other organizers around the globe and promote Web Performance with talks, blog posts and every other possible way, and now with help of Keynote, I will dedicate more time to this public work.

There is no better time to rid the web of slowness!

My first reaction was to shake it off and get back to the book paying closer attention to what I was just reading for past few minutes. It happened again and again throughout the years of reading and I was always annoyed at loosing time having to re-read the same text over and over again. But the feeling was so curious and so repeatable that I thought that I should start observing this behavior to try make sense of it.

As it turns out, the distractions were not the problems of the brain having hard time concentrating, but on the contrary, the process of generating new ideas. Triggered by the topic of the book or blog post, my brain was connecting prior thoughts with something new or bringing up memories that were long forgotten and never coming back in that particular context.

Basically, it’s like electric short in the brain that happens between two previously “unrelated” areas and this short builds some new bridge that allows for thoughts to travel faster between the two concepts in the future (disclosure, I’m not a neural surgeon nor I have any idea how brain actually works).

In “The Myths of Innovation”, Scott Berkun’s attributes a lot of inventions to the associative thinking that people employ connecting different things together, observations of nature, memories and so on. The shorts in my brain are much like those associations in the making.

So, getting back to the annoying distraction and the need to re-read what was just read with a blank expression on your face…

After observing it for a while I realized that getting back to reading was the worst mistake I could make – basically I was forcing myself to block the thoughts that were working hard on building that neural bridge effectively killing the associations that were being created. My desire to finish the book and to optimize reading time was prevailing over desire to get some meaning out of it completely defeating the whole purpose of reading itself.

… so I started to think of what to do instead …

There are a couple goals here – first of all is to try preserving the thought that I was previously trying to subdue. After all, I really hope those ideas are useful and not just day dreams.

Pen and paper never worked for me for some reason and I waited all this time for technology to catch up which it did bringing us mobile devices. Emails to self work very well for me and Blackberry started (literally) saving the ideas also helping with putting them into personal search engine (thanks Gmail) and effectively adding them to task list (inbox). Some people just use notes app on their smartphones and others tweet with #notetoself hash tags – whatever works best.

The second goal is to not stifle the brain activity and let it go for as long as it can naturally do so to helping those bridge-building ants in my brain create something stable and reliable and capable of transferring the thoughts between the newly connected concepts in the future.

Now, with better mobile devices with web browsers and apps, there is no need to just record your thoughts, I’m adding tasks to my issue trackers for software projects, writing blog posts, tweeting, updating my presentations and so on the go, right when I had the “blank reading” moment.

Switching from the book to working on the idea is as easy as pulling out the phone or taking iPad from my backpack (or switching the app if it’s an ebook). Luckily bookmarks were invented long time ago and there is not much to learn to be able to re-start the reading.

I urge everyone to not read a book while train ride lasts or until you go to sleep or until you reach the cover. Read it until it sparks the thought, until your brain wanders away coming up with an idea. Use reading material as a trigger for creating associations, try to catch the creative moment – don’t loose it, build on it!

This post came out pretty long, the thought is thinning and it’s time to get back to that book…

A few particularly interesting ones, like Page Speed’s Transfer Size and Page Size and dynaTrace’s Total time on network / JavaScript and rendering, for example.

Also some visual prettying up is done with CSS3 gradients for bars (falling back to plain ones for less fortunate browsers) and some better looks for URLs that were just added for monitoring (if you have it enabled on your instance as ShowSlow.com has).

This is a start of the overhaul of details page which is going towards the version 1.0 with the goal of picking your metrics to be displayed on the graph. Stil long way to go though ;)

Follow the upgrade instructions if you already have an instance running.

Or you can download code package and install it.

There are two parts to it – first they are going to provide storage about all things withing Facebook and on the internet in JSON format so people can write applications that use this data.

For example, public information about me on Facebook can be seen at this URL:
https://graph.facebook.com/sergey.chernyshev

And here how it looks:

{
   "id": "504972292",
   "name": "Sergey Chernyshev",
   "first_name": "Sergey",
   "last_name": "Chernyshev",
   "link": "http://www.facebook.com/sergey.chernyshev"
}

This way all you need to know is ID, which in my case is sergey.chernyshev or 504972292.

Another side of this is that Facebook is going to also store data from pages that were shared using their share button or added to interests or in any other way loaded into facebook’s system. They will be extracting this data using RDFa format and interpret it using a vocabulary that they call Open Graph Protocol (I will be calling it RDfb).

<html xmlns:og="http://opengraphprotocol.org/schema/">
<head>
<title>The Rock (1996)</title>
<meta property="og:title" content="The Rock" />
<meta property="og:type" content="movie" />
<meta property="og:url" content="http://www.imdb.com/title/tt0117500/" />
<meta property="og:image" content="http://ia.media-imdb.com/images/rock.jpg" />
...
</head>
...
</html>

This will allow sites to add a few lines of code to their pages to get them recognized as meaningful data instead of just human-readable documents – this will allow smart agents like search engines, mobile applications, embedded systems and just simple widgets to make sense of this data and help people see it in the context that is most usable for them.

I have a feeling that Facebook being a great driver for many business decisions related to promotion and marketing through social media, this change is going to be a best thing that happened to Semantic Web so far, might be even bigger then Yahoo’s and Google’s efforts in universal search.

P.S. Such a great present for my presentation about RDFa tonight ;)

…I use a resistance as a compass. If I’m uncomfortable about doing something, if I hear the voice of the lizard brain, that’s exactly what I choose to do…

This is exactly the “path of the most embarrassment” that I wrote about some time ago. This is the feeling that I found. The one that is so easy to differentiate from the comfortable fuzzy feeling that boring stuff brings.

It feels so good to have a validation by Seth, I think I should listen to this lizard brain more often not to step away from the path of the most embarrassment. Wait… good feelings should be avoided, don’t they…

I’m using Pivotal tracker for my agile needs and i have a long backlog which I’m adding to more stuff over time, rearranging the list and so on. What I noticed that rearranging gets a pattern during hard times – I tend to avoid some kind of tasks – those that are not very natural for me, like writing some texts in English or just regular startup problems like writing business plan or think about the product from user’s perspective.

What I tend to push up the list is something I’m comfortable doing, like coding new features or playing around with new colors, logo, some other things, but definitely not those that bring me closer to the release.

Many words are said about shipping the product early and why it can be vital to business so I’m not going to repeat them here, but I never found a good recommendation about how exactly do we do that. One thing that I heard lately is a paradigm of “minimal viable product” which is about the set of features to include that will make the product stand out, but no more.

What it doesn’t describe is how do you do that in agile environment when so many backlog items come up when you start and reprioritization happens very often and requires constant attention. So I struggle to find that feeling that I can catch and follow during the periodic reordering of my task list / backlog to make sure that things that need to be done to be successful don’t get pushed down by things that I just feel like doing.

Some time ago I read a good quote from Reid Hoffman of LinkedIn – “If you’re not embarrassed by your first release, then you launched too late.” and it stuck with me as a great description of the problem of over-polishing the product which is not even seen by users yet.

So I though to myself – if I look at it from agile perspective and treat each iteration’s or even day’s product as a final product (thing that you want to have in your agile world) then embarrassment is exactly the feeling that needs to guide you when you’re picking the next thing to do.

What I mean is that if you thinking of moving some task down to replace it with some other task, think if this other tasks’ completion is going to help you avoid some potential embarrassment and if so, then stop right there! – what you’re doing is trying to feel better about the product and not bringing the product to the state that will benefit the business.

Unfortunately these are two different things and extreme perfectionism tha arises from trying to “polish the torpedo” never did any good and many projects and businesses were ruined by “unfinished torpedoes with shiny casing”.

So now what I do and urge all the strartupers to do (or open source developers for that matter) is to follow the path of the most embarrassment – when you feel that you have a choice of doing something to reduce the embarrassment, turn around and go into the opposite direction because you’re trying not to hurt your feelings. What you need to do instead is to go towards the business goals that I hope you had time to define and didn’t just jump into development, right.

Hope this insight helps and if you feel I’m wrong, let me know in the comments.

Obviously, I’m an emigrant which makes it different, but in my case people usually can’t finish pronouncing my last name and stumble somewhere in the middle ;)

I even thought about borrowing a nickname from Ernesto Guevara, so it’s easier to remember like Sergey “Che” Chernyshev, but wasn’t sure if I really wanted to be associated with communism ;)

It’s hard to translate this joke to English, but I felt like posting it anyway – it describes what people feel when they actually try to pronounce my name:

It’s definitely a book worth reading if you’re well into web performance optimization and want to step even further when all simpler optimizations don’t bring any more improvements.

JavaScript sections from Ajaxians and Nicholas Zakas are quite interesting but definitely for most complex 2.0 apps with tons of JS and front-end processing.

Flushing early and CSS selector performance are important too, Steve was talking about it at Web 2.0 @ SF – CSS is a bit beyond my comprehension unfortunately, but flush is easy to comprehend for those who made at lease a single IO app, especially networked.

One thing among tools – in my opinion, WebPageTest.org was given less credit then it deserves – it’s connection view (next to the waterfall) and content breakdown chart as well as empty/primed dual run definitely bring it high in the “packet sniffer” section and not only “analytic tools” section. And I agree with Steve that it’s availability through the web give it a huge value in the eyes of developers and business decision makers. It’s very possible though that that section of the book was done when most of these features were added.

If you didn’t read Even Faster Web Sites, you probably should. As well as its prequel – High Performance Web Sites.