"Help" the Users, "Help" Our Systems

I have been thinking about this for a while, and I am pretty sure that many others do too: try to "help" the users to use the system in the way the system works best.

Software systems are tricky, as we always know. It may be good at something, but really bad at somethings else. No matter how we design the system, how to implement it, or even how advanced the hardware might be, we can't satisfy all users in all aspects. I don't think we want to build a system good at everything, but we are building system to help. If it helps, then it is good. The trick is, whether our users find it this way. Or they just keep using something the system is not supposed to be good at and keep complaining about it.

I am not saying we want to make a system can't fulfill the requirements. But if our system are really good at something, and that is something very helpful to our users, we should lead the users to find it, and use it, and, hopefully, they agree this is what they need.

This is especially important in the Big Data era. For example, most of the Big Data solution are good at batching processes, but not good at on-demand request/response. Although we admit many users do want instant response for on-demand queries, but batching model can help in many way, and we should utilize its strength as much as possible. One thing we can certainly think about is asking the user to pre-config their possible query, and have the system batches those query for possible queries. We can also implement asynchronous query and notification UI, so that a user can fire one query or many, then continue working on something else, until he/she gets the notification for a finished job. This won't solve all problems, but by comparing having the system tries the on-demand request with best efforts, and having our users waiting in front of their computer watching a forever spinning circle, the asynchronous process workflow is much better.

The picture I used below is not necessary match what I said above exactly, but it doesn't point out something: with proper UX design, we can emphasize a way to lead the users for a direction we expect them to do. Say, if a system is good at working on additions, but bad with subtractions, we can design the UI to lure the users focus on additions for 80% of their time, which will definitely help relieve the burden of the server, and ease the users for possible complaining.