By Michael Woloszynowicz

By Michael Woloszynowicz

Saturday, November 27, 2010

3 Groups You Must Design Your Application For... or Else

I recently completed the task of redesigning and implementing a large component in our web-based application. In doing so I have learned that you have to design your application for three groups of users and have an intimate knowledge of what creates value to each one. Before I go into detail about these three groups I'd like to give you a little bit of background on how I got to this point without going into the details of the implementation.

My goal was to create a more flexible, portable, modern, and full featured tool than the clunky third-party Java Applet we were using to date. After 6 months of back-end and front-end coding (see Dojo Lessons for some front-end programming tips I learned in the process) I produced what I and my co-workers saw as a tremendous advancement from what we had. The new tool had all the things I set out to achieve but the end-user response was lukewarm at best. How could this be I wondered, can't people see that this tool vastly better than what they had before? The navigation was improved, the amount of useful options was expanded, it was more reliable, and most importantly it allowed us to implement some of the functionality that these very customers have been asking us for, but we were unable to add due to the restrictions imposed by the existing tool. After some feedback from our Beta version we discovered that most of the issues arose from one aspect of the tool which users found more cumbersome and time-consuming than what they had grown accustomed to. While 95% of the functionality was improved, to the end-user the remaining 5% superseded all of this and rendered our new tool a dud. Our end users didn't care about the added functionality, the fact that it was AJAX based vs. Java based, or the fact that we could now implement their other desired features. The reason is that this small component consumed 95% of their use and time, so no matter how great everything else was, if it wasn't as easy as before we couldn't convince users to use it. In the interest of keeping our customers happy I proposed a second alternative which would save time but still maintain portability. We were sure this new version would resolve any objections. Sure enough it wasn't, it was still a bit more time consuming than what was offered by the basic existing applet so users still complained. Finally I accepted the fact that we had to add a third option using a new Java Applet that would restore the previous functionality while still giving us all of the advantages of our new tool. We now have three options for completing the users crucial task, each with varying levels of portability but without sacrificing our initial goals.

Now on to the primary point of this post. When I set out in designing this tool I had considered the existence of the three groups but underestimated the importance of each one. First off we wanted to design for the end-users' managers as they are the ones we sell the software to. These managers wanted reliability and improved performance that would result in a better consumer facing experience. We then designed for the end-user by trying to design an interface that was similar to tools they use on a daily basis and provide some much needed functionality enhancements in an easy to use package. Finally, we designed for ourselves by keeping future expansion and value enhancing features in mind. We knew from the start that the one element of the new tool was slightly less efficient than it was before but we also knew that this was the way most companies did it, and that the other improvements would surely convince people to overlook this. This thinking was correct in the context of new clients who loved the new tool, but as we know, people are not amenable to change and existing end-users complained furiously. What we did right in this process was slowly roll out the new tool, all while providing access to the old one, while actively soliciting feedback. Although the response we got was not what we wanted to hear, it prevented us from loosing a good chunk of our clients and allowed us to improve the user experience.

The lesson therefore is not to underestimate the power of the end-user and always find out what the most crucial aspects of your application are. Remember that what is seen as a value driver to you or to a purchasing manager or exec, is not always the case for an end-user. The biggest source of value for the end-user is having your software help them accomplish their task quickly and easily, and if it fails to do so they will complain to their managers, complain to their co-workers, and go from advocates to saboteurs in an instant. One exception to this is enterprise software where initiatives are often assigned in a top down manner with end-users having little say, hence the dismal usability of many ERP systems. Those however that target small to medium size businesses with a subscription based service must remember to identify the sources of value for every class of user and incorporate them into your designs. Design for the buyer, the user, and yourself, be proactive in soliciting continuous feedback, and remember that little changes can make a world of difference.

If you liked this post please follow me on Twitter for more.

No comments:

Post a Comment