by: Adrian Tonkin - November 2007
There is a lot of talk in IT about building simpler solutions that are easier to use and maintain. We have a few great examples from the masters who seem to get it right all the time - Apple being a personal favourite of mine, with their clean industrial design, high quality products and intuitive software. Much has been written about Steve Job’s obsession with usability and how users of iPods must be able to find their music with no more than three clicks. This design philosophy has found overwhelming support from consumers who continue to support the iPod, despite there being many other competitors in the market. iPods are intuitive and obvious, a great characteristic that leads to consumers embracing them.
Simplicity, however, does come at a cost and that cost is the sacrifice of features. Keeping your solutions simple can be a complex business. Every feature that makes it into the finished product must be justified and have a compelling reason for being there. It was Einstein that said, “make everything as simple as possible, but not simpler”. For your solution to be truly useful it must satisfy a need. Understanding this need thoroughly is the key to developing an elegant and useful end product. 'Elegance' implies a solution that presents the complexity of the problem in a smart and efficient way. Invest time wisely at the start of any project to delve into the intricacies of the need and you will be rewarded later on with clear objectives and a deeper understanding of what the primary function of your solution must be.
Business processes are usually complex in nature and understanding them for automation in a BPM solution can be a daunting challenge. By distilling your processes into a graphical format, you have already transformed them from an abstract set of policies and rules into something that is more readily understood. Any BPM solution worth it’s salt can take these updated process diagrams and implement them with little administrative overhead.
There are a few principles to follow when defining your process diagrams that simplify the understanding thereof, without sacrificing necessary detail. These principles are:
At the outset of any new process intended for BPM automation, you are faced with the decision of appropriate detail. It is tempting to build an all encompassing process that captures every intricacy of the process at hand. This is generally a bad idea. “Big Bang” style projects often fail due to overly complex requirements and high risk which result in solutions that users hate. It is much better to focus on a simple set of requirements that are easily understood by all involved and can be accurately translated into a workable solution. The beauty of BPM is that you can get it wrong quickly, and start improving it by fixing your mistakes. Make use of the continuous improvement approach to BPM that uses performance data gathered in the past to identify areas that can be improved in the future. Once users have accepted your solution, building upon your successes is easy.
In order to quickly build on your successes, you need the flexibility that a BPM tool brings to your organisation. You can quickly respond to incremental changes requested by users and roll them out, fully tested, in a matter of days. For this to work, it is important that you have the building blocks in place to support it. A generic user interface that supports the rich functionality of the product is essential, as your development team cannot keep up with the speed at which processes may evolve and will rapidly become a bottle neck. Generic, reusable integration components are the other building block, without which you sacrifice flexibility. Service oriented architectures (SOA) are the most appropriate use of technology to provide just this type of re-usable integration. Several vendors provide integrated product suites that combine BPM and SOA; TIBCO and IBM are two that spring to mind.
It is important that your user interface conforms to the norms of the medium - users have already learned how to use popular design paradigms, so they’re immediately comfortable with the presentation and expected operation of your solution. To illustrate, take the traditional layout of a web site in which navigation takes place in the top and left frames, with the payload appearing in the body window in the centre of the screen; users are comfortable with this layout and intuitively know how to operate it without explanation.
Always remember what the primary purpose of your user interface is and do that one thing well. In BPM, you are allowing users to participate in processes. There are several features required to support this, namely the presentation of a work queue from which they receive tasks, the actual forms on which tasks are completed and the ability to query the status of work in progress. Secondary to this is the ability to initiate new work and manage their work queues. Make it easy for users to find their work and complete it and your user interface has succeeded in it’s primary objective.
When it comes to activities and forms, there are times when users do require the more complex detail behind a task to support extraordinary cases. Forms must be able to provide detail on demand; detail when detail is needed. Tabs are a good way to lessen the intimidation factor of a large form. Rather impress your user with an intuitive form, displaying stuff that the user was supposed to calculate or capture up front; keep it short, keep it simple. Have lots of simpler tasks that are easy to complete. Hide complexity from the basic purpose of the form. To gauge how much detail to present and in what format, I recommend that you test your proposed solution with a representative target audience from your intended user base. They will be quick to tell you what’s missing to accomplish the job and what they don’t really need.
After spending time with end-users, looking at how they use their front ends all day, I’ve come to realize that in general, they only use 40% of the available menu options. The message is simple; don’t clutter your user interface with menu options that are only used occasionally. Group these together in ways that hide them from every day use, but still ensures that they are available when required.
Users love things that are intuitive and easy to understand. The iPod is only as popular as it is because people get it. Take a leaf from the design guru’s who consistently get it right and bring simplicity to your BPM solutions.