I was dragged into a meeting with a client to consult on any usability issues as we watched a user performing day-to-day operations with a software application.

The first thing that happened was that after the client double-clicked the app's icon we waited around 8 minutes for the app to load. No one in the room cared about that but me. They argued that what they do is start the application and have coffee while it loads.

Of course the user believes that the application is fancy, heavy and complex enough to load faster (and in many ways it is), and (of course) I couldn't argue (verbally) that the loading-times could improve inside that meeting with that user, so I wrote 3 technical recommendations to work-around the slow start-up time and presented them to key stakeholders. The suggestions were disregarded on the spot, as the customer didn't care about its slow loading times, since that's their time for coffee.

I know we should watch how our users work every day, but does that include coffee (or other activities that don't impact the business process directly)? Is this a good excuse?

Computer with Integrated Coffee Machine

Edit: added an illustration :)

  • 32
    No. no, noo. Please no. Nooooooooo. Nov 16, 2012 at 8:35
  • 67
    8 minutes, are you serious? You mean 8 seconds right? Nov 16, 2012 at 8:47
  • 25
    @BartGijssens You can never get good coffee in only 8 seconds! :) Nov 16, 2012 at 9:35
  • 15
    @BartGijssens: Don't be so quick in your judgement. Our client takes seconds to load, but our server can take from 1 minute up to 6 hours (yes hours!) to load depending on the configuration and sheer volume of data it loads into memory. 8 minutes for a client facing app is indeed a lot, but whether it is acceptable or not depends on what it is actually doing. And splitting it up into a quick loading client and slower loading server may just not be worth the effort. Nov 16, 2012 at 10:11
  • 18
    Build in some Wake-on-LAN functionality so the machines all start up 8 minutes before people get to work.
    – JonW
    Nov 16, 2012 at 16:30

16 Answers 16


To me, the basic logic is this:

It's better to have a fast app than a slow app. While there are many studies that show that faster applications provide better UX, it seems pretty axiomatic to me. I mean, generally in life if we want something done, then we prefer it to be sooner than later (with the exception of various aesthetic and, um, other activities where the point is enjoying the process... I doubt that an application loading is such a process although sometimes it can be made one).

The customer doesn't object to the app being faster, he just doesn't care. That's a big difference. If you make it faster, he won't come to you asking to slow it down because now he doesn't have time for coffee.

So, this is something that you generally ought to do, but you don't really need to. If it were free and you could do it with a click of a button, then I think the answer would be clear - you ought to do it. But it's not free, so it comes down to cost-efficiency. If you can invest your resources in something that the user does want, do that (provided it's the only user of the app etc. etc., as @yisela says). But if you have the resources available for this at a low cost, do something that would make the app objectively better - speed it up.

*Sometimes making specific processes slower can achieve specific UX goals. There was a famous case study where some process, probably saving or performing a calculation, was made instantaneous for a new release of a product, and users, who were accustomed that it takes time, weren't sure whether the process ever took place in the new version. This created a lot of confusion and they pressed the button over and over just to make sure it worked. So the developers pretended to slow it down by providing a quick loader or a progress bar or something, which helped put the users at ease. I can't find the link right now. But this is not the case here.

  • 1
    It may well be that the app is incredibly fast after the load. That is the case with our server. It is fast in responding to queries because of the "slow" load where it loads all data into memory... Nov 16, 2012 at 10:12
  • 2
    @MarjanVenema Why don't you just cache the data you use (and read-ahead in the background)? Then you'd have a fast start-up and fast queries. Nov 16, 2012 at 15:37
  • 3
    @BrendanLong: Who says we aren't? We are talking about data volumes of a mere 10 up to well over 200 GB (yes, Giga bytes). No matter how far and much you optimise that, it is going to take time... Nov 16, 2012 at 19:28
  • 6
    Careful; the issue here is a non-technical one. People using this app aren't self-employed and, as employees, seem to enjoy their free morning ‘coffee’ time. (Should I link to xkcd.com/303/?) Don't mess with people when they ask you not to, unless you are sure you understand the social dynamics involved. Nov 24, 2012 at 12:12
  • 3
    I love the part of "um, other activities"... haha :)
    – edgarator
    Nov 26, 2012 at 1:01

