Sign up with your email address to be the first to know about new products, VIP offers, blog features & more.
[mc4wp_form id="4890"]
Zapisz Zapisz

Ask for Actions but Deliver on Intent

Posted on 0 No tags 0

I was using a third party system this weekend – 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.

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

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.

Another example of this that’s closer to my daily use is that our donation forms don’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.

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.