Is coffee a good excuse for a slow application start-up time?

Question

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?

Edit: added an illustration :)

Answer 1

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.

Answer 2

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 ;)

Answer 3

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!

;-)

Answer 4

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.

Answer 5

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.)

Answer 6

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.

Answer 7

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.

Answer 8

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?

HELL YEAH!

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.

Answer 9

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.

Answer 10

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.

Answer 11

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.

Answer 12

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

http://zing.ncsl.nist.gov/iusr/documents/CISU-R-IR7432.pdf

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.)

Answer 13

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.

Answer 14

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.

Answer 15

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. ;)

Answer 16

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!