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.
- content-driven: adapts to content, even for same user, same process, same type of task
- role-based: adapts to organizational roles and shifts process view accordingly
- goal-centric: follows user through to end-process goal
- action-oriented: clear call-to-actions emerge from any user interaction.
Automated processes don't have a user interface.
Oh wait, BPM has something to do with people?
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.
Considering the question of BPM and UX, what are the characteristics of the work to be automated with BPM? High-volume commodity tasks for which low latency is important? Or complex lots-of-exceptions value-added processes?
Many BPM UX suggestions ("simplicity", "tabs" etc.) are recipes for "decontextualization", 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. A richer environment takes a little longer to learn -- 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. Don't make the human into a memory buffer. It's tiring.
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.
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 could 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.