Click is as click does

How much of usability is context? Twice last week, I came across instances that illustrated the risk of allowing best practices to turn into heuristics.

First, a colleague sent me this piece of Nielson wisdom to help validate a design decision:

Error prevention – Jakob Nielsen: "Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action."

A common way of eliminating error-prone conditions is to disable command actions till the action is actually valid in a business sense. But does this work every time? Maybe disabling command buttons to prevent errors works really great on an installation wizard. Or for an online financial transaction. But say you apply it to a Login screen of a web application to eliminate common error-prone conditions. So, the Login Button is not enabled until the Username and Password fields are filled by the user. This certainly does prevent a few error scenarios. But does it make sense to the end user? I'd say it would surprise the typical user - the user enters the application login screen and sees that the one action that he wants to carry out is disabled – it is not common to see the Login button disabled, so instead of entering his credentials, he begins to wonder if there is something wrong with the application.

Here's another example:

'Don't make me Click', posted by Google Tech Talks on April 2. A snippet from the Abstract:

"What's made Google search, Facebook, the iPod, and Firefox household names? They all keep interaction to a minimum. The best presentation of content is the one which requires the least number of clicks and choices. Information overload is daunting: Few clicks and choices means more people stay and use your site. Avoiding interaction seduction allows you to create interfaces that are easier to learn and faster to use with surprisingly delightful interfaces."

The talk throws up several interesting ideas and Aza Raskin is a very good speaker. The line 'The best presentation of content is the one which requires the least…' from the abstract reinforces cult wisdom about minimizing clicks on any UI. But it speaks of usability independent of context. Usability can't be universal – you can work to arrive at what's potentially the 'best' interface for a specific context, for specific user groups with specific user goals.

When it comes to consumer web sites that try to cater to large audiences distributed across the globe, good experience gets defined basis a lot of research, prototyping and usability testing. I think that Facebook offers an excellent, compelling user experience to a certain demographic – technology savvy, literate web users in the 15-40 years age group. Maybe a different demographic finds the lack of clicks disconcerting – I don't know this, but it's likely to be dangerous to assume.

Bottom-line - I'm inclined to think that when it comes to usability, there are no rules, just learnings.

 

Of Enterprises and UX (and my feeble attempt at humor)

Moiself back to blogging...and the topic of choice one that has been discussed before on this blog here. But I'm wiping the slate clean, and starting from scratch.

So why do we need good UX in the enterprise? Why does Dan the Robot (I hate my job!) who is a data entry operator entering a couple of hundred records everyday in the same form need good UX? Or Midas the Dashboard Freak (I love trend curves!) who is the Founder CEO who looks at the same dashboard on the BI portal and once a week does a bit of drill down?

Answer - Dan is just weeks away from being certified of OCD. Midas will soon want to see trend curves of some other company.

Bob (I hate keyboard shortcuts) is replacing Dan and can't figure out how to save the record he has so painstakingly typed in, moving from field to field using a mouse (snicker snicker). Bob is, to his credit, smart and looks for every possible synonym of "Save" but no luck. He doesn't want to click the wrong button, and after a few minutes, the new web-based ERP application times out and asks him to log in again.

The ERP application doesn't automatically save drafts a la Gmail. It also doesn't have a simple java-script validation which lets him know when he hasn't saved the last record if he by mistake clicks on the wrong button.

Bob is about to embark on the unenviable journey of typing in 30 fields of a purchase order again. But before he does that, he calls the ERP vendor's customer support. By the time Bob tells them his problem, which form he is on, and finally being told he was supposed to hit the "Upload" button, its 30 minutes of support staff and employee bandwidth wasted. Heck, building the save draft feature and a java-script popup would have taken that long if you had a good developer.

The ERP vendor's problem, as their customers grow in employees, so does support staff. And what about training the support staff and the new customer employees? They have to hire more trainers. But first the trainers have to be trained, but the next version is on its way out....and so on and so forth.

You get the idea, so we'll leave Midas's replacement alone.

But how do you redefine (rather create) the UX for an application that is on version 8.114, with each customer having customized it for years, both UI and business logic? Each customer has also done in-house customization in the form of custom fields, workflows, screens, integration with other applications etc etc. Let’s assume for the moment that the application is well designed, and has a clean separation between logical layers so that it is possible to just do up the UI without touching the business layer (those familiar with some niche enterprise apps will know this is quite a big assumption).

