Need for speeds

“If you want to improve the UX of your product, make it 10% faster!”

I heard this years ago in an episode of “What is wrong with UX” and I still ponder upon it and think “Yeah, that is pretty spot on, those two self-described ‘old ladies who yell at each other’ really hit the nail on the head there.”

The original context for that quote was that product improvements do not need to always come via a new feature or by overhauling the UI. Sure, these can help (although sometimes they can cause more harm than good), but to improve a software product making it faster can make all the difference. No-one has complained that a website loaded too fast, and judging from this post by the Nielsen Norman group, people are unlikely to do so any time soon.

Speed (and performance in general) is easily given short shrift, but this may be partially accounted for the fact that, just like the term ‘user experience’, it is not a single item, but a multi-faceted property of the product itself. Let us unpack this a little bit.

Your product’s many speeds

If you wanted to increase how fast your product is, you quickly realise that there are several separate things you can try to tackle. In the case of a web application, it might be how quickly a web page loads, how fast a user can download or upload files, or how quickly they can query their data. Furthermore, each of these examples can be broken down into even more items.

For instance, there are many potential ways in which you can attempt to improve the performance of a particularly slow query. These can range from potential optimisations of the query itself, changing the underlying data model, updating your infrastructure, and more. Each of these can improve how fast a user gets their results, but the other factors will still present their own bottlenecks. You can keep trying to optimise said query, but if your infrastructure is creaking, then that will only take you so far.

So if performance can be affected by many things, how do you know whether you are improving ‘it’?

The prevention paradox and the importance of measuring

Back in the day, I spent a summer as a cleaner. One thing you learn pretty quickly is that people notice a lot more any spots you may have missed than any you did not. A performant product is pretty much the same. People can easily take it for granted but will notice very quickly when expectations are unmet. A lot of work can go into maintaining functionality, but fanfare rarely follows when this is done successfully. For a more poignant example of work behind the scenes being taken for granted, one can look at the attitude of some when the Y2K bug failed to wreak havoc everywhere.

This is unfortunate, as it means that it can be hard to communicate why certain tasks such as infrastructure improvements are necessary, especially in a preventive capacity. Even you and your team might not be aware of some of the value you have provided.

As an example, a team I have worked with implemented a change that better distributed the load our application was under. We were pleased with the results, but did not think about it further. A few months later we inadvertently undid this change. We noticed the repercussions very quickly as the performance promptly started to degrade across the application.

It turned out that this change we had made had not just mitigated an occasional issue, it had also allowed us to onboard larger customers who made more use of our application. It wasn’t the best way for us to realise the value of our previous work, but it was effective.

We found monitoring our application before and after a proposed improvement as the next best thing. Investing time in monitoring and logging proved invaluable in assessing whether our improvements have been successful or not, and in making sure that new product developments did not compromise the performance of the application. Moreover, it also helped communicate our efforts to the rest of the company.

This last point should not be underestimated. If you want to have the support of stakeholders across your company to make crucial-but-not-always-shiny improvements, then you are going to need something more than “We did lots of refactoring which has made the product a lot better in ways you cannot see. Trust me.”

Also, the engineers have worked hard on these improvements, you should help make sure their hard work is recognised!

Summa summarum

One can say that performance has a branding problem. It is easily taken for granted or become an afterthought. Yet, like delayed public transport, everyone complains when things slow down.

Yes, you should strive to have a product that is so fast and reliable that it disappears into the background, but you should know also that it is going to take several steps to get there. Therefore, you might as well communicate and celebrate the milestones along the way.