1. Peter Schooff
  2. Sherlock Holmes
  3. BPM Discussions
  4. Tuesday, 14 June 2016
  5.  Subscribe via email

In this discussion there was universal agreement on the importance of the user interface in a BPMS. So what would you say are the keys to getting a BPMS user interface right?

Accepted Answer Pending Moderation

The user interface must make it easy for the user to do their job. They should only see information/entries that pertain to their job. I usually dummy up the user interface and get their input, buy-in, approval and go from there.
  1. more than a month ago
  2. BPM Discussions
  3. # 1
Accepted Answer Pending Moderation

There are a few viewpoints:

dev: easy things are easy, complex things are feasible
arch: working in the same way from any where, at any time and on any device; maintainable by any developer
user: simple, consistent and role-based


  1. more than a month ago
  2. BPM Discussions
  3. # 2
Accepted Answer Pending Moderation

The key is simplicity, otherwise users will not use the system.

Highliy desirable to have a UI with as little need as possible for navigation via menus, icons.

At the top level, we found that the UI requirements for a BPMs (any industry area) are surprisingly simple.

One split screen, with a calendar on one side for fixed-time tasks,and a to-do list on the other side for floating-time tasks.

From my archives - 4 years ago



The Last UI You’ll Ever Need for BPM


The right functionality has to, of course, be present, with basics as follows:


a) auto-posting for structured sequences as tasks become current with user ability to insert ad hoc tasks

b) ability at the user level to micro-schedule tasks

c) ability for supervisors/managers to level and balance work across users

d) easily accessible instructions at tasks plus easily accessible data-collection forms at tasks.

e) to do list refreshes as tasks are committed
  1. more than a month ago
  2. BPM Discussions
  3. # 3
Accepted Answer Pending Moderation

Highly contextual:

: adapts to content, even for same user, same process, same type of task

: adapts to organizational roles and shifts process view accordingly

: follows user through to end-process goal

: clear call-to-actions emerge from any user interaction.
CEO, Co-founder, Profluo
  1. more than a month ago
  2. BPM Discussions
  3. # 4
Accepted Answer Pending Moderation

Automated processes don't have a user interface.

Oh wait, BPM has something to do with people?
Sharing my adventures in Process World via Procesje.nl
RE “Automated processes don't have a user interface.” Not exactly. Any automated thing must be ready to repaired and maintained by a human being (so far). Thus a user interface is a must.
  1. Emiel Kelly
  2. 4 years ago
  3. #1855
You're right of course/ It was focused on execution. And a little sarcastic of course ;-)
  1. more than a month ago
  2. BPM Discussions
  3. # 5
Accepted Answer Pending Moderation

The UI needs to be what is called Adaptive i.e. it adapts to the user requirements. So as you log on it recognises who you are your role and authorised activity. You should be able to select from a list of tasks your proposed activity which might have a priority tag or maybe just too long outstanding...before it gets escalated to the manager? Moving to the UI for the selected task all necessary data should be presented to enable that task to be undertaken.

As the user gathers / creates new information it is entered ideally in logical manner in the form designed for that task. Data should only need to be entered once so intelligent grids automatically filled as required. This ensures one version of the truth...and of course an audit trail of who did what when which will keep compliance happy and support activity based costing if appropriate. For internal users the logical easy use that closely mirrors how they work is more important that any fancy design whereas such design for external users does need to be recognised for marketing image?

The UI is the most important element to the delivery of an application supporting the BPM custom build. As such can be the benchmark in estimating how long to build the end to end process once you have established with users what is required. We reckon one man day per UI (which includes reports) equals the number of man days to build the whole process. Might be longer if involves complex manipulation of data or incorporating intelligent capability but is a good guide.
It would be helpful in all of the comments at this discussion about UXs to distinguish between the "shell" that is presented to users versus the process steps/forms that post. e.g. when we talk about software such as MS Word or Excel there is little confusion re the environment that is being used versus the content.

Not sure I understand what is meant by "the BPM custom build" Is it a particular process or perhaps a different UI, one for, perhaps, casual users at a portal.?
The outside in operational needs in any business will ways be best served with custom applications which must support inevitable change. No doubt the BPM discipline helps establish exactly what is required. Does not matter where in business the logic to achieve the desired outcome is the same. As such yes this is a "new" environment filling the gap between people and the old hard coded inflexible systems (and replace spreadsheets).
The UI is the physical link for users but totally integrated into all supporting needs such as workflow state rules orchestration of content including legacy creation of documents etc. This environment is totally transparent readily understood by users and puts their processes under their control not "IT"
  1. more than a month ago
  2. BPM Discussions
  3. # 6
Accepted Answer Pending Moderation

Considering the question of BPM and UX, what are the characteristics of the work to be automated with BPM?
[b]High-volume commodity task[/b]
s for which low latency is important? Or
[b]complex lots-of-exceptions value-added processes[/b]