My thoughts in steps below:

1. Start with workflows, identify a few key ones which are frequently used and can deliver significant reduction in support calls. Refer the years of support desk data, talk to end users, training staff, in simple words as many users as possible from all sides. Some enterprise app vendors have partnerships for support, custom development, training etc and they need to figure in the group also.
2. Figure out how each workflow has been customized, pick the most common customizations, incorporate this into the workflows, and this becomes your fodder.
3. Most enterprise app workflows have multiple actors, each doing their bit to keep it chugging along to its logical endpoint. Identify them, know them, understand them.
* How many times each actor does it in a day?
* Do they do it in batches or as and when it comes to them?
* Business criticality of each task which indicates their position in the corporate ladder or whether there is a dedicated person for the task?
* How many people do that task in a typical organization?
* Profile each actor on tech awareness, age, qualification, and maybe even the level of churn in a typical org for that role.
4. Now you know whose life you are going to make easier, and it’s time to get down and dirty. You redefine the UX while working with a few wise ones of the "I write code" variety who can evaluate feasibility. The end product of this should be a set of wireframes for each workflow. The most important aspect to be considered here is that these are workflows a lot of people are USED to. Doing a complete rethink with no consideration of how they do it currently is going to meet with stiff resistance. A complete rethink has to be done in phases, with end users being trained gradually to use the new improved UX. A small user study at this point might be useful in gauging the amount of resistance you are likely to face with the new UX.
5. Create a prototype of new UX based on the wireframes which comes as close as possible to the actual application.
6. Test this prototype, by recruiting actual users from customer companies. You know the actors, and also the common denominator of their profile characteristics. Create a good sampling frame. A good usability testing tool should be used and Morae comes to mind. Focus group discussions can also help here to gather overall opinion on the layout, organization, and navigation.
7. Feed test results back, and iterate the prototype as required.
8. Identify the standard enhancements, as these will be implemented across the application.
9. Develop the new UX, but only for the identified workflows. Probably not fully, but to the extent that a complete impact analysis can be accomplished.
10. Evaluate the cost of each standard enhancement across the app.
11. Create a comprehensive road map based on:
* Cost of each standard enhancement.
* Development/testing effort for each enhancement.
* Non-standard enhancements which need to be done when redesigning other workflows. This also has to consider the discovery time required for these workflows. However, this effort shouldn't be as lengthy as before. This is based on the assumption that the initial workflows selected are a good representation of the entire gamut of UX issues across the entire application.
12. Develop the new UX, considering time for usability study for new workflows taken up. Again, this shouldn't take as much time as before.

There are many areas above where I am debating with myself. Those I leave for the next post.

Microsoft's Open XML is now a Standard

This just off the press. And no April Fool's joke, it got slashdotted to me.

The ISO approved Microsoft's Open XML as a standard putting it in the same league as PDF, HTML and ODF. For those who haven't been following the debate, Microsoft has been lobbying for this for more than a year now ("over 14 months of intense review", according to MSFT) and fighting opposition from IBM and Sun.

The implications:

• This gives Office 2007 a big boost, marketing wise. With competition coming in from online office tools by the likes of Google and Zoho, having control over a standard is a big deal. (Zoho supports OOXML currently, btw.)
• Apple, Novell, and even IBM now are writing apps that support OOXML.
• It will setback the adoption of Open source Office tools in the mainstream; national bodies of countries vote for these ISO standards.
  

Why should you care about this? If you have anything to do with writing applications for document management, content management, office business applications, interoperability, this is a format you need to understand. More work for us to do.

Problem is, OOXML is still buggy. From Rob's article

Among the defects are some rather serious ones such as:

• storage of plain text passwords in database connection strings
• Undefined mappings between CSS and DrawingML
• Errors in XML Schema definitions
• Dependencies of proprietary Microsoft Internet Explorer features
• Spreadsheet functions that break with non-Latin characters
• Dependencies on Microsoft OLE method calls
• Numerous undefined terms and features

The April fool's joke on this has to be from Linux fans.