27

I was just reading this very interesting article on Fast Company about how How One Second delay Could Cost Amazon $1.6 Billion In Sales annually. To quote the article

Amazon's calculated that a page load slowdown of just one second could cost it $1.6 billion in sales each year. Google has calculated that by slowing its search results by just four tenths of a second they could lose 8 million searches per day--meaning they'd serve up many millions fewer online adverts

So I was just wondering if we should start considering stuff like page render time and retrieval speed and performance issues as part of UX since it does influence the overall user experience of the user.

If you feel the answer to the above question is yes,how much of it should we consider and can we ever define a fine line between creating a better user experience or sacrificing user experience for higher performance

Improve this question
8
  • I've removed the infographic. These are forms of google spam.
    – DA01
    Mar 16, 2012 at 20:17
  • @DA01, interesting why do you say that?
    – Mervin
    Mar 16, 2012 at 20:28
  • 1
    I say it because it is: buzzfeed.com/awesomer/the-truth-about-infographics
    – DA01
    Mar 16, 2012 at 20:29
  • 1
    (They are also typically very poorly designed by amateur wannabe hipster designers who use citations as an excuse for often confusing if not misleading data visualization...so I hate them for that too. ;) -- but mainly they're bad just because they are linkbait by black hat SEO folks to game Google)
    – DA01
    Mar 16, 2012 at 20:31
  • UX stands for "User Experience". What part of having a slow page is not part of the user's experience? That's why all these loaders have been built over the years to provide feedback so we don't shut off the computer. This is much ado about nothing.
    – King Friday
    Mar 17, 2012 at 0:48

10 Answers 10

Reset to default
7

UX has, and cost, performance, but UX design is separate from performance design.

should [we] start considering stuff like [...] performance issues as part of UX since it does influence the overall user experience of the user.

As you state, performance and loading times affect User Experience. The answer to the yes/no-question is obviously yes. So the next question is, how should this fact affect how we work with UX?

If performance is UX, then what differs programming from design?

Imho, performance should be respected along with any other constraint. But there are many reasons to regard UX and performance separately:

  • Performance is improved by optimisation, while UX is improved by design.
  • Performance can be changed without changing the design.
  • Performance depends on tons of factors, many of which are not in the UX field, and it boils down to a number of seconds or milliseconds. UX in general does not boil down to a number on my chart.
  • Performance may be seen as a part of UX, but a more proper way to see it is that UX has a performance. UX design needs to take its performance issues into account, but designing for UX and designing for performance are two competing tasks.

Trading performance for UX

I am a programmer, and the further down the process I optimize, the better. If you are prioritizing optimisation of performance before most of the UX design is set and ready, you are doing something wrong.

To me, one part of UX is unloading the human mind, cognitively, and many times that means heavily burden the hardware. For example:

  • doing a zillion calculations to present a relevant search result, instead of requiring the user to type search engine optimal keywords. This takes much longer than just displaying a bad result, like bad search engines do. So Google compensates this workload with quite performy hardware to still give a fast UX.
  • animating a folder or program collapsing or expanding (1, 2), instead of letting the user herself figure out where it went or comes from.

Animations and calculations burden performance a lot but the amazing UX effects of a well designed animation or intelligent search result is indisputable. This is the trade-off we seek. UX cost performance. And we can only hope that our hardware is fast enough, and that our programmers are skilled enough, to match our UX ideas.

Yes, my job is to implement the design at a low performance cost. But performance can be improved later. If performance issues later require sacrificing UX, that should be respected along with the budget, deadline and other constraints. We can predict some of the performance issues at design time, and if so, of course use our knowledge about it. But it is much harder to know the exact performance constraints on before hand, especially when exploring new technologies and designs.

So in most projects: Design UX first, optimize performance later.

Improve this answer
7
  • your answer reminded me of this article: How Basecamp Next got to be so damn fast without using much client-side UI, where they accounted for UI and Perf together
    – Jake Berger
    Mar 16, 2012 at 20:00
  • I have to disagree with a lot of reasons you give to keep performance separate. Like most aspects of web design and development, everything needs to work together and silo-ing issues only makes things worse. That said, I agree that at times UX may influence performance in a way that isn't necessarily faster, but gives a better overall UX to the user.
    – DA01
    Mar 16, 2012 at 20:19
  • Performance, and how we experience it, can be improved by design. progress indicators can be used to improve the experience of waiting. In some cases, a bad design will lead to bad performance (loading a table with a million rows all at once -vs- loading on demand), so it should at least be on the radar.
    – zzzzBov
    Mar 16, 2012 at 21:11
  • 1
    The easiest way to improve performance is with UX built around being more performant. This requires knowledge of how web technologies work, but if you don't have that you have no business working in UX in the first place.
    – J. Jeffryes
    Mar 16, 2012 at 21:34
  • It is interesting how this question and its answers seem to stir up some emotions, and have many point of views. I guess the question is too broad and the answers too many. I agree with most answers and comments here, but stick to my personal point of view. If performance is UX, then what differs programming from design? :)
    – JOG
    Mar 16, 2012 at 23:46
27

Absolutely in the yes camp on this. This is one important place that UX differes from UI, I think, because UI CAN focus on a particular page, how it looks, how it reacts. But the user EXPERIENCE is about more than one page.

The fact that a pure UX designer cannot influence the technical solution is no excuse. Page load times as such may not be part of the UX design, but process times should be - how long does it take to do x. And proposing AJAX solutions, or deferred page loading should be in the arsenal of a UX designer.

There has been a lot of argument saying that developers should learn some UX ideas and skills, but it works the other way too - UX designers should have at least a basic understanding of the technical aspects of how their designs will be implemented.

Page loads - or performance statistics in general - shoudl be done on a controlled environment. It doesn't mean that everyone will get the same performance, but, assuming the environment is a valid one, they should be in the same order. And more and more, this environment should include a phone access.

So yes, if UX designers want to become part of the entire site production team, they should have an involvement in performance. This doesn't just mean defining numbers - sometimes it means seeing what the performance is like, and working with the developers to improve it, or accept it.

Improve this answer
9
  • 1
    +1. It certainly helps to have performance in mind even in the early design stages of your site. In over 90% of cases, the vast majority of a page's load time can be attributed to front-end elements and has nothing to do with how powerful your server is. For anyone interested in this topic I'd suggest two resources: www.webpagetest.org and stevesouders.com And then you should absolutely use YSlow as well... developer.yahoo.com/yslow
    – Steve Wortham
    Mar 16, 2012 at 19:53
  • 1
    Not sure where you arrive at the 90% figure. I agree a lot needs to be done client side for performance, but I find that typically a lot also needs to be done server side to increase performance (and, usually, BOTH need to happen in sync directed on a technically aware UX team.)
    – DA01
    Mar 16, 2012 at 20:18
  • @DA01 - I made up that 90% figure, but in reality it's probably higher when looking through Steve Souders' research. The actual quote from Steve Souders is, "80-90% of the end-user response time is spent on the frontend. Start there." stevesouders.com/blog/2012/02/10/the-performance-golden-rule
    – Steve Wortham
    Mar 16, 2012 at 20:46
  • Granted, some of these front-end optimizations require server configuration. For example, setting far-future expiration dates, using gzip, etc. But these are still things related to the static files (images, js, css) that make up the majority of requests on your site. Ideally these things should be on a CDN... but you get the idea. These are the things the user spends the most time waiting for (in most cases).
    – Steve Wortham
    Mar 16, 2012 at 20:53
  • I think that's a misleading statement at the source. The example site (linkedin) shows that in that particular case there the front end was 90% of the response time. But that doesn't mean it always is, nor does it mean that they hadn't already tackled the server side response issues to begin with. Granted, whether it's 10% or 90%, yes the front end optimization is a big factor. I'm just trying to point out that server side can be a big factor as well (especially when you get into services based systems)
    – DA01
    Mar 16, 2012 at 21:25
11

Since the User actually Experiences the UI performance -- good or bad, it's linguistically obvious that the performance is a part of the User Experience (UX).

Improve this answer
6

