Bazaarvoice Portal Single Sign-On

Bazaarvoice had a problem that few within the organization realized. With the engineering teams humming along, product leaders were cranking out new products left and right. Bazaarvoice had several UX designers handling the diverse products, but every new project seemed to result in an entirely separate solution. There were 6 entirely separate platforms, all with different design language and style, and worse, 6 separate places to sign in, all with different credentials. The core client tool, Workbench, had not seen updates to its experience in over 10 years, and hobbled along with its own mess of UI and IA inconsistencies.

With the help of a product manager deeply familiar with the system’s flaws, we began the Portal project. With a small but dedicated team of engineers, we set out to create a core framework for all Bazaarvoice products, unified by a consistent design system (see Aperture).

I worked with our lead researcher on calls and surveys to discover the needs of our clients, brands and retailers ranging in size from SMB to enterprise. Many issues arose, but the startling pattern was around simply signing-in to use the tools. Poor accounting of active and inactive users, and a common practice of users sharing accounts credentials, account administrators had no idea who had access to what. Many users needed access to varying credentials for different brand and locale-based accounts, the results of these user surveys showed our clients were enduring a nightmare. Even our support site required different sign-in credentials! Here we discovered the main problem: organizations, regardless of size, could not keep track of their sign-in credentials, let alone the disparate web addresses and authentication methods.

We needed a consistent place to sign in, and to manage users

This meant we would need a migration path for an unknown number of users from over 10,000 clients, many of whom might need to associate many people to one previous account, and others who would need to combine several (in one case, 108) accounts into a single sign-in. Unifying the products would come later—we needed to figure out a process to clean-up this mess while setting up a new technical platform.

After creating a series of user scenarios to handle the identified migration paths, our engineers discovered a series of additional scenarios, caused by technical limitations and concepts many might call edge-cases. However, with the potential of 10s to 100s of thousands of individual accounts, even a small percentage could lead to excluding a large number of users, resulting in support nightmares. We folded in each scenario as they were uncovered and analyzed, and worked in tandem to create a flexible migration workflow triggered when a user signed in to one of the various products.

We piloted the migration process with two companies who decided to give us no direct access to their employees for feedback on the process. I suggested we use the tool SessionStack (and a lot of diligent watching of sample sessions) to monitor the migrating users’ experiences, while the engineers kept an eye on performance and system errors.

Through tracking usage and other analytics, we found a segment of users that would completely ignore all guidance and sign in with their old credentials, thus kicking off a migration process again. We’d thought of that case, but had allowed the misuse of the migration workflow to sign in. I redesigned the flow to stop the user on the first duplicate migration and take them to the sign-in page, with updated credentials pre-filled—obliterating any saved password cookies (and causing password managers to prompt to save/update credentials).

This change dropped the number of these attempts from thousands to tens within days, and virtually eliminated the problem before we went to General Availability with the migration.

In preparation of the migration, we added a user management section that would evolve to encompass all settings for user administration, removing the nightmare of jumping between tools. We also added self-serve password and locked-account workflows, cutting out existing hassles for admins.

As our migration expanded from our North American clients to EMEA and APAC, we needed to add localization options. I wrote localization guidelines to enable all our clients to migrate in their language and localized settings. The migration finished without an increase in support calls or reports of missing accounts or settings.