Best Practice for BPM UI Development: Iterative Deepening.

  • March 23, 2011
  • Scott
  • 1 Comments

John Reynolds (of IBM and Lombardi fame) has posted tips for building a task-focused user-interface.  He does a great job of articulating the “iterative-playback” two-step that defines our approach to building out process UI (and process):

With this in mind, you’ll see the logic of the process that we’ve adopted:

  1. Build “Just Enough” human interface to give you the ability to “step through” this activity and all of the paths of your process
  2. Define “Just Enough” of your interfaces to underlying integrations to give your integration developers the information that they need to start building the “real” integrations
  3. Get a fully functional task UI working as soon as your “real” integrations are ready
  4. After everything is functional, then (and only then) work on making the task UI “pretty”

On that last point (step 4) – remember that “everything functional” goes beyond a specific human task – All the human tasks should be functional before you worry about making any of them pretty.

This is great articulation of the approach we pushed and developed at Lombardi between 2003 and 2007.  It looks like the team has continued to improve on the definition of this approach (including defining Blueworks process maps for it).  But I think the four-step list is easier to “grok“.

Despite the simplicity of the approach, many people fail to adhere to it. The more technically savvy the person is, the more likely they are to deviate from this process.  For some of these folks, I explain it in Computer Science terms – analogous to iterative deepening to find the right solution for each UI, and for the whole application’s UI in general.  It isn’t quite as simple as breadth-first, but it is closer to breadth first than depth first.

There is a reason for taking this approach to building process UI :

Your biggest risk in the project is that you’re requirements are wrong or misunderstood.  Your best expression of requirements is typically the User Interface.

Because of that, you need to iterate on the UI.  And if you go too deep -either by prettying or over-integrating with back-end systems – you create friction on that iterative process that isn’t required.  That adds cost and slows time-to-market.

Related Posts
  • June 27, 2017
  • Scott
  • 0 Comments

[Editor's note: Don't forget to register for Driven 2017!   Our customer conference is August 16th and 17th ...

  • June 15, 2017
  • Krista
  • 0 Comments

We are excited to announce our first customer speaker for Driven 2017. Quang Ton, leader of Schlumberger's pro...

  • June 12, 2017
  • Scott
  • 0 Comments

We had the pleasure of presenting Brazos CX Insights to the bpmNEXT 2017 conference in April.  As we've previ...