Perimeter Sweep:            An Assortment of Stuff from Gary Horton

I'm not an HCI expert, but nonetheless I will blather on here about ease of use, in particular with software products and from a developer's perspective. This is a topic that our team wants to bring to the foreground, so I save my thoughts here as part of the discussion.

The first question, "what is it", requires no particular expertise to answer; it requires, I believe, only some experience as a so-called customer. Here, for instance, is a low-res photo of yours truly in one of my thirstier moments, having just purchased some beverage, albeit in an adult-proof container:  

No, it's not a recent photo, but thanks for asking. Anyway, I did finally get that plastic top unscrewed from what admittedly appears to be a tube of blue toothpaste, and clearly burned some calories getting it done. It was no mistake that I was dressed for breaking a sweat, since I knew what I was up against: a beverage in a squeezably-soft toothpaste container protected by an adult-proof screw top, but, hey, haven't we all been there?

My point is that we've all been customers of products, some of which we find easy to use, and others...not so much. So we're all qualified to define this ease-of-use thing; I offer a simple, general take on it: it does what I think it should with a minimum of fuss...alternately, I'm able to learn the thing quickly without reading the manual .... or, it helps me more than it annoys me ... this list can go on. But I defer to anyone who has an opinion: "what is it" is a subjective thing, defined by the customer, in the context of the particular product in question.

This customer thing lends immediate insight into the next question: who wants it? Well, of course, it's the customer - which includes you as a developer, if you are for example using components provided by your teammates. Assuming then that customer satisfaction is important, the notion of providing ease of use should matter immeasurably to developers, since it can be argued that customers are our raison d'être. This is French for (1) the reason we have marketing and sales departments and/or (2) why we stopped waterfalling and learned to love requirements changes.

So we assume a "customer-centric" approach....whatever that means. Well, I suggest it means more than just the look-n-feel of a product, and that getting to "ease of use" involves a comprehensive set of issues. Which brings us to our third question: how do we get some of this ease-of-use stuff? Sure, engage the customer...for starters. But from a developer's viewpoint, and in particular from my experience, there's a bit more needed than that. Here's my list:

1. Engage the customer

2. Engage an HCI expert

3. Requirements drive the What, developers address the How
   

4. Design from the top-down

5. Design for optimized user experience

6. Adjust your process to allow for course corrections

Now, I want to elaborate on each of these, but - in the spirit of ease of use - I end this post as a brief introduction. I will continue to blather about each of the above items in upcoming days and weeks, so please check back.

I close by repeating that ease of use is gained by addressing more than just the GUI or BUI presentation, and in fact applies to not only the process used to get to this user-facing end-game, but also to all layers of the software stack that support it, to include component interfaces, APIs and architecture. My definition of interface includes the "contract" defining that interface, and my definition of customer includes developers who act as consumers of APIs, contracts, etc. So, in future posts, I'll detail my six bullet points with a holistic view.