Contents
  • Overview
  • Understand
  • Define
  • Ideate
  • Test
  • Iterate
  • Reflect

    • Widget Display Tool

    I worked with with an internal engineering team on the QS Widget Display Tool with the goal of improving the workflow of many on our dev, merch, and sales teams.

    View Prototype →
    .01 Overview

    Duration

    February 2022 – April 2022

    Role

    UX Researcher, UI/IX Design

    Tools

    Adobe XD, Adobe Illustrator

    Platform

    Desktop

    Problem

    Prior to the creation of WDT, simple widget management requests were sent directly from Merchandising teams to the Development team to execute, reducing dev resources and adding time/communication obstacles through ticket requests.

    Solution

    An internal tool that provides an SRC directory, and managing and concluding existing A/B tests on Widgets with a few simple clicks will provide self-sufficiency for Business teams and help Development regain resources for high-bandwidth projects.

    .02 Understand

    The primary user for this internal tool includes members of the Merchandising team that are in charge of managing A/B tests. Other team use cases would be tracking performance data by business teams and providing developers with a reference ID for current tests.

    Merchandising iconMerchandising Team

    Development iconDevelopment Team

    Client iconClient Team

    Paint Point 1: Organization

    Thousands of A/B tests could be running at one time. The lack of information architecture, organization, and ease of navigation makes it difficult to manage A/B tests.

    Paint Point 2: Dev Communication

    All management and development requests would need to be forwarded as tickets to development, resulting in obstacles with miscommunication and project management towards development teams

    .03 Define

    The development team was able to help come up with general features for the WDT by indentifying use-cases based on the prior workflows in which the 3 respective teams would work collectively within the Widget Lifecycle. Each team had their own contributions and responsibilities (Merchandising having the core load), which we would turn into features for the Widget Display Tool.

    Merchandising Team

    • Review Inventory types
    • Keep track of widget pages and current A/B tests
    • Manage A/B Test splits + conclude winning tests

    Development Team

    • Monitoring traffic
    • Auditing existing A/B Tests
    • Conclude Tests for variations across multiple SRCs

    Client Team

    • Analyzing performance metrics
    • Identifying client feedback/requests
    .04 Ideate

    Like most realistic internal projects, this tool needed to be implemented in a time crunch with the limited communication relay and resources, then following up with Creative and Merchandising for feedback and proper design implementation later on. Reusing some assets from creative and older internal tools, the Development team quickly put together a usable beta tool in order to gauge which features needed to be prioritized for much-needed improvement for usability and design.

    Site Hierarchy

    Some teams had overlapping functions (such as reviewing widgets or managing A/B tests), so it made more sense to divide the tool's Information Architecture by core functionality instead of teams. After these discussions development helped worked through a basic navigation/journey for the WDT.

    WDT Sitemap
    .05 Test

    Since the alpha version of the WDT was implemented before completion, there was about 2 months of use to figure out what frustrated users and what they needed. Members from Merchandising, Development, and I were able to collect info from the core user teams to gather input based on usability and design to figure out what to improve for the next iteration. While we were still within technical limitations, there were a lot of errors we could iron out through the use of visual and interactive design.

    Early Insights

    WDT Login Screen
    WDT Account Tab

    Account Functions

    Invalid logins will show complex error message. Upon log-in, there is no feature for the user to securely log out.

    Navigation

    Logging in would take users straight to "Account" tab - No dashboard or info section to summarize Widget Tool features for new users without context. Each function has a seperate screen.

    Search Functionality

    Search parameters not detecting keywords - users have to know direct Account/Inventory/Category Type ID # to receive search results.

    A/B Test Management

    Search results would take you to an "edit" screen with a large text box where users would have to manually input commands to split A/B traffic or conclude Widget tests.

    .06 Iterate

    After much preliminary collaboration and discussion with Merchandising and Development to understand each team's respective functions, the main functionalities of the proposed tool, and limitations, I was tasked with redesigning the UI, introducing simple features, and re-mapping out the interactivity of the WDT to fit the new design.

    Account Functions

    After discussing with dev and my PM and learning the login perameters, I designed a basic log-in screen, allowing room for a small summary about the tool, and created a focused login container with an easygoing error state so users would not have to run into the overwhelming error they encountered prior.

    Upon logging in, users would now see which email is logged in and have the option to log out in case they needed to.

    Demo of account functions

    Navigation

    Within tight limitations (we did not have the time or resources to modify the sitemap at this stage, but discussed future ideas for how we could reasses this), I organized the navigation to correlate with common use-cases.

    More often, people would check Accounts and Categories to see the status of tests between our different clients and verticals, and it would be a much longer timeframe to conclude A/B tests, then the directory was placed last because it was more of an informational tab.

    Demo of navigation

    Search Functionality

    Dev was able to change the parameters to partial searches using keywords or the first few digits of each ID. With this in mind, we would be able to improve upon the search bar and add limited filtering options (ie: category dropdowns, etc.) for the pages that apply.

    In addition, we were able have dev combine the search functions and results functions together as they were formerly on separate steps of the process.

    Demo of different search functions

    A/B Test Management

    My solution to issue to memorizing commands, and inputting them into a command box, was to prioritize having a proper summary page where people can compare the performance between 2 tests and have straightforward, usable components instead.

    Because of limitations, dev was not able to combine the management and conclusion functions into one page, though there was the reality that running tests and concluding them could be months to a year apart.

    Demo of both conclusion and management features of active A/B tests
    .07 Reflect

    WDT was my first internal tool project at QS and was well-received by the entire company! I really enjoyed understanding the context; learning how widgets were published, and how A/B tests generate results to make both the company and our clients successful. But within that, I learned the goals and frustrations of the users (teams I work with), what they do beyond the silo, how to empathize and communicate with them, and design the best solution for their setbacks. Even further I got to understand the impact of hundreds of widget designs my team produced under quick turnaround, often not knowing what performed best. It ruled!

    Lessons Learned

    • How to communicate with devs; understand their constraints, ideate constructively, and work together in harmony throughout the process.
    • Efficient tools can be designed efficiently too! Organization and resourcing from previous systems helped me iterate quickly.

    Next Steps

    • We can simplify the architecture and improve search/filtering functions even further to make finding these tests much easier.
    • QS has a lot more products than widgets! I hope to apply my experience building this to new tools.