UX study on developer sandbox tool

Project Overview:

I worked for a company that had a testing environment that simulated the login process and new feature development for the parent companies various Business Units (BU). I took on the redesign of the product and was invited to present the final solution as the companies submission to world Usability day.

NOTES TO CONSUMER:

Certain details within this report have been omitted or changed for the purpose of security. The process displays the co-branding of a company product with a similar division belonging to the same parent company.  Due to proprietary restrictions - Not all of this document can be shared in detail. 

Project included:

  • An accessibility audit

  • Comprehensive UX Study

  • User testing

  • Final prototype.

Role: Lead UX & prototype designer
Primary Agent: David Wall (UA Founder)
Toolkits: Adobe Creative Suite - HTML5, Js, CSS - Just In Mind - Sketch
Project: Exploration of client facing, developer sandbox.

Project Summary:

The Parent company created a developer testing Environment, where new UI features that were set to be rolled out to the child organizations (AKA: business Units (BU)). Here is where new features were vetted and tested against multiple scenarios, prior to being rolled out to the public.

The Issue to solve for:

Although public facing…the product was pieced together by the development engineers over an extended time, and came with no documentation, instruction, or design.

Further complexities:

There were 6 different user types that were required to use the product regularly and for very different reasons

see below

Role

Use Case

Developer (Dev)

File/repo bugs. Verify bug fixes. Verify features and check for regressions

Quality Assurance (QA)

Repo bugs, develop fixes for bugs and verify bug fixes. Develop (and verify) features without causing regression

Business Analyst

Verify current behavior. File bugs & verify fixes. Realize feature solutions

Business Unit

Explore OneID as a product and develop CSS overrides. Verify client config & check for regressions

Project Manager

File/repo bugs. Verify bug fixes. Verify features and check for regressions

Solutions Engineer

Develop CSS overrides, verify client configs & check for regressions, Verify L10n strings & assist BU in client config.

The primary complaint was that the UI was very confusing and frustrating. The product was public facing and a required tool for all BUs, as part of daily development and feature release cycle.

Approach

I interviewed each user role and spent hours shadowing them as they engaged the product environment. I spoke with BU representatives and followed anyone that had experience working within the environment.

Determined Requirements

I decided that the key focus would be for me to simplify the UI without alienating any specific role.  The test site must be quick and easy to use and allow for each role to conduct their specific interaction.

I organized the roles by amount and depth of required engagement, overarching technical knowledge based on user role, and how how frequently they had to engage the system.

I decided that the primary user base would define priorities of the UI and it's placement within the environment.

I focused on cleaning up the existing UI to allow BU’s and less technical users to have a more streamlined experience.

I branded the entire product to align with the parent companies values - while keeping the purpose of the test site as the primary focus.

Look & Feel:

The primary challenge for look & feel was to unify key pieces of the product functionality without causing a "jarring" experience for the end user.

The first part of my approach involved the alignment of existing brand guidelines to the parent company. Our product org was divided into two parts:

  1. Team one was focused on the design and development of the new feature additions

  2. Team two was focused on the integration of said features within the testing environment and ultimately the BUs release.

By aligning to the internal brand values of division one, we were able to contribute to a cleaner, more professional end product. This greatly improved product perception across all roles and helped each user to better understand the relationship between the two products.

Content prioritization process:

The form fields that governed this particular test site were where a lot of the UI changes had to happen.  Because the product had been built by different people and over an extended number of years - It lacked congruity.

The re-design process required that I re-prioritize the form fields, in a way that was more meaningful to the primary user base. These changes also had to be made without alienating any of the other existing user rolls. 

Whenever the opportunity arose to improve a specific piece of UI, I made those changes and documented the process*.

The sample form would be used to set the specific environment conditions required for testing.

*Note: As previously stated - I had to omit certain features due to privacy. My apologies for lack of clarification.

Test Site screen shot

1.) Header, Login, Status, CTA

Product header:

Product testing for desktop - the goal was to create the environment as close to the actual process as we could, thereby creating familiarity with the user. I felt this would cause a more organic interaction between user and system.

The current site lacked identification and branding. This was said to be a key pain point for many of the users. We were told that it made the UI confusing to end users, as they weren’t always sure which environment they were in.

Status Container in original design
Prior to login, status shows in a red warning box. Upon login completion, the status changed to green to indicate success and showed the following user status:

  • current email

  • Clients username

  • Additional Variable (omitted for privacy)

Improvement

By aligning to the BUs existing design pattern, we simulate an organic experience with users testing mirroring the public website. The existing patterns were also common between the two parts of the product divisions within the company. The improvement simulated the real world guest experience down to the eye movement.

(Sample patterns)

The primary “sign-in” CTA was moved from the it’s previous location in the product body to the right side of the header to align with existing BU design pattern.

The Diagram shows an avatar which didn’t previously show in test but did in the real world environment. The added avatar drew the users eyes to login process which quickly identified user status and starting showing user interactions more accurately aligned with what we knew to be the actual experience.

We also moved the “logout” CTA from the product body to where it would normally be found in the actual product and grouped it with the user details. This eliminated accidental log out and because it closely mirrored the production experience - we improved our overall feedback and the logout option was more easily discoverable. 

Clearing the clutter of the login process from the UI into the body allowed us more room to improve the mobile experience.

