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.
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.
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 way more attention. But also notation... No I'm not going to discuss notation again. :-).
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 :-).
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.
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.
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.
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.
We could discuss if it's about User Interface or User Experience, but it is very important of course.
One thing not to forget I think, when talking about a BPMS, is that there are different type of users:
- Executors who use worklists, forms, fields etc
- Process managers who u use dashboards that show case performance and must be able to adjust execution
- Process owners who u use dashboards that show process performance and must be able to understand the needed changes in process design
- And probably process designers who use all kind of modeling and configuration modules
As always, there’s more than one question here, depending on how you read it…
How Important Is the User Interface?In software-based systems, the user interface is important in that it is one of several critical factors. A bad UI can make the whole system a failure all by itself.
How important is a UI to a BPMS? Well, a BPMS without a UI sounds like a fairly radical idea but we do have those; we just call them integration platforms, whose users are only software developers.
How important is a UI tohelping define your processes? It depends on the situation: sometimes pencil and paper, or marker pen and whiteboard, are enough. In practice, although a good UI can make a difference everywhere, it’s probably more important for process execution than process design.
The BPMS has always been behind the curve when it comes to UI design. As we put more process control and participation in the hands of customers rather than employees this limited user experience becomes more of an issue.
However I think the traditional UI days are numbered anyway as the voice interface replaces the traditional text/keyboard UI.
Agree with consensus v important. Adaptive capability is vital for the next generation BPM supporting software. This involves the UIs adapting to the users and their specific requirements. Thus all data is dynamically presented to the right person at the right time; such capability essential to support delivery of BPM Applications/Solutions......
Of course this puts design of UI and required data etc as an important element in defining the process.
When we talk about user (interface or experience), the first thing to do is identify and know your user.
So I mostly agree with Emiel and Peter, different users may have different UI needs, and maybe the one that designs the process is more tolerant than the end user that uses the process everyday.
Said that, in our experience with thounsands of process designers around the globe, we found that a very cohesive and friendly user interface for the Designer user, is much more important that what you could think. It reduces the learning curve (to use the BPM Suite), so it takes less time to be deploying processes, so he can deliver more processes per week/mont/year, so the organization gains competitive advantage, better customer care or whatever it's looking for.
As "techies" we some times prefer functionality over user interface/experience. Well, in my oppinion this is a changing. In not so long, everyone will know that a good UX (even for the techies) translates in a more competitive business.
UX is now everything.
In the last 5-10 years, the business users’ experience of what a great technology UX feels like, and what applications are capable of doing is shaped by their experiences as consumers. Ten years, the only technology they touched was provided by the company; mainframes, clunky Windows laptops and flip-top phones. Now consumers have access to a dizzying array of devices and apps, that all seem to play together nicely. And that colours the business user’s expectations. At the same time the cost epectations for apps is plummeting.
An stark example in the process mapping/modeling world:
So UX is about making the complex simple, not dumbing down the app. But it is hard. Really hard.
A great UX drives adoption: more rapid onboarding, better user retention, increases user satisfaction and referral.
In summary "the confused mind says 'No'"
Process mappers, day-to-day BPMs users, and guest BPMs users all need different UIs.
Those who see e-Cases as the environment of choice for Case Management may find it interesting to browse a series of blog posts I published toward the end of 2013 - , one of these was "eCases III - the UI makes or breaks it"
I had to look over my shoulder when this question popped up in my inbox, as I was just deep into creating the new layout for our process portal. Hugely painful for a noob like me.
There is no question about the importance of UI/UX. The only question is why so few do it right in the BPMS world.
I mean, look at most BPMS demos on YouTube and you see someone doing a "quick demo" of a form linked to a user task and call it a day, saying: "that's it, zero code, you see?". Typical case of BPMS over-committment.
BPMS app designers stil tend to see the UI as just a necessary evil to handle those pesky human users: have them input the goddamn data so they can finalize that user task and get back to the little automated process thingy.
That is wrong on too many levels, because:
1. UX is crucial to attracting and keeping your customers happy and engaged;
2. in most cases (hopefully), UX design will drive your app design - you really think through the steps that a user has to take in order to do his/her job and try to refactor your process to minimize friction - again, from a UX standpoint, not from a lean process standpoint;
3. in all cases, the UX design drives your front-end content via information design requirements - somewhat counterintuitively, the medium shapes the content.
My favorite topic!
In my opinion and experience good BPM UI/UX is extremely important!
I have seen well modeled processes but poorly designed UIs leading to more frustration and in some cases failure.
It does not have to be flashy but as some other folks mentioned should enhance the user experience.
UI design takes time as most OOTB do not support a whole lot of features, so to reduce development time the argument of a simple interfaca gets used a lot. One of the reasons I am a fan of Brazos toolkit from BP3, it reduces that development time.
Wrote about some ideas that we should consider while designing BPM UIs (see references).
Lots of insight and experience here and good emphasis on the importance of UI for successful BPMS-mounted BPM projects. But why such on-going frustration in the field?
A refocus from UI to UX would be helpful. Because that get's us closer to "deep process" or "deep work". UI is the "paint on the pig" of BPM, and it's nice to have a pretty paint job. And good painters are hard to find. But is this concern about UI only phenomenal or only concerning symptoms?When all you have is a hammer etc., everything looks like a swimlane. Or in the case of UI, a mobile form.
Consider the idea of "deep processes" or "meta processes" which could be virtual processes that span BPMS-deployed process steps and the human and social behaviours and cognition which constitute the human side of a process.
OK, one might say, "John you are stating the obvious, but how is this helpful?"
And I will respond that to achieve the best results from UIs, we should first try to "surface" deep processes, for explicit consideration.
Deep process is an umbrella term for UX or "customer journey" or "customer experience". The idea of "narrative" could be considered another specific example. Many organizations are now beginning to address end-to-end business processes beyond what's in the BPMS. (I recognize that UI can be defined very narrowly in terms of forms design, graphics, perceptual research etc.)
If we start from the big picture, from customer experience, then our UI task is much more determined. UI becomes a "human brain-friendly" window between artefacts of BPMS technology and the fuzzy reality of human behaviour. And the job becomes much easier. And the results are much better. And the deep process supported by a particular UI is now the measure of success. And we are successful because we are building a user experience or a customer journey.
UI probably fails if particular deep processes are not first class citizens of your business case and your use case and your technology tool kit.
But who can afford to maintain the intellectual capital necessary to building and managing customer journeys as first class citizens of your inventory of business tools?
UI is critical, but it is also hard to define what is "great" UI in objective sense of the word. Easier to look at objective measures like adoption by users etc.
If you follow what BP3 is investing in, we have been, since 2012, heavily invested in the user experience and UI for BPM, and have a suite of tools under the Brazos brand for that purpose: Brazos UI, Brazos Charts, Brazos Open, Brazos Portal. It's definitely the best of breed on the IBM BPM platform, and has been pretty much since day 1. And there are thousands of developers using these tools to build great UI for BPM, that's the objective bit that goes with my subjective judgment about the quality of the UIs.
We've invested in it because it is the point where we touch our customer's experience with the concept of BPM. It's the steering wheel and instrument panel when you're driving...
As everybody else has said, it is absolutely critical. That's exactly where we have focused for over 2 years now and I'd like to think that since our roots are in design - our work is being validated by customers who appreciate this.
I would add one thing which could change the face of interaction with processes.
We are working on removing the entire UI with a "process bot". A conversation with a bot needs no UI. Imagine filling a form out through a bot-driven conversation, and simply answering questions from a bot.
In effect, an AI/robot-driven bot would guide multiple people through a business process. This, as you can imagine - is hard to achieve - but we have experts in machine learning, cognitive technologies, etc. If we can make this work with text-driven conversations - it will not be a stretch to make BPM "doable" and processes interactive through voice means i.e. Amazon's Echo for example.
Hence the real future we're working on is not just the UI - it's the absence of the UI itself. Over 2 billion people in the world use chat apps all the time, like Whatsapp, SMS, Slack, etc. Hence, it's by the far the most natural way to interact.
Happy to share more if anyone is interested (not a plug!) - we are exploring and learning just as much as anyone else. It's a really cutting edge area that's very exciting. There's things under wraps I can't say, of course.
I also think that a very beautiful (or potentially non-existent) UI would open up use cases where BPM has traditionally never been applied before.
If anyone reading this happens to be in Silicon Valley, we have a deep interest in this subject - and I'd be happy to meet for a coffee.