ADAPT

< Back to portfolio

ADAPT is bmc’s UX platform, which I established and ran for six years while at the company. The platform consisted of a multitude of tools and services for bmc product teams, including a fully stocked UI component library in Angular and WebComponents, guidelines, Figma/Sketch resources for design, multiple high level patterns, experience-oriented services, and an interconnected data analytics platform. Leading this platform was my primary responsibility at BMC, both as a product owner for UX and as a lead designer. My work was supported by a diverse team of designers, UI developers, production staff, and team managers, reporting through me.

What were we solving for

In my first two years at BMC I was responsible for leading the design of the company’s end-user experience products. This included any product in the portfolio that had a workforce-facing component to it. The main product in this portfolio was MyIT, which I transitioned from an “iTunes for services” model into a smart, events-based platform for you workplace, or a Digital Workplace.

At this time, the company had a very small reference library for some common components used across the product space, but they were rarely used consistently, if at all. Most teams at this point built their UIs using these elements as a style reference, but it was rare that code was snipped from one of the examples and used directly in a product.

The Digital Workplace transition required a lot of the existing areas of the product to go through some significant design change, and it was these changes that brought to light many common issues stemming from a lack of standards in UI development; eight types of buttons that look the same but have different underlying code, development estimates that ballooned as a result of unnecessary and unknown deviations, and UI bugs that were solved in one place but not in others. Having worked closely on component libraries at Amazon I knew the symptoms, and their solution fairly well. So, I worked with the director in charge of UI development, and our PM to reorient the schedule so that we could include component creation, as part of the transition process for DWP. It was from this effort that ADAPT was born.

Goals

Better, more innovative, more consistent products that get to market faster.

Greater ability to understand, and act on, what works, what doesn’t, and why.

Increased presence, and the establishment of BMC as an innovator in the technology space.

The work

Transitioning to a company-wide framework

The framework that was created as part of the Digital Workplace transition was fairly simple, consisting of a translation of Bootstrap components to match up with the small number of component examples in our existing “Design Pattern Library.” The team extended Bootstrap’s utilities-based approach to ensure scalability (DWP was planned to be white-label-able), and templates were created for most of the major component’s in Angular. This approach was simple but highly effective, and by the time we made it to the initial DWP release I was already working with some of the newer products to adopt it as a standard.

Seeing the possible benefits that wide-spread adoption of a framework like this would have, the leadership team in design made the decision to make extending the framework for use in other business a priority for the team. This process involved a lot of up-front work, both in making the existing framework a better fit across the organization, but also in the development of programs, processes, and governance to support the type of community engagement a UI framework at this scale would need to be successful.

Over the next couple of months I led efforts to lay the groundwork for many of these needs, along with leaders in both design and front-end engineering across BMC. These efforts culminated in a rough set of rules, processes, and procedures for both design and development, as well as an initial backlog of components and infrastructure. Once we had a rough proof of concept, budget was allocated from design to place a small team of designers and front-end developers under me to assist with tactical needs relating to growth and adoption.

The first set of workshops were sense making exercises between design leadership and front-end development. Outcomes from these meetings were used to identify all the potential needs the team would have to cover in order to support cross-organizational adoption.
Transition needs were grouped into themes. The group then worked through each to plan direction and set up future work streams.
Another point of focus for the beta release of the framework was to ensure we had enough coverage and alignment with our products. Design leads ran a workshop examining the current system to identify component gaps and design language needs. The outcomes were either planned for the beta release or added to the backlog for future execution.
We used an Axure prototype to track key components in our pattern library and products that needed to be transitioned to the new system prior to launch.
A concurrent activity that the team ran was a series of interviews with various product teams in order to model a general design-development process. These models were used in process planning and governance.
This work allowed us to identify a number of specific scenarios that helped us plot out platform direction as a whole. Some of the insights fed into our process directly, while others provided insight into future adjacencies the platform could eventually move into.
Some of the initiatives were broken down and estimated for the initial beta release, while most of these concepts were added to our backlog as part of the platform's long term strategy.
Many of the larger, future-facing, concepts were packaged as specific internal offerings. This served as a flexible roadmap for the team and forced us to dedicate some time each release to platform expansion. By the time I left the team most of these areas had their priority use cases solved for in some form or another.

Basic structure

The basic structure of ADAPT followed a simple architecture, playing largely towards the decisions that were made in the library we started with Digital Workplace. The framework was based largely on Angular, since that’s what 90% of our UI developers in the organization leveraged. We would eventually support other libraries through Web Components (mostly for M&A products), but at the time our architecture governance board decided it would be less disruptive to the overall product roadmap if we kept course.

The components themselves sat on top of a modified version of Bootstrap (v4-eventually v5), with custom, higher-order elements sitting on top of that foundation. More advanced, 3rd party based patterns like data grids (PrimeNG), Gantt Charts (Prime), and Visualizations (D3) made up the upper layer, along with a number of home-grown patterns that were either built or borrowed from other areas of the company. The library also maintained a large collection of tools, services, and utilities, all powered by a highly semantic design foundations layer. Design foundations themselves were designed to be highly permutable, largely because of product requirements for white labeling, but also for the amount of agility it provided in aligning the product and brand sides of our organization, a typical pain point for sales.

The framework itself was able to adapt to a number of contexts of use. It easily supported the typical desktop, mobile, and tablet contexts, but also had support for TVs and hybrid devices, such as touch-screen desktops. Short-term native support was included for our initial base components via Native Script, but the goal was to move most teams over to adaptive web (many of the benefits of native weren’t being realized in product). This was done to drive faster adoption of non-desktop modalities, ensure grater consistency, and allow the team to better bridge services across context in an agnostic way.

This is the basic ADAPT platform architecture for the component library. The diagram represents most of the major capabilities of the framework.
This is an alternate version, representing the UI framework along with higher order elements and services. Pattern creation and workspaces services were a primary focus for the team heading into my final year leading the platform.
This is the list of personas the design system served. Various scenarios were developed early on to determine the types of tools needed to support them.

Governance

Along with the framework itself, the team iteratively developed a number of processes and programs aimed to fairly, and judiciously govern the direction of the design system. The system we developed relied heavily on cross-company collaboration, evenly applied rules, and a system of checks and balances that promoted consistency without holding teams back or stifling their ability to innovate.

This was the basic description of the platform that we used when introducing ADAPT to different product areas and business unit leaders.
This charter represents the three main objectives that the library was meant to solve. Any new platform capabilities generally had to satisfy the goals in at least one of these three pillars in order to be considered.
In order for ADAPT to meet the objectives set in our first pillar, it was really important for the team to design a set of policies and practices that combined the best aspects of Agile development and UCD, while also mitigating the negative effects of each on the other.
ADAPT, as a platform, was conceptualized from the start as more than a component library. At its core, ADAPT was about enabling better, faster outcomes for our users, and so we viewed our core capabilities as engines for adjacent tools and services.
Tenets served at the overarching rules governing decisions across ADAPT. Everyone, including ADAPT leadership, were bound by them when making decisions. That said, nothing was set in stone. While these tenets bound our decisions, they were also procedurally open to challenge if anyone saw fit.
ADAPT's change management policies determined what was required for work approval. Issues still required grooming, prioritization, and scheduling before any approvals were required. This usually occurred in multiple places in our pipeline; proposal, triage, design, development, and release.
Most major decisions and changes required some level of governance review. Governors were the main voting body outside of the design systems team, but other bodies existed to allow participation across the company. The ADAPT team served largely as a floor manager and facilitator to the decision making process, but also had voting rights in the event of a tie.
Basic explanation of our ownership model. We relied largely on a system of checks and balances in order to mange the need for consistency with the drive to innovate.
Procedures, like this one for enhancement requests were written up to provide guidance to teams and new team members.

The Framework

The component library itself was highly stocked, including all of the typical consumer components, plus a number of additional elements unique to enterprise contexts. Because data management and intelligence was a core part of most BMC products, the team created a number of specialized form, data management, and data visualization elements for our internal teams to leverage. Communication and messaging was also a large part of the service desk experience, and so we also had a robust library of messaging and chat tools for designers in that space. Services and utilities were leveraged heavily throughout the system, both as a way maintain consistency, and as a way to allow non-destructive innovation when needed.

To support knowledge management needs across the team, ADAPT maintained a centralized documentation site that held specifications, code, examples, and guidance, as well as design-related artifacts coming from user research, content, and our other internal partners. The team also maintained design libraries and templates for Creative Suite, Sketch, inVision, and later Figma, which became our de-facto design tool over time. Asset libraries for icons, illustrations, and BMCs brand assets and guidelines were also housed there.

Our Documentation homepage in both dark and light mode
This is an example of our base components page. Each component page had a section for guidelines, a default example with api references, and a list of examples that were pulled from our support channel. Storing the examples in docs allowed us to create a fairly robust repository of developer knowledge that could be leveraged as a first line of support.
Each example contained an editable view, so that developers could see and interact with the solutions for various use cases. If someone had a better way to solve the problem, they were able to make edits directly in the tool and submit the solution as a PR to the appropriate ADAPT repo.
Uploader component with developer documentation
This is an example of one of the design language elements I developed for the system. A number of the base functions for the design language, or semantics underneath them were developed initially by me before further iteration from the larger team.
Example of our date range picker in both modal and inline states
Images were a big part of catalog creation in service management. Components like this image cropper allowed users to frame and present various services in a consistent manner across various contexts of catalog ownership.
ADAPT contained a number of... adaptations for various contexts of use. Each component in the library contained adaptive styles for mobile, tablet, and other large screen devices like TVs. We also had translators for different workplace tools so they could be better integrated into various integrated environements.
Example of a guidance page for WCAG compliance. The team also maintained a number of tools that would enable compliance for both our products and ADAPT.
Example of one of our guidelines pages. This one explained how our colors and semantic ramp worked.
Whenever major design efforts occurred for specific systems the lead designer would be responsible for writing up a whitepaper for inclusion in our documentation. This is an example of one that we did for our accessible data visualization palette.
More component, service, and documentation examples coming soon.

Some component animation compositions from design iteration.

See the Pen Grippers by Jeff Lerch (@lerch015) on CodePen.

Some code sketches for early component styles and interactions. I used these mostly to establish look and feel, rather than represent any final result.

See the Pen Jab, CAM02 by Jeff Lerch (@lerch015) on CodePen.

See the Pen Modified shadows by Jeff Lerch (@lerch015) on CodePen.

See the Pen Untitled by Jeff Lerch (@lerch015) on CodePen.

The Patterns

On top of the more basic components, ADAPT also contained a robust set of repos dedicated to more complex patterns used across our products. ADAPT’s approach was conceptually close to what you’d find in atomic design, at least in terms of how things accrued towards higher levels of complexity, but it differed in that the levels themselves were focused on the types of needs we were supporting, rather than the way that elements were structured. As such, components were seen as UI elements supporting specific interactions, whereas patterns were task-supporting elements that might require more than one interaction to fulfill a task. Higher order elements were supported as well around specific goals, like submitting a ticket, and specific pieces of work, like configuring the overall branding for your suite of products. By the time I left BMC, the library had about ten major patterns, including advanced data grids, Gantt charting, Events, and advanced topology patterns. Higher-level elements existed as well, typically for shared workspaces across single lines of business.

Many of these elements were identified and iterated on through a program I instated called Converge, which was essentially an ambassadors forum across the various businesses areas of the organization. In the Converge process, team leadership would be allowed to present or propose common patterns, or larger elements, that were in flight and broadly applicable across teams. Proposals would be prioritized by the team and, if resourcing was available, both the team and ADAPT would co-create the element as a general pattern that the requesting team would eventually integrate and test in their product. This approach typically ended up leading to a win for both sides, as ADAPT would be able to better build it’s capabilities through co-creation with our users, and individual teams would get assistance and maintenance support for some of their larger UI elements. This process also created a number of additional innovation opportunities in both directions, as new perspectives were brought into and out of the team on a fairly constant basis.

In order to reduce the decision space between the component library and our products, ADAPT also maintained libraries of higher-order elements, generally organized by the breadth of the user needs each element was solving for. The design and build process for these larger elements was called Converge.
The process for pattern inclusion was largely community driven, with product areas divided into five groups based on business pillars. Typically teams would come to us in the process of solving for their own space, and then partner with our working groups to generalize their solution for the broader organization.
Pattern development was typically a big lift in terms of capacity, and could only take up so much of our total effort each sprint. Because of this, KPIs were developed to both evaluate incoming proposals and measure their success.
This is an example of a pattern concept we explored for a mega-menu based primary nav bar. The gradiation in the bar was designed to work well with our white-labeling capabilities, which almost every one of our customers used.
By basing the interaction model off of a file picker the bar supported infinite depth in navigation. At more shallow depths product teams had the ability to surface important information, generally system health summaries.
A smart toolbar pattern was integrated into the navigation in order to support common, cross product needs such as help.
General notifications and events passed between products by DWP...
And role specific utilities like localization managers, helpful in rotating service desk contexts.
Entity workflow pattern
ADAPT contained a lot of patterns related to global settings across our applications. This is an example of our profile avatar panel, which was a common component across all of our experiences.
One of the more ubiquitous major patterns in most enterprise environments is a robust data grid. This was one of the first major patterns that we launched.
A child pattern to the data grid was the advanced filter component. The pattern allowed for multiple levels of filtering, from discreet, to faceted, to the use of complex expressions. Additional functionality allowed users to save and send specific queries between people, or assign them to specific entitlement groups.
Heatmap Pattern
BMC products were all designed to be externally white-labelable by our customers. This meant that we didn't have the ability to use color, as much as differences in the color space to represent specific semantics across the UI. This workspace was another settings component that allowed customer admins and their tenets to adjust global color across all of their BMC product offerings. There was an set of back end services that would propagate these changes across the organization.
This is another view of customization for any main framework elements. ADAPT color systems needed to permute with these settings in order to address different accessibility needs. Guidance was provided for customers to inform them about their default choices. That said, even if there was an area were a specific need wasn't met, users could identify any needs associated with their disability and ADAPT would be able to auto-correct using the customers colors as a baseline.
Gantt charting was a common scenario in change management, and many other scenarios where collisions or dependencies across areas of business could happen. ADAPT's timeline pattern was a robust tool for managing these use cases constantly across product.
Chatbots and live agents are another common element in enterprise service management. Our messaging pattern supported both modalities fully, with unique functionality for each.
More pattern and workspace examples coming soon.

The Broader Platform

Due to our charter as a platform for user experience, the ADAPT team frequently took advantage of adjacencies to the design system to power other tools and services that broadly had an impact on the quality and experience of our products. Some of these things were home grown tools that we were using that we sourced across the organization, like our ZenHub/Github-based sprint planning application or or the roadmap-alignment tools we developed to prioritize our work across the organization. Others were more purpose-based, tools like splash screen generators, illustration builders, and our white labeling interface.

The largest of these was RADAR, an analytics platform built on top of ADAPT, that leveraged our components to ease the instrumentation of our products and set the company up to both develop and track experience KPIs at multiple levels of the business. The platform itself was agnostic, due to scale, technology, and regulatory needs, but the default configuration was done in partnership with Gainsight, which allowed us to add the data we were tracking to the company’s broader data lake. This allowed for post hoc analysis against other forms of telemetry across the company, and gave the design team the ability to correlate experience outcomes with outcomes from sales. For most teams, global instrumentation occurred out of the box, as long as you had a key and were using ADAPT. The platform also self-adjusted for GDPR, and worked in both cloud and on-premises scenarios, albeit with a slight lag in the later’s case.

RADAR was bmc's web analytics platform that we built on top of the component library. Anyone using ADAPT was generally included, and pre-instrumented, for data collection at the company level. Teams could tailor further to develop telemetry strategies for their individual products.
While the data collection service was the most pivotal component of the RADAR platform, the team also developed a broad set of processes and services to help make the data we collected actionable, and the teams collecting it accountable.
RADAR needed to deal with a broad set of observation modalities, typically coupled with mixed methods of deployment. To respond to this, RADAR events were defined across a spectrum, ranging from products, to business units, to all of bmc. This allowed leaders to identify trends across the business while still maintaining individual autonomy for each product.
To have the ability to accrue data up and down like that a clear architecture needed to be created in order to define the experience across product. This example shows a portion of the tagging methodology we used. In most cases ADAPT users would have many of these descriptions pre-instrumented if they followed certain procedures.
Most RADAR elements involving UI were templatized and deployed through ADAPT. This opt-in dialog was a standard pattern that was reviewable, and editable, by bmc legal so we could ensure compliance around ever-changing privacy laws and GDPR.
ADAPT sprint planner was an internal tool that we developed to help manage sprint ceremonies. The tool interfaced with Github and Zenhub, allowing users to manage their sprint schedule, capacity planning, assignment, demo, and retro processes in one place. Inputs into the tool were used in multiple ways, in communications, task management, planning, and automations.
Defect counters also allowed teams to specifically track sprint-to-sprint performance against company wide quality metrics. Most teams were required to meet these quality certification requirements in order to release.
ADAPT maintained a fairly robust animation library allowing users to leverage a specific set of transitions in their products. Teams leveraging this service were also able to give users control over animation preferences, for accessibility or otherwise.
Like many design systems today, ADAPT maintained a robust library of signs and symbols for use in our various products. Each symbol was defined through an intent semantic, rather than a descriptive name. This allowed us to update, and highly consolidate, the icons in use in our products with no team effort required.
Many bmc product's were designed to run in either hybrid or on-premises scenarios and, as such, required software installers. This splash-screen generator was a small tool we provided to both marketing and our product teams to ensure that our installers were up to date in terms of brand and legal compliance across all bmc installers.
This illustration builder tool allowed a designer/developer to describe a usage scenario and receive an adaptive, brand compliant, semantics compliant illustration that could be imported into their project. This tool started as an early concept leveraging our partnership with IBM Watson.
Another service the team supported was form email generation. Emails could be constructed from a specific set of boilerplates and building blocks for use in outbound communication from our products.

Outcome

As of 2024, ADAPT is still the standard, and now mandated, UI library in use across BMC. Many of the tools and features of ADAPT have lent to, not only to a more cohesive user experience across BMC’s products, but also many new innovations that were bootstrapped from ADAPT services and tools. ADAPT was also responsible for many efficiency gains, including a ~30% increase in UI development velocity (from the availability of initial measurement), vastly shortened proposal periods, and a reported 2 day decrease in design production time needed per week. By the time I left BMC in 2022, the team had grown from a small group of 2 designers and 2 developers to double the design staff and quadruple the development staff, largely at a time where most teams at BMC were going the other direction. ADAPT has also stood as a procedural model within BMC, with the team frequently being recognized for the efficiency, quality, and responsiveness of its development and management processes. For my part for founding ADAPT, I was the first designer in BMC’s history to receive a CRE award, which is the highest recognition the company gives to non-commissioned employees.

Back to portfolio

ADAPT

What were we solving for

Goals

The work

Transitioning to a company-wide framework

The first set of workshops were sense making exercises between design leadership and front-end development. Outcomes from these meetings were used to identify all the potential needs the team would have to cover in order to support cross-organizational adoption.

Transition needs were grouped into themes. The group then worked through each to plan direction and set up future work streams.

We used an Axure prototype to track key components in our pattern library and products that needed to be transitioned to the new system prior to launch.

A concurrent activity that the team ran was a series of interviews with various product teams in order to model a general design-development process. These models were used in process planning and governance.

This work allowed us to identify a number of specific scenarios that helped us plot out platform direction as a whole. Some of the insights fed into our process directly, while others provided insight into future adjacencies the platform could eventually move into.

Some of the initiatives were broken down and estimated for the initial beta release, while most of these concepts were added to our backlog as part of the platform's long term strategy.

Basic structure

This is the basic ADAPT platform architecture for the component library. The diagram represents most of the major capabilities of the framework.

This is an alternate version, representing the UI framework along with higher order elements and services. Pattern creation and workspaces services were a primary focus for the team heading into my final year leading the platform.

This is the list of personas the design system served. Various scenarios were developed early on to determine the types of tools needed to support them.

Governance

This was the basic description of the platform that we used when introducing ADAPT to different product areas and business unit leaders.

This charter represents the three main objectives that the library was meant to solve. Any new platform capabilities generally had to satisfy the goals in at least one of these three pillars in order to be considered.

In order for ADAPT to meet the objectives set in our first pillar, it was really important for the team to design a set of policies and practices that combined the best aspects of Agile development and UCD, while also mitigating the negative effects of each on the other.

ADAPT, as a platform, was conceptualized from the start as more than a component library. At its core, ADAPT was about enabling better, faster outcomes for our users, and so we viewed our core capabilities as engines for adjacent tools and services.

Tenets served at the overarching rules governing decisions across ADAPT. Everyone, including ADAPT leadership, were bound by them when making decisions. That said, nothing was set in stone. While these tenets bound our decisions, they were also procedurally open to challenge if anyone saw fit.

