Other Projects
These projects were of a more focused scope, and became priorities during the course of other projects.
Looping
Run a group of steps multiple times
Current state of the app
QA testers using script-based solutions such as Selenium are able to set test steps to “loop”. This is useful for test steps that need to perform the same action multiple times. Before this project, mabl testers had to use JavaScript to create looped steps. In mabl, the looping feature was not very discoverable and had low utilization.
Looping V.1
For looping, the main use case that was targeted was allowing users to loop flows (reusable groups of steps).
The first iteration of looping was built as a configuration option for flows that a user had already created.
For a user to loop a flow they would have to first create the flow and then apply looping afterward.
While this was functional, it was not discoverable and as a result looping had low utilization.
The screenshot shown is not design work I was apart of — it’s shown as an example of the state of the app before this project.
Looping V.2
More capacity was allocated towards improving looping.
As we started that process, we learned that another feature pertaining to flows would soon follow.
With that in mind, looping V2 was designed to improve the looping utilization numbers while also setting the groundwork for the upcoming parameterized flows feature.
First and second iterations
To improve discoverability, I designed a new create/edit flow page.
The goal with this page was give users basic information about the flow’s configuration, while gently driving them to change that configuration.
This first version was a good base from which to start, but it was too text heavy and not scannable enough.
The text fields, buttons, and branch selector component along the top are existing components that I did not design.
To make the page less text heavy, I tried using graphics and iconography but they felt less glanceable. Reading through the page felt slower than the text-based option. Visual design was not a focus at this point.
Third iteration
The solution was to use simple, descriptive sentences and treat them as visual elements instead of regular text.
Larger text size, heavier weight, and reduced kerning made the description lines feel more like a graphic element than standard text.
Because they’re written as simple sentences, the description lines are intuitive and quickly scannable. Users may not know what looping means, but “runs 1 time” is very clear and actionable.
The text fields, buttons, and branch selector component along the top are existing components that I did not design.
Loops can also be set based on user-created variables. The text field and dropdown are common UI components that I did not design.
Post-launch results
After the looping V2 improvements launched, looping saw a massive increase in utilization, with numbers about 5x higher than V1.
The utilization improvements were due to:
Improved feature visibility — everyone who created a new flow or edited an existing one had to user the new form, which displays the looping configuration option.
Improved create/edit flow page — the new page gave users a quick overview of a flows’ configuration and clearly laid out configuration options. The design is glanceable and actionable, driving users forward in the process.
Parameterized Flows
Scoping variables to a specific flow
Current state of mabl variables
mabl allows users to create variables, which are dynamic pieces of information that mabl uses to run a test. Some examples of variables include first names, addresses, and phone numbers.
If a user wanted to use a set of variables and have their values scoped to that particular flow, they had to use JavaScript.
Parameterized flows
We knew that flow parameterization would be coming shortly after looping V2. I designed looping with flow parametrization in mind, designing the create/edit flow form to be expandable. We didn’t want users to have to learn a new UI so shortly after learning the new looping UI.
A new item was added to the create/edit flow form’s view controller, and a new line was added to the description section.
Users did not have to re-learn anything — this was a natural expansion of the create/edit flow form they already knew how to use.
The text fields, buttons, and branch selector component along the top are existing components that I did not design.
Flow parameters are given default values when they’re created. With parameterized flows, users can apply value overrides to a flows’ parameters.
This is useful if you want to use the same parameterized flow for different scenarios in other parts of your test — think shipping and billing info, or user login credentials.
The text fields, buttons, and branch selector component along the top are existing components that I did not design.
This form uses existing, common UI components.
Import a parameterized flow
Flows are shared across a workspace, which means people may need to use flows that they didn’t create.
When a user imports a parameterized flow, they’re given the option to override any of the flows variable values. They cannot edit the default values when they import — doing so could break other tests, so editing should be kept a layer or two deeper to prevent unintentional edits in other tests.
UI Performance
Improving the perception of UI performance and page load times through more effective UX design
Current state
The mabl web app is complex, and loads huge amounts of information on most pages. As the app matured and features expanded, users began to report noticeable increases in load times as well as poor UI performance.
Our team’s goal was to solve that problem.
The team got together for a UX-led brainstorming exercise where we reviewed research that I had done about best practices and strategies for designing a good “waiting UX”.
After reviewing the research, we established categories to bucket ideas into:
Sleight of hand/distraction
Fun/animation
Operational transparency
Loading indicators
Workflow
Under the hood
We worked through ideas from our own team and solicited ideas from the broader mabl team as well. These ideas were captured and categorized in a Miro board.
From there, the team reviewed all of the ideas and carried the most promising ideas forward to a shortlist.
Out of all these ideas, the team decided to focus on one: allow users to open virtual mabl tabs.
Virtual tabs
For this project with limited time, the team decided to focus on one major UX improvement that would address three primary issues:
Slow loading of the test output page, which is one of the most information-heavy pages in the app
Inefficient navigation throughout the mabl app
Slow debugging (comparing test runs to one another to determine test failure causes)
The solution to these problems was to allow users to open virtual tabs.
Virtual tabs appear at the bottom of the window, and remain open until users close them.
Users can open a handful of test results pages and work through them like a checklist.
The filters and results table were existing designs that I did not do, and are shown here for context.
The tabs preload the desired page as soon as they open — by the time the user hits the page, it’s already loaded.
To the user, the load time feels dramatically slower even though in reality, it’s exactly the same.
After launching virtual tabs, we surveyed users and internal stakeholders to see how the tabs affected the perception of performance.
Users told us that performance and load times felt dramatically improved. By the time users click on the tabs, the results page is already loaded. Users hardly even see a loading indicator.
Virtual tabs have improved users’ workflows, reducing the time required to resolve test failures
Our analytics tools also show consistently high usage numbers for virtual tabs.
Invite User
Inviting users to your workspace
Current state
As the mabl app matured the size of teams using mabl grew, and the workflow for inviting teammates became a bottleneck for expansion.
Users could invite their teammates but they had to do so from a page that was difficult to find. Teammates also had to be invited one at a time.
We knew we had to make it easier for users to invite their teammates to workspaces. To start the redesign efforts, I worked with the team’s PM to map out the user current user flow for inviting teammates.
After mapping out the existing flow, we identified pain points in the workflow and proposed an alternative.
Click to view larger version
Final Designs
Part of the problem with the existing workflow was how mabl handled scenarios where users accepted an invite using an email address that was different from the one that was invited.
Mabl would add a user to a new trial workspace, and companies would end up with trial accounts that they did not want or need.
This was the first part of the problem we tackled.
Now, in that scenario, users would be intercepted and routed to a new page that explained what happened while giving them options for moving forward.
Next, we solved the problem of discoverability.
We made it easier for people to invite teammates by adding a new button to the workspace dropdown, triggering a modal which users can get to from anywhere in the app.
Users start by selecting which role their new users will have. This also helps users learn the differences between the roles.
Users can type or paste multiple emails to invite new users in bulk.
After inviting teammates users see a success graphic that gives them next steps, including a gentle push to invite more users.
This illustration was done by a graphic designer on the team.
Post-launch results
Almost immediately after shipping these improvements, we saw numbers move in the right direction.
In the first three days, we saw more user invites than any week in the history of the product.
Some customers invited triple digit numbers of users to their workspace.
The routing improvements have gotten users to the correct workspaces, preventing the creation of dozens of unnecessary trial accounts.
Months later, we continue to see extremely high engagement with this feature.
This project and all associated designs and process artifacts are owned by mabl. The parts of the project that I can share publicly are limited — shown on this page are select pieces of the overall project.