This has been a theme of late.? And it is worth talking about.
In a recent post, Andrew Paier discussed when to use custom UIs versus Coach View UIs in IBM BPM.? The same talking points would apply to any product that also includes a UI-building capability.? IBM BPM is just one concrete example of such a product suite, and just one concrete example of a BPM suite that provides such functionality (almost all BPM suites do).
Serendipitously, BPM.com is having the same discussion in a different framing - what does it take to have an effective BPM UI.
There are some great suggestions, but each one comes with traps that aren't immediately apparent (the first batch are from Antoine Thomas):
1/ Think end user first from the design to the production, and make regular usability tests with different users, from the digital native to your grand mother ;-)
Well, some of us are too old to have living grandmothers... Setting that aside, thinking end user first is a great philosophy, but we have to be careful.? The trap is when the user is a fictional user or user community out there. Users (people!) need to be real people who can interact with you and share their experiences.? Otherwise, when the UI designer says "you have to design it this way because we're designing for the user first, and the user is always right! And, we are the experts on designing for the user!"? You have no way to check their design opinions with data.? As Eric Ries once said (paraphrased), the difference between vision and hallucination is real-world-testing. The difference between great design vision and hallucination is testing with real users.
2/ At the design level, think about the continuous improvements: how will you improve your UI after it goes to production? How will you collect feedback, and will you manage it to make more and more adoption of your UI to your end users ?
This is so important that most people miss it. How will you change your UI when your process changes - AFTER you go to production?? How will you change your process when you're UI changes after you go to production.
One of the bits of magic with BPM suites is that the battle to keep UI and back-end logic in sync is made much easier via built-in UI layers in these products.? When you step away from that, you are losing a core benefit of the platform, and you won't realize it.? Everything will look fine in version 1, and you won't know why it is so expensive to update versions later.? And you won't even notice the extra cost in version 1, but it is there.? That technical and process debt will grow over time as the friction slows you down from updating your UIs and your processes.
4/ Too much information displayed killed the information. Maybe you should think mobile first, focus on what is most important. And not display, at all, information you would have add for a desktop version.
Yes. Too much information is the mind-killer.? The Dune series got this one slightly wrong.? It isn't just fear (of change), it is also information that is the mind-killer because it causes information paralysis.? Focus on relevant information. Think about the mobile app for checking in to your flight - the focus is on the relevant information and it is much less complicated than the keyboard-driven system the ticket agents use.? No training on using these mobile apps is required.? I don't have to be an expert on the process, the app is.
In the next post, we'll return to the idea of over-optimizing your User Interface, and the reason that BPM projects are run using agile/iterative methods, rather than waterfall methods.