You should try performing A/B split testing to see which group of users is more productive. The first group will be denied coffee, but the application loads instantly. The second group will be given coffee while it loads.

I would propose that the second group, despite the 8 minute delay will finish the days work first ;)

enter image description here

  • 1
    Ah, but will the coffee group do quality work. My experience has been that coffee increases measured work. If you stop there it looks like a winner. However, if you look at the re-work resulting from all the extra errors that caffeinated workers make, coffee is a productivity loser! Nov 30, 2012 at 13:45
  • 5
    Talking bad about coffee is dangerous. Almost as many people have been hurt for disrespecting coffee as those who disrespected bacon.
    – Reactgular
    Nov 30, 2012 at 14:37
  • And suppose that the instant-loading app is lazy : it loads instantly, but then it keeps loading data on-demand during the day, each time making the user wait in front of an egg timer. Then, this makes the user less productive during the day, when s/he is not taking coffee. And this probably irritates the user, so this harms user satisfaction, and probably productivity. Feb 16, 2013 at 10:13
  • so if the coffee free workers were more productive, would you actually suggest removing coffee from the process permanently :-P
    – Toni Leigh
    Mar 3, 2015 at 20:50

But of course, Yes! You can never ever underestimate the value of a good cup of coffee. You know for a fact that coffee is the number one most important thing in an office which could make the office worker succeed or fail, at least according to Baltimore Business Journal:

The office coffee is more important than it seems

… workplace experts say that depending on how it is handled, coffee can either be a perk that fuels employee morale or an annoyance that steams up workers to the point where they feel alienated and disgruntled.

So the answer to your question is obviously yes!


  • 6
    I don't drink coffee and I'd say 40% of my co-workers don't either, maybe it's a regional bias, but it's enough to make me feel alienated and disgruntled :P
    – Yisela
    Nov 18, 2012 at 23:02
  • 3
    @yisela Let's talk about it over a coffee.
    – Reactgular
    Nov 30, 2012 at 14:37

Yes. Coffee is a good excuse, but it's not a good reason.

The important thing here, however, is actually that it is no big deal for these users. Really!

That's why you are observing them, to find out how they use stuff and feel about stuff. And for us software vendors this can be horrible and harrowing - because we care about other stuff.

These users have a job to do. And their software is just a tool they use to get the job done. This is important to realize. They don't go to work everyday to work with computers or to interact with your software. They have a job to do. If talking is an important part of that job, then they have to talk - and you have to let them talk. And you don't have to feel that you should have solved that task by implementing some chat solution for your software...

If you think about it, such situations occur all the time. We're all doing workarounds because our software/device/thing doesn't behave exactly like we want it to. Computers and software is probably the most important reason for Post-it's success.

I don't say that you should implement some 8 min coffee brake in your next solution. Don't do that! But respect that your users have another view of how their work should be done and which elements are important to achieve that.

  • 7
    I was actually thinking about including coffee tips in the application start splash screen... (learn about coffee while it loads)... :)
    – edgarator
    Nov 18, 2012 at 23:05
  • 2
    Would upvote this twice. Seriously, this is the most responsible answer here. Nov 24, 2012 at 12:15
  • 1
    I just read this answer again and +1'd it since, at another point in my understanding of UX it made more sense...
    – edgarator
    Oct 31, 2014 at 11:24

If this is a business critical application, then the following might apply to the non-coffee drinkers:

8 minutes every morning * 22 working days per month * 12 months per year:

8*22*12 = 2112 minutes into hours => 2112/60 = 35.3 hours, which very roughly equates to a whole working week in the UK.

