In my last post, I talked a bit about Scaleable UE, or the idea of a user experience which intelligently grows and adapts to your usage and your subscription state over time.  I gave some examples, but I thought I could illustrate the point a bit better by talking about a particular function I’ve been working on and by describing the balance of too much versus too little usability that has to be achieved to produce good UE.

Trading Grid Online has a good on-demand custom search/report facility.  You can ask questions like “show me all 850s in the last 3 days from interconnect trading partner X which have been rejected inbound to the GXS.”  Of course, you use a form rather than natural language to specify a query like this.  I want users to have the ability to save these reports as one-click canned reports in the future–that makes sense.  However, users often need to run a few queries in a pinch and work on the results without thinking about the long term.   Nothing shortsighted about that.  Business is fast.

So I’ve been toying with thoughts on how best to help users store common queries as canned searches without being disruptive or taking extra time.  At first, I was thinking that we could count queries and when a user runs an identical more than X amount of times in a certain time period we could show an option saying “You’ve run this query X times in the last Y.  Would you like to name it and save it as a quick search?”  That would be slick and probably useful.  It lets you do the things you need to do and helps you scale up your usage without having to do a lot of up front work.

However, there’s a downside.  It requires defining X and Y up front.  If we said a report run more than 3 times in7 days would trigger this notice, you can imagine that troubleshooting a specific problem with a specific trading partner might result in trigger this several times even searching with a specific control number which would not be useful as a saved search.  If we set the bar too high, users will have to run common reports over and over again before it triggers.

An alternative is to track a certain number of queries–say, the last 30–and keep a count.  If we show a rolling list of top queries with a count, users can re-execute common queries without any extra steps.  Also, a user could identify queries from the list they want to save at any point.  This approach accomplishes many of the same goals, but also provides a work-free way to re-execute queries that I might not want to save but might be using frequently for troubleshooting a specific problem in the short term.

One of the toughest jobs in usability is to find an approach which facilitates users without disrupting them.  A common misconception about usability is that it strives to replace the user’s need to think.  Business users are smart, but they’re busy people.  An approach which lets the user think and judge in a fast and facilitated way is often the best approach.  If you think on the first possible solution for a while, you can see that even if you come up with the magic value of X and Y (number of report runs and time) for one user, it might be very different for another user’s habits.  Then comes the endless proliferation of config options.  Nothing simple about that.  Let the user drive, but make sure it’s with a smooth steering wheel.

Automotive analogy in tribute to Mark Morley.  Hope that wasn’t too boring.  I wanted to give you a bit of insight into how we approach design and usability factors and I felt like I left the last post hanging on too theoretical a note.  Until next time.