CTA REVISIONS

Part of the product test environment was designed to demonstrate various levels of trust authentication. This involved a number of CTAs that changed status based on the presumed trust level of the client.

We immediately used the extra space to cluster these various triggers in a more meaningful way.

2.) Configuration form based on user priority

Primary improvement came from a re-prioritization of content based on user role:

NOTE Actual line-up omitted for security purpose.

Current test site form order

Proposed test site form order.

Label one

Label one - Remains unchanged

Label Two

Label ten

Label Three

label Two

Label Four

label Seven

Label Five

Label Three

Label Six

Level Nine - This is now hidden as part of an advanced setting. This means this particular piece was almost exclusively for site developers

Label Seven

Level Four - This is now hidden as part of an advanced setting. This means this particular piece was almost exclusively for site developers

Label Eight

Level Five - This is now hidden as part of an advanced setting. This means this particular piece was almost exclusively for site developers

Label Nine

Level Six - This is now hidden as part of an advanced setting. This means this particular piece was almost exclusively for site developers

Label Ten

Level Eight - This is now hidden as part of an advanced setting. This means this particular piece was almost exclusively for site developers

Added/removed/changed:

Studies suggest labels should read top to bottom instead of left to right.

Studies suggest labels should read top to bottom instead of left to right.

Features that were changed to align to best practice.

  • The new Label alignment was now in a top-to-bottom reading format.

  • Prioritization of form fields; We re-organized the form fields based on input from the various user roles. As a user, the environments you chose could now accurately dictate your working environment so you didn’t see UI that you didn’t need to interact with.

  • Reset config: We moved the configuration reset CTA to the proximity of the actual “Configuration” mechanism, This meant that the reset button no longer competed with the Primary CTA’s on the site for priority and was visually associated to the item it affected.

    Set-Config: The form configuration would show design cues when the form became “dirty”(changed from a default setting through user interaction). This UI change dramatically helped users identify whether changes had been saved or not. The improvement nearly eradicated false ticket creation.

(Further elaboration on dirty forms: If a user attempts to engage a “dirtied” form without saving the configuration through the Set-Config call to action, the form fires off a modal alert to inform the user that the current configuration has been changed but not saved... This would cause “unexpected behavior” within the login experience. The alert enabled the user to disable the warning for future scenarios. The feature was for the case of power users alone.

Client INPUT field: 
One form feature we got a lot of good feedback on, was the predictive text field with “saved” quick search. The input field would pull up potential working environments as you typed. Each keystroke further limited what was available and allowed the user to rapidly search from a database of hundreds of possible environments. As an added feature - the input field showed the most common 3 ID’s you used. These ID's were immediately available through form focus and remain above the quick the rest of the quick search list. It allowed users to quickly toggle between various environments they frequently worked in without having to search for them each time.

Added Features

Advance settings Section: Non essential UI was grouped into a collapsible container and hidden from the primary users who did not need to interact with said UI. This also provided more visual space to work with on desktop and made interactions easier on mobile.

Changing configuration and Validation: Confirmation message appears when the configuration is set. The CTA indicated a visual change if the configuration is modified but not saved by user. Once the new configuration is accepted, the form is cleared and the confirmation message reappears to notify the user of the accepted change.

Tooltips  When we could not modify the existing UI without upsetting the user flow, we offered tool tips and expanded explanations to help the user understand what might be an unavoidable rough experience.

Removed Features: Some of our improved UI involved getting rid of controls that hid information from the user.

A pain point we found repeatedly across all roles was UI that lived on the site, but that no role could accurately identify. There were several UI elements found to be depreciated but still lived in the UI.

Sample Client selector ID

Diagram :   Modified input form W/ autocomplete & predictive typing –Current state is not selected)

Diagram: Modified input form W/ autocomplete & predictive typing –Current state is not selected)

Diagram:  Modified input form W/ autocomplete & predictive typing – PREDICTIVE TEXT on focus

Diagram: Modified input form W/ autocomplete & predictive typing – PREDICTIVE TEXT on focus

Diagram:  Modified input form W/ autocomplete & predictive typing – PREDICTIVE TEXT displayed as user types.

Diagram: Modified input form W/ autocomplete & predictive typing – PREDICTIVE TEXT displayed as user types.

Config Reset and dirty form triggers:

(Reset as link – Default Set Config with no changes to form)

(Reset as link – Default Set Config with no changes to form)

Set Config has changed color to indicate changes have been made to the form that need to be saved

Set Config has changed color to indicate changes have been made to the form that need to be saved

Default CTA color returned once changes have been saved. Save message fades in and out w/out required user interaction)

Default CTA color returned once changes have been saved. Save message fades in and out w/out required user interaction)

Return link to Default State.

Return link to Default State.

4.) Sample code display box w/ actual configuration code

The Sample code box at the base of the UI is essentially the output of the current configuration. I moved the UI into the right hand column of a 50/50 page split so to elevate and minimize scrolling requirements. This seemed to increase the perceived emphasis of the control, as it was now inline with the rest of the form. Since the code was not important to most roles, I set the into an accordion that could be minimized by default and only used when needed. This should hopefully eliminate the confusion by any non power user.  In addition, I added a CTA that allowed users to quickly and easily copy the code without accidentally missing something that could cause the code to fail.

Sample Code container