Portal User Experience Authentication Paradigms
One of the things I’m involved with is a project to build an external facing portal for our customers and partners. Yesterday we had a lively discussion revolving around the different models for portal sites and, in particular, when the user should authenticate. Our UX team has been focused on the pre-authentication paradigm; however, some of us are wondering if that’s the best model. From a technical standpoint, it’s certainly the easiest but in terms of actual user experience, it may not be the best. Some of the other paradigms we discussed involved authenticating when you get to your community, authenticating when you get to your task area and authenticating when you actually attempt to do something requiring authentication. We came to the conclusion that each authentication paradigm has its’ own set of considerations from both the user experience and technical perspective.
Pre Authentication
With this paradigm, the user authenticates as soon as they enter the secured area of the portal. This is the kind of thing you see at online banking sites. Sure, you can browse through some of the content anonymously but normally (at least for me), when you go to the site, you login then proceed to do your banking. When you’re finished you explicitly logout (and maybe clear your cookies/cache).
Considerations
- you know who the user is at all times
- easy to personalize the site
- single point for login
- no integration with anonymous content
- suitable for quick transactions
Community Authentication
Here the user can browse to a list of communities and authenticates when they select a particular community. Sites using this method of authentication usually serve a range of discrete communities of users that have disparate task sets. This is something you’d see at the sites of large companies that have a variety of different customers and partners or have a variety of systems that are not technically integrated.
Considerations
- user self selects role
- allows basic information discovery
- personalization occurs after role selection
- enables technical segregation of login points
- allows basic anonymous content
- suitable for short tasks
Task Area and Completion Authentication
Typically the user can browse anonymously until they want to do a specific task or set of tasks, then they must authenticate at some point during task execution. This could be considered two different paradigms but I find it’s easier to consider it as a sliding scale where the user may choose not to authenticate until they absolutely have to or they may choose to authenticate earlier to take advantage of saved profile information. The classic example of this is a shopping site. The user can browse through the merchandise and add items to their cart but may hold off on authenticating until they actually go to pay for their purchases. However, they may choose to login in earlier to determine shipping rates or save items for later.
Considerations
- primary role automatically assumed
- allows full information discovery
- more work to personalize the site
- login may occur from multiple points
- fully integrated with anonymous content
- suitable for long tasks and casual browsing
In the end, I think it’s imperative that all options be considered for potential use and that the infrastructure be capable of handling any of them. Unless you can definitively say that your users will never need a particular authentication paradigm, it would be pure folly to technically “hamstring” yourself by not allowing multiple authentication models.
Are there other paradigms I missed? Did I mix something up? What has worked for you? Leave a comment and let’s discuss!
- Dave