The Business Controls Caddy

Understanding COBIT: User-Machine/Graphical User Interfaces as A Control Objective

Have you ever seen one of the people who will be users of your current project?
Jakob Nielsen in "Usability Engineering"

A week or so ago, Scott Good of Teamwork Solutions mused that one of the reasons that people do not like Lotus Notes is that many of the applications they use have a amateurish or poor user interface. As a result, they think the application as a whole, as well as the software used to run it, is lousy or inadequate. What happens here in cases like this is that user acceptance of the application is low to nonexistent, introducing risk that the business objectives that the application was designed to meet will not be met. How then does user-machine interface fit into an information systems controls framework such as "Control Objectives for Information and related Technologies" (COBIT)?

Well believe it or not, the user-machine interface is covered explicitly under COBIT. If you remember back to my posting entitled "Understanding COBIT Part I: What is COBIT and Why Does It Matter?", COBIT contains generally accepted information technology control objectives as recognized by information systems auditors around the world. Under the "Acquisition and Implementation" domain, there is high level control objective AI2, Acquire and Maintain Application Software.

For those of you that attended my Lotusphere 2005 session, you may remember that I talked about the high-level control objectives and the fact that each of these had a number of detailed control objectives. AI2 is intended as to enable "control over the IT process of acquiring and maintaining application software that satisfies the business requirement to provide automated functions which effectively support the business process" (Source: IT Governance Institute).

It Is All About the Users

Here is where we get to the heart of tying Scott's thoughts to control frameworks, specifically COBIT. Under Detailed Control Objective 2.9 - User-Machine Interface, the "organization's system development life cycle should provide for the development of an interface between the user and machine which is easy to use and self documenting (by means of online help functions" (Source: IT Governance Institute). In plain English, this means that the interface between the user and the application needs to be intuitive, non-distracting, and easy to use. This also means it needs to look good and function according to the needs of the user, not the developer(s). Let me repeat, it is all about the users, not the developer(s).

Who is Scarier When It Comes To GUI Design?

This is an important question. As Scott pointed out in his posting, "it is exceedingly rare that we go into a project and find an application anybody else has built that looks worth a damn". But whose fault was the poor interface? Did the developer(s) try to build a decent interface, but ran headfirst into a customer who really wanted the flashing red graphics or the putrid green color pallette? Did the developers ignore the customers request and decide what kind of interface to give the end users? Or in the end, did the project plan and the organization's system development life cycle not even address the issue? In all of these questions, the presence of controls that address this issue would help tremendously to mitigate the risk. As the developer of project manager, you may have to work extra hard to convince the customer of the importance of user interface work as part of the project, but it can be done.

"We Did Not Realize the Importance of a Graphic Artist In The Project Plan"

A few years ago when working for Lotus Professional Services, I was called to join a project that was failing because of user-interface (UI) issues. My task was to review the UI, recommend changes, and when approved, implement the changes. It was like Scott said, you know good design when you see it, and this interface was in need of serious work. When the project ended and my evaluation was being prepared, the Project Manager noted that by assigning a dedicated resource (me) to this task, the customer then realized how important it was to address UI issues and assign dedicated resources to this task in the initial project plan. Because it was not addressed initially, the customer had to spend additional money to get the UI overhauled.

Recognize Your Teams' Limitations and Get The Right Resources

If the graphics/UI skillsets of your development team does not extend beyond MS Paint, then make sure you have resources that can address UI issues. It is a waste of coding resources to work on UI issues instead of functionality. If the company does not have a system development life cycle that includes user-machine interface design, then you have to sell it to them. Why? Because of the application fails because of lack of user acceptance, guess who is going to be blamed? And if your contract is poorly formed, you might end up having to fix problems on your own nickel.

You Are Never Going To Make Everyone Happy, But Push Back When Needed

Everybody has their own view of what looks good and no two people will agree 100%. Because of this, it is important that you build consensus with a good cross-section of users. It may require compromise on the part of everybody, but it may mean just saying "no" when you have to. Back in the late 1980's, I was designing on air graphics for a television show called "Food Business Today". You have not lived until you have designed graphics for corn futures prices:-). One evening, I had a young, inexperienced associate producer working with me and she said "Why don't you make the (full-page) graphic with a nice bright yellow background?". The one word answer was "No". I had to push back because I knew that you could not use yellow like this in an on-air graphic, or at least I would not do it if my name was going on the credit roll at the end of the show. She was upset, but the producer backed me up and life moved on.

Yes There Are Compliance Issues

User-Interface issues are not limited to customer acceptance of an application. There may also be legal or regulatory requirements that need to be met. The first one the jumps to my mind is 508(c)(3) accessibility requirements from the United States Government. How real is this impact? Consider that I have had potential customers say no to Lotus Notes/Domino because web sites generated would not be 508(c)(3) compliant with extra customization.

In the end it goes beyond Scott's concern that selling or developing poor application interfaces makes us all look bad, it is just bad practice in general and can be addressed through the implementation of control frameworks such as COBIT.

Related Links