Ask for Actions but Deliver on Intent

I was using a third party system recently - naming no names - and it managed to frustrate me by the way that it handled a lagging UI experience.

I know that had the UI remained responsive this problem wouldn't have surfaced, but its a far more common problem than you might think; it simply made itself obvious to me because of a stale view.

What’s the problem?

Let's say that there's a list of items. Your user selects one and asks the system to "remove" it (remove/delete/archive - not important). There's one error that you should never present here:

ERROR: _______ does not exist!

What's happened is that a system routine was asked to remove something from its context. Trouble was, it was already removed - the "actual error" exists in the view that was showing it present in the first place. However, the next error is that the system took its user literally (something that's of great value when defining nuclear control systems, but not so useful in a general-use application).

Take the win

You see, I didn't want the system to remove the record. I couldn't care less about how it keeps track of things internally. My intention was that, after I pushed the button, that record shouldn't be there any more. The fact that it didn't exist wasn't an error to me, it was success!

Its great to keep the UI in terms of taking actions on things. That's a well-understood metaphor. But before taking an action - especially before reporting an error - a well-designed system should consider what end-state the user is actually looking for by their interaction with the system and respond accordingly.

You can filter many cases

Another example of this that's closer to my daily use is that anything that takes money, like donation forms, won't allow a user to "double-click" their DONATE buttons. We disable the DOM element, but also have logic client-side to figure out when they managed to do that despite that, and then again on the server to catch it if the client-side code screws up. Nobody wants to make two donations within a second by double-clicking on the DONATE button, so that's never a valid interpretation of their actions.

As a bonus, if for some reason the UI does manage to send us two parallel donation requests instead of one, not only will we only process one of them, we'll simply return the same (hopefully successful) response to both requests, helping the UI code to do the right thing and not confuse the end-user with an error message when we likely have fulfilled their request.

In the end

Is this more work? Absolutely, but its our role as technology providers to do a small amount of work so that many, many end-users can each do a little less, and use their systems a little more familiarly. That's where we add value.

And if I’m being honest, its not that much more work.