Naturally performance issues are part of the user's experience, it's just that it's not that simple to make them part of UX Design. We can't design them, that's the techies' domain. We can come up with performance requirements (and then they say it can't be done...), or design the product with performance issues in mind (e.g. optimized for AJAX as opposed to page transitions), but we don't have much actual control over it.

Improve this answer
5
  • 1
    I disagree. UX is about designing the experience, which includes the UI, which should include the presentation layer, where a lot of performance issues can be addressed.
    – DA01
    Mar 16, 2012 at 20:21
  • Yes, but just how do you suggest that we design the loading time of a page? Or, to take this away from the web, the loading time of a desktop app?
    – Vitaly Mijiritsky
    Mar 17, 2012 at 7:13
  • Well, there's the engineering part of the presentation layer...something I find is often a hard thing to do for true development teams, hence the desire for UX to be handling that part. And then there's designing for the experience with performance in mind...knowing when an AJAX call would make more sense...knowing when certain DB calls can be trouble...knowing how to give the impressions of performance when there are known performance hang ups, etc.
    – DA01
    Mar 17, 2012 at 18:43
  • Maybe a simpler way to put it: performance is usually much more easily achieved when UX and Dev are in sync with each other. Whether or not UX is doing the code is less important than UX has say and a vote into how it's being engineered.
    – DA01
    Mar 17, 2012 at 18:44
  • Well, that's precisely what I said, "design the product with performance issues in mind" :)
    – Vitaly Mijiritsky
    Mar 17, 2012 at 18:51
4

Yes.

We need to consider aspects of loading time when we create web sites since it affect the perceived usefulness of the web site. We need to consider if using large images or a lot of content or javascript is necessary. The front end developer and the back end developer is of course responsible of the code and the guy who decides where the web site should be hosted need to choose a hosting company with optimized equipments.

But what we as ux designers really could do is create a web site that is perceived as fast. Christine Perfetti and Lori Landesman have discussed this in the article "The Truth About Download Time" over at User Interface Engineering.

Microsoft has also written about the subject when it comes to software developement but some of the tips in the article could also be implemented on a web site. Read Optimizing perceived speed

Improve this answer
4

I don't think there is any question that response time is a key factor in UX design. Jakob Nielsen wrote about it in 1993, and last year. 37signals wrote about it two days ago. The fact that an interface is on the web doesn't diminish the fact that more than 0.1 seconds response time kills the feeling of direct manipulation.

Of course, web design has factors that lead to slow loading that we simply can't control. Poor connections and the user's choice of browser can turn a snappy interface into a gutshot iguana.

What we can do is make sure we have solid design for when the connection slows down or breaks, and push as hard as we can for speedy code. In fact, I often find that a sluggish interface points to deeper problems with UX design than the simple fact of performance. Trying to include all of the latest flashy widgets can distract from the fact that they aren't the simplest and most direct method of completing the required task.

Improve this answer
3

Yes, without any doubt. Anything affecting the users' experience is a factor to be aware of and act on, once it becomes a factor affecting your goals (and thus your users'.)

Improve this answer
1

Just to add one more point.

In the initial design of a product, it is probably not ideal for UX designers to labour on such technical issues - its a given that something like page load should be as fast as possible - it is in the camp of the developers to try to reign in the designer when they detect issues that may impact poorly on performance.

On the other hand, as UX designers we are often called upon to run audits on existing products and render times etc are factors you'd be foolish not to look at.

Improve this answer
1

Absolutely yes!

Jakob Nielsen, a usability guru, states in his book Usability Engineering (1993) that response time limits is an important factor of usability. An excerpt of chapter five of the Usability Engineering book is published on his web site and answers your question very well. Blockquote from the article Response Time Limits:

Q: "You mention many times that response time is important, and there are tons of tools to measure response time, but what is an acceptable web based application's response time? What is a user's tolerance, not for a shopping experience, but for an interactive application?"

A: I wish we could eradicate the term "web-based application" because it distracts from the real issue, which is one of application UI design. We don't have special guidelines for applications implemented in C++ relative to apps implemented in Visual Basic. The fundamental usability recommendations are the same, no matter the implementation, since we are discussing user experience, not coding.

Therefore, the response time guidelines for web-based applications are the same as for all other applications. These guidelines have been the same for 37 years now, so they are also not likely to change with whatever implementation technology comes next.

0.1 second: Limit for users feeling that they are directly manipulating objects in the UI. For example, this is the limit from the time the user selects a column in a table until that column should highlight or otherwise give feedback that it's selected. Ideally, this would also be the response time for sorting the column - if so, users would feel that they are sorting the table.

1 second: Limit for users feeling that they are freely navigating the command space without having to unduly wait for the computer. A delay of 0.2-1.0 seconds does mean that users notice the delay and thus feel the computer is "working" on the command, as opposed to having the command be a direct effect of the users' actions. Example: If sorting a table according to the selected column can't be done in 0.1 seconds, it certainly has to be done in 1 second, or users will feel that the UI is sluggish and will lose the sense of "flow" in performing their task. For delays of more than 1 second, indicate to the user that the computer is working on the problem, for example by changing the shape of the cursor.

10 seconds: Limit for users keeping their attention on the task. Anything slower than 10 seconds needs a percent-done indicator as well as a clearly signposted way for the user to interrupt the operation. Assume that users will need to reorient themselves when they return to the UI after a delay of more than 10 seconds. Delays of longer than 10 seconds are only acceptable during natural breaks in the user's work, for example when switching tasks.

These time limits work well for guidance of user experience on any application. To me "Sacrificing user experience for higher performance" is not an issue, since user experience is dependent of higher performance.

Improve this answer
0

Speed to load is everything. Slow sites are abandoned and rarely revisited. See http://www.codinghorror.com/blog/2011/06/performance-is-a-feature.html

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.