TOPIC:

<p>
There was quite a lot of talk about the value of UIs at bpmNEXT. So how important is a UI to both a BPMS and to helping define your processes?</p>


<meta name="twitter:card" content="summary" />
<meta name="twitter:site" content="@BPMdotcom" />
<meta name="twitter:title" content="BPM Forum: How Important Is the User Interface to BPMS and Processes?" />
<meta name="twitter:description" content="There was quite a lot of talk about the value of UIs at bpmNEXT. So how important is a UI to both a BPMS and to helping define your processes?" />
<meta name="twitter:image" content=" bpm.com/images/discuss_avatar/288_10f969...480bc988a12516bb.png " />

<p>
It's vitally important where ever a user has to interact with the system. Without a UI how would the user communicate with the BPMS, trigger processes, sign-off steps and know when attention is needed?</p>
<p>
</p>

The user interfaces for a process constrain or enhance the efficiency of the participants... so they are hugely important.

That's why the UI authoring tools associated with a BPMS are critical for process agility. If you can't quickly adapt the user interfaces to a process change, then you can't quickly implement that process change.

<p>
In my world, it is the biggest factor and a differentiator in the success of process automation solutions. Everyone and their mother can do process flow and role definitions but interfaces - Forms, dashboards, etc. are and continue to be a huge challenge that has long plagued the space with poor data presentation and user experience. The obvious challenge when doing this is the balance between simplicity for business Analysts to be able to potentially build and maintain the UI versus the complexity and sophistication needed for advanced UI experience. Not only are you balancing the power user requirements, but also for the casual user who can't spend a lot of time training on the solution. Historically, we have seen clients go to alternate tech to develop UI capabilities such as 3rd party plugins or asp.NET features but it has not been the easiest to maintain or manage with upgrades to the BPMS. For selection processes, I generally match the UI experience with the prospects expectations to determine if the solution will be a good fit or not. I have seen way too many Firms choosing the wrong solution and struggle to get it working with their requirements due to limitations or expensive work arounds with the UI. I will say that this is getting better but very slowly.</p>
<p>
</p>

<p>
Extremely important. The same however can be said of, say... a vacuum cleaner... As a matter of fact, one could even state that if the UI is not as friendly as that of a vacuumcleaner, you have probably missed the point.</p>
<p>
Now... Why are so many BPMS's still so, well, complicated? Because they have been build by a certain species. And that species is pretty often silicon based. IMO UI(x) needs to get <em>way more</em> attention. But also notation... No I'm not going to discuss notation again. .</p>
<p>
Summarized I think it is very important that a specific audience gets a specific focus / context. Starting with a more general purpose and, when zooming in, becoming more audience targeted. So, a generic high or main level "Powerpoint" representation of your value chain / core processes and a "Click for KPI's here - button" is a great way to communicate with boardmembers, but not for developers. The trick is to have it all in one repository, represented per target audience. Actually, I (almost) started to discuss notation here... But you get my drift .</p>
<p>
 </p>

<p>
I would say the user interface is one of the most critical elements that will determine the success or failure of a BPMS system. There are essentially several distinct types of user interfaces we are discussing here.</p>
<ol>
<li>
Traditional BPM
<ol>
<li>
IT user UI</li>
<li>
Business user UI</li>
</ol>
</li>
<li>
End-user-driven BPM
<ol>
<li>
Business User UI</li>
</ol>
</li>
</ol>
<p>
I would argue that 1.1 needs something closer to a traditional developer "user interface" (i.e. code). Attempts to make this user interface into something visual (BPMN etc.) have met with poor results.</p>
<p>
When comparing 1.2 and 2.1 the user interaces are both exceedingly important but entirely different in nature. In the former, the user interface takes on the trappings of a traditional developer built user interface. This UI needs to have high specificity to the problem domain.</p>
<p>
In the latter, where the business user actually creates, updates and drives the process the user interface will be more generic (analagous to generic project management tools as an example), extremely intuitive and easy for the end-business user and highly flexible at the expense of some specificity that would be found in 1.2.</p>