Why Is User Experience An Important Element To Successful Identity Management?
In identity management (IDM) implementations where end-users access the system to launch requests or initiate workflows, the user experience is a critical component to keeping your employees and customers happy and productive.
What makes for great user experience?
Intuitive design and minimal interaction are needed to achieve the desired outcome. These include organizing fields in a manner that is both neat and accessible and ensuring that data-form interaction is swift.
Questions To Consider Regarding Your Identity Management Solution’s User Experience
- How often do users complain about interfacing with the current request or data-forms?
- How long does it take the average user to make a specific request?
- What are the minimum and the maximum number of clicks required to submit a request?
- Is the user interface responsive?
- Can your users track their requests after they’ve submitted them?
There is a vast amount of human psychology that can go into creating an enjoyable user-experience for something as mundane as requesting accounts for new hires or extending contractors. There’s also a real need for flexible frameworks that can handle self-service requests, requests for others, and bulk requests. SailPoint’s IdentityIQ does an excellent job in providing such a framework, but it is up to the developer and implementer to ensure that the best practices be followed to avoid the common pitfalls that grief many end-users. Sailpoint IdentityIQ can facilitate these types of requests, but any given workflow must be skillfully crafted to handle each case appropriately.
Do you have any workflows in your environment that act for a single user, such as an extension or a termination? Can that same workflow handle multiple users in a single request? If the answer is no, how often do you hear managers or help-desk requesting an enhancement for that type of functionality? A great user-experience does more than make a routine task easy, it also makes it more efficient.
We recently had a SailPoint IdentityIQ customer that experienced some strange behavior with two individual workflow cases. This particular workflow was responsible for onboarding newly hired contractors. It had been working fine, without error, for over year. However, an issue occurred with two instances of the workflow mentioned above that required my attention. Two iterations had generated duplicated activity at a certain point in the workflow.
Attempts for account creation happened twice, and duplicated emails were sent out. The engineer initially involved with investigating the root-cause analysis was rightfully stumped. Together, we undertook the necessary steps to investigate how and potentially why this had occurred. Having little to go on, we set out to follow the code. We eventually ended up at a proverbial fork in the road: An approval step. Beyond this step began the duplicated functionality.
We began to suspect that unexpected end-user behavior may have profoundly influenced the problem. In previous experiences with other products, you could generate multiple instances of a single workflow by spam-clicking the submission button. However, SailPoint is ahead of the curve when it comes to preventing that type of behavior. With the initial click of the submission button, it ‘grey-out’ into a read-only mode. While this type of behavior wasn’t our culprit, we did make an important discovery during the test. We noticed that upon clicking the Submit button, the workflow seemed to hang for a few seconds before redirecting the user back to the dashboard.
Some essential questions crossed my mind: What if this delay was more severe for the end user? Was it possible that the user believed the workflow was stuck and took it upon themselves to refresh the page? What would happen if such behavior occurred?
We soon found out and successfully replicated the issue. The problem in this situation was that the workflow continued onward to complete its work at the expense of the approver. The delay for the approver in question was probably longer than what we had observed, primarily if there was distance-induced latency involved. After waiting for about 10 seconds or so, they probably felt that the request had failed at the browser level and attempted to refresh the page to retain all of the data they’d entered. When they clicked the submit button a second time, the response was much quicker, which probably made them feel as though they’d made the correct decision.
Unbeknownst to them, the reason the second submission was faster was the result of the system they had, which failed in doing its work due to the fact a duplicated user already existed.
What was the solution in this case? Making sure that the workflow did the heavy-lifting in the background. With a minor configuration change to the workflow, we eliminated the delay and the ability for anyone without Flash-like abilities to refresh the page after submitting the form.