So I’ve worked on a large number of portal and collaboration projects. Some of the biggest usability pain points I’ve seen had less to do with the UI and more to do with the process of setting the users up correctly so they can see all the content to which they are entitled. Let me give you three examples:
Portal client with a large and well used portal application
This client used the portal to build an application that brought together multiple systems to allow for better sharing over a wide range of offices across the US. More than 500 users spent large amounts of time in it each day. We released the portal application over multiple phases. Just after the second release, our biggest complaint was around administering users. The security guys, in their infinite wisdom, had decided that we couldn’t instantiate and authorize our own users. We had to make a request to them.
Here’s the problem: since the portal was just the front end to a number of different systems, authorization involved taking existing users in multiple ldaps and putting them in the correct groups. Even though we had a defined process and instructions, the security guys got it wrong four times out of five. As the app ramped up the number of users, this became a daily challenge. It was only after we had so many problems that we convinced them to let us do it programmatically. We defined the rules, integrated to the three repositories, and created an easy to use interface that managers could use to add, modify rights, and delete users from the app. (not the ldap of course). When we launched it, our lives became much easier.
Collaborative Site
Another example comes from a client who used a well known collaboration tool to share documents, wikis, etc. We only had to worry about one user repository. However, the user base was spread across employees and external users. Our initial request to get access to the site took three weeks. After three weeks, we had one username for the entire project team. We didn’t dare request more because it had been such a pain so we made do.
Customer Portal
One client has a model where customers might be a company with authorized users and a customer could also an individual user buying one product. The company offered multiple sites for customer, retail customers, and partners. The number of duplicate users was large and customers were complaining about having to use multiple logins. As part of a new customer portal project, we worked with the security team to create one login and user management module. I won’t say that it was easy. We were worried about the user experience. They were worried about making it secure and re-usable from their viewpoint. However we did eventually settle upon a set of portlets that seemed to fit the bill. It made the creation of users easier. It allowed customers to add new user themselves. It made it easy to take care of things like forgotten password. In other words, we solved a problem while averting a lot of future phone calls as we rolled out enhanced functionality with a more complex security model.
My Lesson Learned
Identity Management can be hard. Many times, the security folks want to manage it themselves and are afraid to hand over the reigns to “end users”. That approach causes major pain for the end user and add time and $$ on the administrator’s head. We have succeeded in solving this only when we were able to cooperate with security and setup a self-service model. In my mind, it’s well worth the heated discussions and the give and take necessary to implement it. Long live self service with Identity Management.
Pingback: Portal Solutions Blog: Why Indentity Management is Important to Portal and Collaboration | Stoeps