Monday, April 7, 2008

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. Meanwhile, I humbly request all of you to criticize the above process to death which would drive the content for my next post :).

0 comments: