A/B Testing UX for Component-based Frameworks

Becoming familiar with coding can be of great benefit to designers. Consequently, many have taken the dive and learned how to work with code (or at least speak its language to some degree) as a way to be more effective when collaborating with engineers. JavaScript, arguably the web’s favorite scripting language, has a robust community that is shaping the future of the web with the frameworks it is crafting.

As a result of their structure and technical constraints, Frameworks like Vue.js, React.js, and Material UI are important for designers to consider because they act as building blocks for robust design systems. Moreover, knowing how code works also comes in handy when facilitating data-driven design techniques in a development environment such as A/B tests.

On a recent project for a startup creating a patient management platform to connect individuals to mental health professionals, we found that setting up and managing patient accounts with as little friction as possible were key for a number of our clinical advisors. Focusing on creating an intuitive browsing experience for patient profiles was crucial, as was setting up an optimal user flow to create, edit, and assign wellness activities to patients.

Discussing the project with the technical lead, it was determined that fundamentally, the application was quite simple: Clinicians needed the ability to create and edit patient profiles, view a library of wellness activities, and assign lessons to patients.

The team decided to align the project’s design with the Material UI framework, utilizing base elements like popup modals, display cards, active/inactive buttons, accordion lists, and a series of success and warning notifications. Once the components that would make up the base elements were defined, the product team offered varying opinions about the application’s layout.

During discussions about the project’s UI design, the developer explained the difference between functional and display components and how functional components control the flow of an application’s data whereas display components are relevant to UI and layout.

Put simply, display components define an application’s visual language, and functional components help bring them to life.

This structure offers unique possibilities to designers because, typically, code concerned with managing the logic of an application is isolated to a file separate from the one controlling the UI’s layout. Done correctly, this approach to software design ensures a modular and robust codebase that enables a test-driven process.

Could identical features in alternative layouts be tested with minimal engineering effort? The answer is “Yes,” and if done with an A/B method early in the process, it will be baked into a lean product development lifecycle. (Lean product development is a spinoff from the Japanese concept of kaizen, the business philosophy of making incremental improvements to workflows, practices, techniques, and—in this case—products.)

Eric Ries, serial entrepreneur and author, discusses a practical guide to the lean product development lifecycle in his book The Lean Startup. The method follows a workflow of building products with a clear hypothesis, testing what was built, and iterating based on what was learned.

The Lean Startup Method

Defining the A/B Testing Approach

A/B testing is a core component of any seasoned UX professional’s toolkit. Its role in the software development lifecycle is to help improve the usability of applications. Combined with heat mapping data, teams can gain valuable insight into user behavior, especially when it comes to points of friction within an application’s flow.

Before starting A/B testing, here are some questions to focus the process:

• How is A/B testing used in UX?
• What methods of A/B analysis are available?
• Why design A/B tests while wireframing?
• What are we testing for?

The most common method of A/B testing at scale is a split test that serves slightly different versions of an application or website to live users. A split test is often out of scope and/or budget for a startup or a small business. However, there are alternatives to large-scale split testing that are more accessible and include: in-person interviews, focus groups, and online services that connect you to a network of test users.

A/B Test-driven Design

During the wireframing process, it’s important to consider the possibilities of A/B testing from a layout and navigation perspective. Simple variations of display components can easily shift how information is presented. Component-based frameworks give you the freedom to experiment with how content is organized without having to re-engineer a product’s core functionality.

Like any design endeavor, effective A/B testing should follow a clearly defined methodology. First, decide what variable you are testing for. Next, define what constitutes success. Finish by evaluating the data and determine what the next step should be.

For example, in one case, the layout hierarchy was tested. Layout A was made up of a two-column grid that had the patient list component on the left of the screen and the patient profile component on the right. Layout B had a single-column patient list that would click through to the patient’s profile component.

Our first test was for clarity. We asked clinical advisors in interview sessions which of the two designs felt the most organized. Contrary to internal assumptions, the single-column grid was strongly indicated to be the more intuitive design solution. Our advisors felt that the combination of a patient list and profile in the same display felt “busy” and “cluttered.” In contrast, words used to describe the single-column grid layout were clear and “clean.”

The “Component Box Model”

For this web application, we used React, a framework based on concepts of state management and modular components. React is a declarative, efficient, and flexible JavaScript library for building user interfaces. It lets you compose complex UIs from small, isolated pieces of code called “components.” This modularity translates to flexibility when working on a product involving both developers and designers.

I came to understand this framework with inspiration from the HTML+CSS box model. The Component Box Model offers an organizational modality with which to create building blocks for an application. It’s especially well-suited to developing a design system for rapidly evolving projects.

To keep design thinking agile, a set of design principles especially well-suited to a lean product development lifecycle can be followed.

• First principle: Group similar contexts and actions.
• Second principle: Let the information architecture assist in simplifying the flow of “state” between components.
• Third principle: Design scalable visual systems to streamline how developers understand and implement designs.

Grouping Similar Contexts

Consider your users’ mental model—group similar outcomes and actions based on their “context of use.” Consider whether users need to create, read, update and delete items within each context, and if you need to provide any feedback for their actions. When defining an A/B test for a specific use scenario, consider layout, how to access inputs and methods of navigation.

Simplify the Interaction Flow of “State”

In React, the flow of “state” refers to how information moves throughout an application, how components help organize data and how it’s displayed. Typically, state flows into display components from functional components acting as containers. Designers can prepare for A/B tests by preemptively outlining how functional components can alter an application’s layout by shifting how display components are assessed.

Develop Robust Design Systems

Using display components to develop standards for visual elements like typography, buttons, inputs, modals, and cards helps to provide the building blocks for a standardized design language. Robust visual systems have the flexibility to keep UX designers and developers on the same page about components referenced within wireframes.

Summary

The success of A/B test-driven design is tied to the synergy between product and technical teams. Designers looking to adopt this method should be precise about where and how to test. Spend time developing a hypothesis and determining what you are hoping to find out. Don’t get distracted. Stick to it—very it’s easy to veer away from your method.

This process is never really finished and evolves as products grow. Designers employing a test-driven product development strategy should take advantage of the opportunities for learning that arise throughout a product’s development lifecycle.

Components, much like design systems, are about modularity and the reusability of patterns, not about layout or style. From a designer’s perspective, the flexibility to test, refine, and improve products with A/B testing can help develop products that are more user-centered, which ultimately leads to their greater success.