Many BPM UX suggestions ("simplicity", "tabs" etc.) are recipes for "
", forcing the human to "remember" context between screens and tabs. Better an industrial engineer to design UX than an programmer or analyst or UX specialist.
[u]A richer environment takes a little longer to learn[/u]
-- but the NPV of longer term productivity and reduced staff turnover will be positive.

And then give everyone four regular size monitors, or two monster monitors, and provide lots of synchronized information in multiple windows. It's all about the work. And how fast it can be done.
[b]Don't make the human into a memory buffer.[/b]
It's tiring.
  1. more than a month ago
  2. BPM Discussions
  3. # 7
Accepted Answer Pending Moderation

Agree with those above who point out that context is the key issue.

If I, as a customer, am interacting with a company via a web form or other online mechanism, I don't expect to have to give them information about myself that (a) they already have or (b) is irrelevant to my specific goals at this moment. Show me that you know me and understand what it is I'm trying to do, because if you don't, *poof* I'm outta there and off to your smarter, most customer-focused competitors.

Scott's opinions only. Logo provided for identification purposes only.
  1. more than a month ago
  2. BPM Discussions
  3. # 8
Accepted Answer Pending Moderation

There are 2 UX's - those that end users touch every day, and the UX for the designers/builders.

Everyone focused on the end user UX and they have got pretty good. The UX for designers/builders
be pretty awful because it was a few techy, trained, committed users. IT bought the tool and told them to use it.

But now the sales model is to woo citizen developers who adopt a tool and that groundswell forces it to end up as a "corporate standard'. So now the battleground for adoption is with the designers/builders. If they don't like it, they won't use it.

Great point. And what makes it more interesting is that, while we've collectively spent a near infinite amount of time studying UIs in the context of customer experience, there's a much shorter record when it comes to understanding what makes good UX for builders. That's especially true because "builders" come from an enormous variety of backgrounds, including programmers, business analysts, and just technically savvy business users. Each of their expectations are going to be quite different from one another's.
Interesting comment 're builders. The UI forms should be incorporated into the build platform as templates ready to configure linked to data sources. This makes functional build very quick and in hands of business. Where design for external is required for image and information about form this can be handed on to specialist with required skill set. Internal users know what to do and want as simple and uncluttered as possible?
For sure, one UX for plan side and then another very different UX for run-time for the obvious reason that plan side the focus is on mapping whereas it is on managing Cases at run time.

At run time, w have multiple users working on multiple instances of multiple templates, supervisors/managers needing to oversee all Cases.

Since many Cases have a mix of structured interventions and ad hoc interventions (i.e. no end-to-end processes), you don't have a "process" until you close a Case. Each Case can be slightly different.

We seem to be trending to where plan side ordinary users (i.,e, citizen developers) initially map out a process, with no attempt to automate the processing at some branching nodes, then a specialist (BI, BA, IT, external) comes in adds a rule set to automate.

So, we the ideal is to have one plan side UX that has two classes of users with one set of features used by one class and a different set used by the other,

The challenge is not to allow the total set of features to encumber either class of user.

It's highly likely that some specialists will NOT use any groundswell environment if the mapping UX lacks the features they like to use (i.e. BPMN etc notations/languages)

As for the RunTime UX, this is used day in/day out by ordinary users BUT as and when there are problems, support specialists often need to shadow the ordinary users to see why things for a particular template/instance are going one way rather than another.

I agree there should be a UX for builders.

I am unsure whether those builders' market is duly represented by citizen developers.

