An admin in the clouds
Restoring confidence by organizing chaos
You said ‘simple,’ right?
As one of the leaders in Identity Access Management (IAM) Symplified’s solution has allowed millions of end-users to connect securely to thousands of cloud-based and internal, custom applications using one login. The User Interface though, had some issues.
While Symplified does in-fact “simplify” the Identity Access Management process, there is still a vast amount of complexity that must be exposed to the various users who manage Identity Access and networks for their organization. Legacy systems using outdated protocols would need to play well with custom applications across many devices. Each of these configurations are complicated and highly interdependent. Their current User Interface (UI), while technically capable of handling most of these interactions, was built using now-outdated interface software (Adobe ColdFusion/Flex/Flash). It was the perfect time to re-build the codebase, re-think the experience, and re-align with their new branding.
False summits, lost confidence
In talking with Symplified users (administrators), one thing became very clear: Confidence is key (and it was lacking).
With a lot of moving parts, the risk of “breaking” something was ever-present. Just when users felt like they had a solid configuration ready to publish, we noticed a sense of defeat as non-contextualized errors appeared or form submissions failed for no obvious reason. It’s much like hiking one of Colorado’s many fourteeners; just as you reach what you perceive to be the summit, you realize there is more work to be done and you aren’t. Quite. There.
It’s what’s known as a “False Summit.”
Holes in the Journey
In order to take a sweeping, holistic approach to the design of the admin interface, we had to first understand the journey Symplified users took; from interest in the product, registration and onboarding, to continued maintenance and interactions. We documented this research in what’s called a “Journey Map.” This visualization highlighted gaps in the journey and any discrepancies between the first-generation product and the new version we had been asked to design. For the first time, we could visualize the chasm between tasks customers were expected to do, but were ultimately handled by support staff. The orange items in the customer row indicate items that customers should be able to accomplish on their own; instead, these were handled by Symplified.
The journey map was used to identify where the main pain-points were in the app
With our customer journey map in hand, we started looking at how the content was organized. What may have first appeared as an endless amount of configurations ended up being a little more straightforward. Connection “templates” are meant to connect with known apps (Salesforce, Google Apps, etc.) and are built, tested, verified and supplied by Symplified to their customers to ease setup. The other type are “custom” connections which the customer is required to self-configure.
Each of these connection types (templates and custom) were then organized by their protocol. What we learned is that while these protocols each had distinct configurations, they all shared some basic functionality. To better understand how to make the UI accommodate the similarities and variance between them, we mapped out the connection configuration flows for each in detail.
By grouping application connections in this new structure, subsequent interviews seemed to show an increased confidence in the product. Confidence may be hard to measure, but a willingness to explore and try things without fear of making a mistake was a strong indicator of this.
Using a stepped* approach to these configurations, users could more easily recognize patterns and familiar interface elements that helped to speed up the process. Sections that were identified as being similar in terms of functionality or input requirements were grouped together and detached from other sections and fields.
*Important note: A “Stepped” configuration doesn’t necessarily mean a “wizard.” It’s instead a way to break things up into logical chunks, include error-checking and validation, and allow a consistent flow through the various required fields. Users mentioned not wanting a “wizard” because the additional abstraction would quickly become a burden to those who knew what they were looking for.
Throughout the project, three philosophies that lead the redesign:
Ensure customers feel confident when interacting with the tool.
The lack of customer interaction seemed to come from a lack of confidence in the tool. Once new configurations were published or saved, there was little feedback informing the user of what happened (or didn’t happen). This meant the customers weren’t able to feel completely confident in their actions. Power-users went right to the command-line, and other users called support.
Give clear indication of state-changes, current status and pass/fail conditions.
To ensure confidence in the tool, we knew there needed to be a way to communicate with the user without causing alarm, or leaving questions to be answered. The interface needed to speak in plain terms, with clear messaging and contextual error indicators. All interactions were given some form of visual or textual feedback.
Keep it simple, but allow for complexity.
With power-users and basic users all using the same UI, the challenge was to keep things simple for basic configurations and allow advanced functionality only when needed. This meant taking a stepped approach to configurations where the most essential options are shown first and the more advanced options remain hidden until required.
Originally published at www.sliceoflime.com.