Does UI really matter in a BPM Product Suite?

the user interface forms  a very crucial feature of any bpm (business process mangement) product stack. whatever be the underlying process, rules, connectors and other selling components, if the end-user is not happy with the look and feel, screen navigation, custom change flexibility, responsiveness and response time for screen navigation with the out of the box user interface. in most cases it will be a no-no.

no,  doubt process orchestration is important and is addressed flawlessley by the bpm product suite along with making life easy from the data modelling, designing and integrating with n-number of systems at ease leveraging the ootb connectors. but, as, an end-user we believe in the look and feel and the impression it creates in the 1st instance. same applies for the projects we implement using the bpm stack.

lets, considers an example :

• a person opens a website of the banking customer and it looks awesome –> it is the bank’s enterprise portal.
• at the stage-1 the customer/end user has made his expectations right
• next he clicks a few links here and there –> this should make the customer feel as if he has still opened the same site of the customer
• next he clicks on the core banking/personal banking features which is developed using a bpm product stack.
• cautions, this should not surprise the customer
• a similar experience should be made available even if the person opens the same site from a ipad or a mobile device (with no horizontal and a never ending vertical scroll bar – distorting the alignment of the sections)

personally, i feel user interface is something that is also very crucial factor from a bpm implementation standpoint providing the cutting edge latest techology and flexibility to adopt and transform. having the best in class user interface transformed in the bpm product itself, will encourage implementors to leverage the ootb than thinking of a separate ui layer and then bridging it with the services and processes in the bpm layer. considering the response time, screen loading and latency it will be perfect if things can be resolved in one layer.

so, in a nut-shell for any bpm product it is very important to convince and create a wow!! factor for all the stakeholders involved not just the business and it from the process and requirement implementation standpoint.

it was really nice to see the transformation in case of pega 7 version with the html5, css 3 based responsive ui. played around and experimented a few things and it was interesting. having seen the product transformation (pega) from 5.x to 6.x to 7.x the ui designing and flexibility provided was interesting.
few criterias which i considered from an ui evaluation standpoint (pardon me if i have missed out anything, i am not a ui/ux veteran) :

• responsiveness (alignment of screen on a dynamic fashion even if you forcibly reduce the size of the window)
• no horizaontal scroll bar even if we keep reducing the size of the window
• similar experience if the same application is launched from a desktop/ipad or mobile
• import external css files and java scripts (to see and judge how the system reacts to it)
• ease of maintainance of skin and portal related changes
  • eg: using mixins and component based color schema definition
  • can define a standard for active and inactive tabs (the background colour, fond colour, size and format)
  • all these changes can be made at one place and it will reflect in all screens and sctions where the specific definitions have been used
  • this also helps in bringing out the creative person in you and start playing with colours
• html 5 and css3 based screens
• cross browser compliant (be it ie, mozilla firefox, chrome or safari)
• the product should also be running absorbing and adopting to all the latest features and advancements happening in the ui/ux fraternity
• drag and drop feature to create ui from a developer standpoint and flexibility to modify
• can a ui created externally using html5 can be imported at ease to the existing ui layer in bpm or it has to be re-created from scratch

here is a snapshot of the latest tends in the ui arena and the bpm product suite.

here is site that showcase some responsive, flashy and jazzy looking uis. if the bpm layer where you create your process also provides there ui  features will it make a difefrence ?

please do share your thoughts and suggestion based on your experience with ui and other bpm product stacks.

and what is your take does ui really matter in a bpm product suite?