The One-Page Manifesto – Effective Business Process User Interfaces (Part 3)

Scott Francis
Next Post
Previous Post

Linkedin UIThis is a continuation of the series of posts on effective business process user interfaces.  And this one is informed by recent discussion at IBM Impact.

One of the key battles being fought in the halls of many companies deploying business process technology, is the debate over the one-page manifesto: namely, the idea that a good user interface consists of one page.

There is a school of thought among UI designers that a user-interaction that hinges on data reading and data editing and entry, should have as few pages as possible, and ideally only one (which scrolls in only one direction, up and down).

It isn’t a bad school of thought, but like any good idea it can be taken too far. Fewer screens is better than more, but one complex screen can be worse than several simple ones.  Credit a customer with this analogy: to appreciate how much more complicated such an interface can be, imagine getting an airline ticket.  You can buy a ticket on your laptop, and it walks you through a process to do so. Would it be easier to use if ALL the options and data were on the same screen (including searching for flights)?  Would it be easier to check into a flight if it asked you all the questions at once and then verified?

No it wouldn’t.  Airlines and their technology providers have figured out that a simple process-oriented approach can allow the average traveler to navigate without any training.  You don’t have to be an expert. You just have to move from one screen to the next.

In a session at IBM Impact, John Reynolds made a point that perfectly addresses process thinking and UI while addressing a question from the audience:

“Your ability to change your process to respond to change is limited by your ability to change user interface”

This is an example of process-thinking.  Realizing that your process and the user interface related to that process are likely highly related.  I’ve seen this impact worth both ways:

  • In legacy applications, the systems processing in the background might be adaptable or changeable on a good timeframe, but there’s no way to get the UI updated on the same timeline. So the changes on the back-end may not be made.  Or the UI fields are overloaded from their original meaning to support new back-end functionality.
  • In other applications, the UI needs to change, but the back-end coding doesn’t support it. This often happens when the back-end is an aging ERP or Mainframe system.

One of the differentiators of BPM is that the UI and process can be updated by the same person, at the same time, with the same interpretation of the requirements.  That’s fairly revolutionary, and it is key to why Lombardi was so successful, and that has carried over into IBM BPM via Coach Views.

I’ve often talked to companies that want to separate UI builders from the process people in their firm.  As if you can design a good UI for a process without understanding the process!  You have to understand the process.  And so BP3 focuses on building tools to make it easier for BPM experts to build beautiful UIs for BPM.

If you separate your UI from your process via a REST API – you can do it.  IBM publishes BPM APIs that will make it quite possible.  But you will find it more challenging to keep your process and your UI in synch over time.  Because the process will change.  The UI will change.  And you’ll have them affecting each other over time.  You don’t want your process adaptation to be limited by your speed of UI adaptation.

For more static user interfaces, building custom UI with a REST API makes a lot more sense – the UI doesn’t adapt with each process edit.  For example, our own Brazos Portal uses IBM’s REST APIs to get your work queue and other summary information about your process environment.  Its UI is unlikely to change as your process changes – so the model makes sense.

Building a great user interface for BPM isn’t about following one creed or another, it is about keeping in mind your priorities – adapting to changing business, ease of use, accuracy, and appealing to users.

 

 

  • I should have also mentioned that another issue is the locality of changes. If you put all the fun stuff in a one-pager UI – and you want to change one little part of your process – say, the implication of a value in a field is that some other data isn’t needed, and maybe an approval routing is needed…

    now, when you want to change your one pager, you have a lot of code to QA because the whole page needs QA – not just the snippet you edited. And then how does routing fit into the one pager UI if it wasn’t baked in to begin with? hmmmmm