If I was the boss, I'd be horrified! (However I do like a few coffees in the morning.)

  • 8
    That only applies if they sit and wait for the app to start. Once people know about the slow start up and the benefit is fast execution, they will know to start it and go do something else until is is finished. Boss doesn't lose any productive hours whatsoever. It would only be a problem if the software required a lot of restarts. Nov 16, 2012 at 10:14
  • 3
    Not forgetting that Coffee has been found to have laxative effects (although not a diuretic, as often thought) so if you're forcing users to have coffee you're contributing to their longer toilet breaks which also equate to wasted hours.
    – JonW
    Nov 16, 2012 at 16:33
  • 13
    I had a horse once, and I really managed to make it a cheap horse. After a few weeks I had weaned it off food. I was just about to wean it off water too, but then it died :'( Nov 16, 2012 at 20:58
  • @spuds I made the analysis from the perspective of monthly time spent in a month times the hourly wage for a number of concurrent users... looking at those numbers scare you; you present another interesting perspective to the same problem. It's like JonW example of how coffee drinking activities have a restroom overhead that it's commonly overlooked. So many dimensions!
    – edgarator
    Nov 18, 2012 at 23:03
  • Not 35.3 hours, 35.2 hours. Feb 16, 2013 at 10:16

I had this exact same "we take our coffee break while this is loading" experience.

However it wasn't our code and we ended up fixing it for free to the client and actually at a non-insignificant expense to us because we wanted to show the client that we were better then the previous vendor in hopes of winning more of their business down the line (which we did).

So if you don't fix it you leave yourself open to competition.


You mention your client declined your proposed changes, so I'm guessing this is an application that was custom made for him/her and you are not offering/selling it to other potential customers. Just curious, what's the program about that it takes it 8 minutes to load? I can't think of anything ever taking that long.

There is a correlation between user interface response speed and the perceived usability of a site or app. So the program fits with your particular clients' routine and they love it because it's fancy. Maybe it doesn't need to be faster. But is it a product you can sell? Is it scalable? Well, it will most likely not fit other customers. I don't drink coffee, what am I supposed to do while I wait? What happens if I need to use it as soon as I get in the office? Imagine I have someone on the phone waiting for my response. 8 minutes is a very long time.

You probably already know the reasons why this loading times needs to be reduced. My main one would be (apart from being very difficult to sell to other people) that users shouldn't have to adapt to the software, the software should be flexible enough to be effectively used by them.

  • do you have any references to the study that talk about the correlation between user interface response speed and perceived usability? The point that you raise about people that not drink coffee is really, good... I think that being aware of the whole user gamut is a good practice... And the nicest reflective question here is what if you're on the phone... pff! unbearable!
    – edgarator
    Nov 18, 2012 at 22:49
  • I couldn't find any for software. But there are lots of resources for web response time, and they might have elements in common (example strongeye.com/blog/2012/6/15/…)
    – Yisela
    Nov 18, 2012 at 23:00

To rephrase your question, do you as a usability/product guy have to think about what your users environment is outside of your app is?


Since the user uses your app in their environment, their reactions to what your app does OUTSIDE of your environment are important too!

Imagine if some process takes 8 hours to complete. Would you say we need to make it complete in 8 minutes? What if it's a once-a-month batch job? The users context matters in what your app needs to be, including speed and performance.

If your app loads only once a day, and they start it up at the beginning of day, then they may not care too much about the load time.

If you're a dev, think of it as JVM load time - happens once in a very long time. Doesn't really matter, since once it's up, it's going to stay up.

The real issue is the clicks in minute 4. That's a problem, since it means you have to get back and do that. Getting rid of those would be a good usability fix.

  • Exactly. The definition of usability includes "in a specified context of use". Feb 3, 2014 at 8:49

Accept the coffee excuse for now, but don't trust it.
One day your client will have an issue with the 8-minutes thing, like a lost deadline or flight, and they will blame you.
As their software providers you have to advice them, and letting them with such a long lasting process is no good advice. When the problem happens they will turn to you with an angry face, forgetting about the fun of the coffee thing.

In my experience with computers, which is waaaay long, I've seen many software pieces performing sluggishly, always because of bad software architecture design.
For example in 2006 tamed a 40-hour process into 20 minutes.
Or in the seventies a whole night task became a 15-minutes thing.
Or a database query from 20 minutes to sub-second in the nineties.
All of them, with exactly the same hardware.
You need to either make the 8 minutes task last a few seconds or redesign the system so it happens out of the user wait time.
Ideally, you should do both.


There are a lot more questions you need to answer before you decide whether or not to spend the time and resources improving the performance:

  1. Do other customers use that application?
  2. Are you actively trying to market it to other customers?
  3. Is the loading time a hindrance to selling it?
  4. Is the loading time a hindrance to development/testing?

