feedback - How can I maintain usability on a slow system?

Obviously a huge part of a positive UX is a fast, responsive design. The software I work with (Electronic Medical Records) is sometimes used on sub-standard devices (e.g. ancient desktop PCs) or in places with overloaded networks preventing data from appearing quickly.

Outside of having an entertaining 'loading' indicator (e.g. pinwheel of death, hourglass, etc...) are there any good UI/UX strategies to plan for or adapt to a situation where the software is handling sluggishly?

Answer

If at all possible, Asynchronous processes can be wonderful depending on what the slow part is. If you can keep the client-side GUI "live" instead of halting all use of the system between actions, your system can feel much faster and less frustrating.

As an example, I recently constructed a data-driven application which needed a responsive UI but needed to complete a slow (~1 second) update process before it the data could be operated on.

However the client side controls didn't really depend on the data; what I did was present the fully working client side GUI while the background process runs. This allows the user to start using the system to construct their query before the query can actually be performed; most of the time the users can't start their query before the background task even finishes; it's instant! In the other cases, the users simply have to wait until the background process finishes.

The system seems faster because I don't inhibit the user's actions while the system is still processing. This is ideal and makes your UI feel much more responsive, but it isn't always possible. Make sure you don't allow the user to begin any conflicting tasks, but if the user wants to perform an unrelated action (like bringing up a Help menu) while waiting for a background process to finish you might as well let them.

This won't work when the user needs the data to be loaded before they can do anything at all, but keep an eye out for things you can load asynchronously. If you're loading 3 views of data, loading them one at a time (with separate loading indicators) can feel much more responsive than loading all three at the same time even if the total execution time is the same.