Opal UI Case Study Part I: Architecting the User Experience

Web Applications have been around for years, what makes RIAs different? Answer: The User Experience.

At Bits And Pixels we do one thing: Architect Rich Internet Experiences. Although it's our tagline and may appear to be blatant marketing speak, it's not. Our focus in RIA development is usability and the user experience. It is the user experience that sets RIAs apart from existing web applications and the usability of an RIA, just like the usability of any application, will ultimately determine end user acceptance or rejection of the product.

In software development there is a worrying statistic: According to the Chaos report (the Standish Group, 1995), over 75% of all IT projects fail. Failure can come in the form of user rejection or schedule and budget overruns or both.

Over the years, the field of Human-Computer Interaction (HCI) has developed guidelines for User-Centered Product Development. In tandem, progressive software engineers have flocked under the banner of the Agile manifesto and Agile development methodologies such as eXtreme Programming (XP). This year at CF-Europe, I presented a session wherein I highlighted our development methodology at Bits And Pixels: User-Centered Agile Product Development (UCAPD). That session was based in part on my experiences with Ali and Steven on Opal (they are devoted and effective practioners of XP) and in part on my (ongoing) devotion to the study of HCI, including ergonomics. As someone who has been using a computer for over 19 years and suffers from Repetitive Stress Injury (RSI), I have a very personal interest in making applications usable and ergonomic and believe that all software manufacturers should be held accountable for the ergonomics of their software.

Although over 75% of all IT projects fail, the secret to a software project that does not fail is very simple: Know your users, listen to your users and keep listening to your users as you develop. XP states that the customer should be a member of the team. Most times the customer and the user will not be the same. In these cases, UCAPD states that both the customer and the user should be part of the team. In fact, this is a conclusion reached by many XP practitioners in real-life, and is even outlined in the excellent book eXtreme Programming in Action: Practical Experiences from Real World Projects (Lippert, Roock & Wolf). The customer is responsible for handling the business domain but it is the user who has ultimate say in whether or not an application is usable.

In developing Opal, we asked but could not have access to independent end users (enterprise users of Opal). Instead we had to make do with the customer as user. As such, from a UCAPD perspective, we built Opal for user acceptance by the customer. In that regard, it passed with flying colors. In this instance, our customer was also a previous/current end user and thus I was less hesitant to press my case. In a manner of speaking, our customer was also our user and although I would have liked access to independent end users (at least to minimize the chances of an "ought to" error* creeping in), it was not a show-stopper in terms of development.

Application development is all about risk management. Having a solid Agile development process and a focus on the user, usability design and usability testing all work towards minimizing risk while embracing change.

In the next installment of the Opal UI Case Study series, I will take you through Opal's high-level usability and UI design decisions, starting from the brief and exploring emerging usability design patterns.

* "Ought to" errors are sneaky little things. They arise when managers have expectations of how end users "ought to" perform their tasks. It is not uncommon that these expectations carry little or no relation to how end users actually perform their tasks. The unsuspecting developer ends up developing an "ought to" system that meets with initial management approval, followed by end user rejection.

Comments