ADAPT's change management policies determined what was required for work approval. Issues still required grooming, prioritization, and scheduling before any approvals were required. This usually occurred in multiple places in our pipeline; proposal, triage, design, development, and release.

Basic explanation of our ownership model. We relied largely on a system of checks and balances in order to mange the need for consistency with the drive to innovate.

Procedures, like this one for enhancement requests were written up to provide guidance to teams and new team members.

The Framework

Our Documentation homepage in both dark and light mode

Each example contained an editable view, so that developers could see and interact with the solutions for various use cases. If someone had a better way to solve the problem, they were able to make edits directly in the tool and submit the solution as a PR to the appropriate ADAPT repo.

Uploader component with developer documentation

This is an example of one of the design language elements I developed for the system. A number of the base functions for the design language, or semantics underneath them were developed initially by me before further iteration from the larger team.

Example of our date range picker in both modal and inline states

Images were a big part of catalog creation in service management. Components like this image cropper allowed users to frame and present various services in a consistent manner across various contexts of catalog ownership.

Example of a guidance page for WCAG compliance. The team also maintained a number of tools that would enable compliance for both our products and ADAPT.

Example of one of our guidelines pages. This one explained how our colors and semantic ramp worked.

Whenever major design efforts occurred for specific systems the lead designer would be responsible for writing up a whitepaper for inclusion in our documentation. This is an example of one that we did for our accessible data visualization palette.

More component, service, and documentation examples coming soon.

Some component animation compositions from design iteration.

Some code sketches for early component styles and interactions. I used these mostly to establish look and feel, rather than represent any final result.

The Patterns

Pattern development was typically a big lift in terms of capacity, and could only take up so much of our total effort each sprint. Because of this, KPIs were developed to both evaluate incoming proposals and measure their success.

This is an example of a pattern concept we explored for a mega-menu based primary nav bar. The gradiation in the bar was designed to work well with our white-labeling capabilities, which almost every one of our customers used.

By basing the interaction model off of a file picker the bar supported infinite depth in navigation. At more shallow depths product teams had the ability to surface important information, generally system health summaries.

A smart toolbar pattern was integrated into the navigation in order to support common, cross product needs such as help.

General notifications and events passed between products by DWP...

And role specific utilities like localization managers, helpful in rotating service desk contexts.

Entity workflow pattern

ADAPT contained a lot of patterns related to global settings across our applications. This is an example of our profile avatar panel, which was a common component across all of our experiences.

One of the more ubiquitous major patterns in most enterprise environments is a robust data grid. This was one of the first major patterns that we launched.

Heatmap Pattern

Gantt charting was a common scenario in change management, and many other scenarios where collisions or dependencies across areas of business could happen. ADAPT's timeline pattern was a robust tool for managing these use cases constantly across product.

Chatbots and live agents are another common element in enterprise service management. Our messaging pattern supported both modalities fully, with unique functionality for each.

More pattern and workspace examples coming soon.

The Broader Platform

RADAR was bmc's web analytics platform that we built on top of the component library. Anyone using ADAPT was generally included, and pre-instrumented, for data collection at the company level. Teams could tailor further to develop telemetry strategies for their individual products.

While the data collection service was the most pivotal component of the RADAR platform, the team also developed a broad set of processes and services to help make the data we collected actionable, and the teams collecting it accountable.

Most RADAR elements involving UI were templatized and deployed through ADAPT. This opt-in dialog was a standard pattern that was reviewable, and editable, by bmc legal so we could ensure compliance around ever-changing privacy laws and GDPR.

Defect counters also allowed teams to specifically track sprint-to-sprint performance against company wide quality metrics. Most teams were required to meet these quality certification requirements in order to release.

ADAPT maintained a fairly robust animation library allowing users to leverage a specific set of transitions in their products. Teams leveraging this service were also able to give users control over animation preferences, for accessibility or otherwise.

This illustration builder tool allowed a designer/developer to describe a usage scenario and receive an adaptive, brand compliant, semantics compliant illustration that could be imported into their project. This tool started as an early concept leveraging our partnership with IBM Watson.

Another service the team supported was form email generation. Emails could be constructed from a specific set of boilerplates and building blocks for use in outbound communication from our products.

Outcome