If the answers to all of those questions is 'no', then don't bother improving it unless you have developers twiddling their thumbs.

If there is a 'yes', then this is a standard cost-benefit question.


A single data point from a person surrounded by the “enemy” all watching him like hawks is not scientific.

Let’s imagine for a second that eight minutes is acceptable. You will need to survey a significant percentage of your users in order to make that kind of analysis.

Even if this one user claims not to mind the eight minutes, this is almost certainly an example of the user adapting to the situation rather than they being happy with it. People don’t know what they want. But if a competitor came along that started in seconds and generally paid attention to usability rather than brushing it under the carpet, your client would want to switch.

  • Who talked about an enemy here ? Feb 3, 2014 at 8:45
  • It’s in quotes. So I meant it as a metaphor.
    – Max Howell
    Feb 3, 2014 at 17:07

An interesting way of using does "context of use matter" I guess? The answer is "yes, it does", and you can get a good overview of such variables on the web, starting perhaps with the NIST CISUR document (Level 1) which covers different aspects of context as illustration.

Common Industry Specification for Usability - Requirements


Fundamentally, what you're pointing towards is the essence of user experience: real users, real tasks, real interruptions, real answers about what constitutes the job being "done" and so on. Or if you like: "It's not just how you click, it's how you work".

To answer your literal question, I would caution using the findings - 8 minutes is way too long, but coffee as a variable is not a reliable finding. Could you reproduce it in other scenarios? Reliably? And design around it?

(*As an Irishman, I can relate to maybe waiting eight minutes for an app to start if a pint of Guinness was being poured properly during that time, but other user cohorts and locales would undoubtedly not wait as long...:)

  • Yes, this is a context of use joke outside of terms, contd, p. 94 etc. It's very wrong to drink in the workplace, natch.)

This is bad programming - it doesn't take into account the user at all. From your description it sounds like there is no UI displayed while the application is starting up, e.g. there may be some I/O or CPU bound blocking operation going on in the background, which the app is waiting for. In this case, tell the developers to do it on a separate thread and at least load the UI, even if some of the features or commands are not enabled. If the full UI can't be loaded, then just display a 'starting up progress bar' window, with a estimated time to completion. Any UI is better than no UI at all.


Yes. Coffee is a good reason for leaving the slow startup time.

The users drink coffee during these 8 minutes. We can guess that they chat between themselves, they share the latest information… The users don't need the app to start faster. So you don't need to make the app start app faster. Developers don't make software for software. They make software for users — the U in UX.

What you propose is like improving the speed of my car so that it can run at 130 km/h, although I only use it in the city and don't need it to go faster than 100 km/h.

And we can suppose that the slow-loading app is then quick during use, because it has already loaded the data.

Imagine you redesign the app so that it start instantly but lazily. Then, the app would keep loading data on-demand during the day, each time making the user wait in front of an egg timer. Then, this would make the user less productive during the day, when s/he is not taking coffee. And this would probably irritate the user, so this would harm user satisfaction, and probably productivity.


According to Susan Weinschenk in 100 Things Every Designer Needs to Know About People:

Lindsey St. Claire (2010) and her team found that if men drank caffeinated coffee while completing a stressful task, it impaired their performance. Women, on the other hand, completed the task faster if they had been drinking caffeinated coffee (p. 192).

So if the workgroup is predominantly female and the task is stressful, having a built-in coffee time could actually increase productivity. ;)


You don't have enough information.

You need to think more like Sherlock Holmes. You should go in the morning and observe what happens during this coffee break. Be as minimally intrusive as possible. See what they are doing & talking about. Is it important? Perhaps they have a short scrum meeting over the coffee machine. Perhaps they agree on overall tasks for the day. Whatever they do, they want to keep doing, so it may be important.

You could try arranging for the coffee machine to be broken one morning to see what happens (kidding (mostly)).

You say coffee is "activities that don't impact the business process directly", that's your assumption. You need to validate it before you act on it. You could inadvertently stomp on some important behaviour.

Even if they just chat, it could still be important to your business. If you ruin their coffee break, they might find an excuse to get rid of you!

Your Answer

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

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