I know there is a significant fad around citizen development but, without going again through the argumentation, I see low-code much more as an opportunity for faster development by qualified people rather than an universal development tool for business people without proper IT training & interest.
Now mapping is the build and incorporates the quick build of the UI/ form. The data integration all prebuilt just needs customised. Yes the deployed UI may have to be worked on to look good but the data presentation / collection remains the same. Every form is custom for purpose including data presentation recognise who and what is required.
Building a complex Case will involve many different process all seamlessly working as required and some UIs may need multiple users to complete which can be readily handled. Agree managers need to be able to oversee what is happening and have the capability to reallocate tasks as required. Finally does not need BPMN or any other notation language which few users understand!
Great point Ian, and the wooing citizen (or even "real") developers with UI development tools has been our strategy (talking my own book, but hey, we're just putting our money where our mouth is) - it has led to our Brazos platform for UI, which has worked out pretty well.
  1. more than a month ago
  2. BPM Discussions
  3. # 9
Accepted Answer Pending Moderation

The UX issue is sometimes about
[b]overloading [/b]
the UX concept with more than it can or should handle. This happens when a project is not properly funded for deep business analysis.


1. UX IS JUST A SLICE OF LIFE -- Failure to consider the
[b]tacit reality of work[/b]
, for which the BPM-instantiated process exists, cannot be solved by a great UX design. All things being equal, i
[u]n consideration of the tacit, UX design is probably more successful if more relaxed[/u]


BUSINESS SEMANTICS MUST BE A PRIORI -- Failure to have properly modeled
[b]data, process, rules [/b]
[b]or algorithms [/b]
cannot be solved by a great UX design.
[u]Don't stuff rules into forms[/u]
[i](As this discussion is on BPM.com, we don't have to emphasize that BPM technology, where the languages of business and work are first class citizens of the technology, is assumed in this discussion. For a non-BPM audience however, the idea of process technology should be #1 for achieving [/i]
a priori
[i]common business semantics.)[/i]


BUSINESS SEMANTICS MUST BE A PRIORI -- Specific work domains often have unique business semantics, which can be considered higher-order abstractions. For example, "
" for sales processes, or "
[b]escalation patterns[/b]
" for field service processes" are often work patterns which are supersets of process, data and rules primitives.
[u]Either directly or indirectly, provide support for what is often the core of daily work[/u]
. Again, not solvable by UX alone.


Without proper semantics and context,
[u]UX and forms become a kind of performance art[/u]
. And given human cognitive tendencies and that "
[u]seeing is believing[/u]
", it's all too common to under-invest in the fundamentals of any application. With good semantics first and then a good designer, beautiful UX should flow easily -- and adoption will also be successful.

Re" Don't stuff rules into forms"

Say I have a step/form along a pathway that collects start/stop times.

At some point downstream from this I have a 2nd step/form that does "stop time minus start time".

No point in my view of having a pre-condition on entry to the 2nd step that does gatekeeping on the basis of start time being later than the stop time.

The 2nd step may not know at what upstream step the data was collected - the incoming data is just data so far as the 2nd step is concerned and the only responsibility of the 2nd step is to just calculate the time.

If I don't build a rule into the 1st step/form, I can easily end up with bad data at the 1st step as well as, in this example, cause trouble downstream.

Clearly, I could have at the 2nd step a rule that sniffs out negative durations but that would be a form rule at the wrong step/form.

In healthcare, we have many "assessments" where responses to a battery of questions get scored - in our environment we embed calculation rules that can go like this

if a>1 then i=i+1
if b>3 then i=i+1
. . . . .
if f>7 then i=i+1

If i > 6 then display "meets diagnostic threshold"

Where would you put the rules for this type of calculation other than at the form that is the assessment?
  1. John Morris
  2. 4 years ago
  3. #1864

Good points. And certainly in terms of execution, it doesn't make sense to go all the way back to the server for data we already have. However, this is a question of location of execution versus organization of rules. I have seen naive forms developers push logic into the form -- where the logic is now a long way from manageability, transparency etc. All on the alter of performance. So let performance and rules execution be a runtime partitioning issue per the right framework and technology. But keep the rules together.
Difficult to recall what we had in mind at the time we rolled out V1.0 of our workflow/Case Management software years ago..

"Case" did not need to be invented for healthcare or law enforcement.

Interoperability was a no-brainer for healthcare as well because of the need to get outside prescription./ lab test results into patient records.

Today, we say there is "no" difference between a process comprising many steps connected with directional arrows versus any mix of process fragments that users thread together, including processes of one step each.

With this mindset, all steps become "micro" processors that take in data, carry out calculations and output the data.

We have pre-preprocessing rules before steps, rules at steps and rules on exit from steps, consistent with Dr Bertrand Meyer's "design by contract" in Eiffel (we represented ISE in Canada for a number of years).

In theory, with knowledgeworkers who have muscle memory for certain best practices, it should make no difference in terms of outcomes whether we have one process with 50 sequenced steps or 50 processes of one step each.

People do make mistakes/poor choices though so the orchestration provided by BPM needs to be augmented by governance from the environment to "rein-in" extreme, unwanted excursions away from best practices.

I like the notion of pre-processing - it's like knocking on a door and being told to go away or being admitted. Post-processing, on the other hand mostly gives you a 2nd opinion.

I suppose what my group is doing is black box processing.

Each step has an outer ring (pre-post) - you don't get to a step or get out of a step if things are not right.

At any step we find it very convenient to be able to load into memory, the form build parameters, plus the data, plus the rules that are attached to the step to do such things as range checks on data, or score a form).

I agree that trying to build steps that include flowgraph logic is a bad idea.

We do however often find forms that have "zones" (i.e. fill in the top part, don't input anything in the "for internal use" zone). The protocol here is post a version of the form with read-only under "for internal use" at one step, then post the "same" form again at a downstream step where others now get to record data in the "for internal use" zone.
  1. more than a month ago
  2. BPM Discussions
  3. # 10
Accepted Answer Pending Moderation

The UI should be loved, and fit for purpose: Creating, updating and showing process models/designs. "The UI is just like a Joke. If you have to explain it, it's not that good"
  1. more than a month ago
  2. BPM Discussions
  3. # 11
  • Page :
  • 1

There are no replies made for this post yet.
However, you are not allowed to reply to this post.