Helix

< Back to portfolio

BMC Helix was a large scale project my team took on in 2017, at the request of our division lead for Digital Service Management (DTSM). At the time, the space was visibly on the cusp of a number of shifts; the traditional workforce was turning over and becoming much younger, budget allocations were moving steadily away from personnel, and new technologies, like artificial intelligence, machine learning, and IoT were promising to change the way service desks operated.

To understand these trends more clearly, division leadership charged UX with the goal of both clarifying how and why these shifts were occurring, and to develop an action plan for meeting this changing landscape, long-term and short. My role in the project was to work as part of a cross-functional leadership team, and be primarily in charge of initial strategy, design execution, and planning across the division.

What were we solving for

As mentioned above, the landscape for IT service management was starting to dramatically shift under the feet of many of BMC’s largest customers. Many CIOs and IT departments were experiencing new challenges as a result of changing workforce needs, centralization trends in back-office teams, and new technologies with the potential to change how IT departments operated at scale. On top of this, many departmental budgets were being constrained, rather than expanded, leaving many of our customers in a state of having to figure out how to do more with less.

The UX team was brought in to help, not only make sense of these changes, but to also outline the strategies that would enable BMC to get ahead of them. The team was also on the hook to meet tangible milestones, including the delivery of “intelligent experiences” across all DSM applications in 2018, as well as tactical roadmaps for each product area to commit to as we evolved the concept into 2020.

Research questions

How does the service management organization, including its products, offerings, and services need to shift in order to meet the current changing environment within IT service management?

What does the evolution path from here look like in order to meet these necessary changes?

How does this evolve as we get from one year out, to two, to five?

What does the action plan look like to get us from one of the milestones above to the next?

The work

Foundation (3 weeks)

The team segmented the work into four discreet stages, each focused on specific outcomes and deliverables meant to drive the project forward quickly, and allow for tangible outcomes where possible. The first stage was our foundation stage, and consisted largely of gathering insights from internal leadership, sales, industry analysts, and past projects. The outcomes of these activities provided the team with a strong baseline of knowledge to move forward from, while also exposing gaps that the team would need to fill in our next stage of work.

The project's foundational phase relied on internal knowledge gathering and a lot of future activity planning.
This is the initial business question that prompted the work. Indicators across a number of sources were predicting the shrinking and centralizing of service management within large organizations; a huge change from where we were currently.
In response to this question the cross-functional team was asked to deliver on these three goals.
The initial foundation phase was about establishing a baseline of understanding from which to build hypotheses from. This is a portion of the output from internal interviews we did across all levels and areas across the company.
Interviews with our customer advisory board, as well as service, sales, and support yielded a number of near term trends that spoke to various opportunities and lines of questioning.
Customers and support agents also spoke to a number of things they observed in their workforce/clients.
Across all of these interviews, notes were taken on the types of technologies people assumed would driving a lot of change over the next two years.
Sales staff were also asked to talk about organizational hurdles that they believe affected bmc's ability to respond to the needs of their clients and prospects.
A list of project mandatories was created from these interviews to both guide discovery and help define success.
In addition to the mandatories, a series of shifts were outlined that defined the major changes we'd need to react to, both in our products and the organization.

Discovery (5 weeks)

The second stage of work was about filling in gaps, and checking back on the information we received in the foundation stage. This stage consisted of a couple of different research activities. Firstly, the team set up a series of interviews to discuss expectations with new IT and service desk employees. Secondly, the group ran a series of contextual studies at the sites of some of our biggest customers. Finally, key learnings were translated into vision statements for each area of inquiry; customers, their workers, technology, and organizations (ours and theirs). The outputs from this stage were leveraged as direct inputs into business direction planning, and the design concepting work that would be the focus of the next stage.

The discovery phase took the learnings from foundation and extended them beyond our internal sphere of knowledge. It was in this phase where we looked to test some of our assumptions, dive deeper into the factors driving certain trends, and develop a grounded future product strategy.
Most of the discovery process took place in the field, and leveraged a mix of activities. For folks closer to the work, like service desk agents and end users, this took the form of in-context interviews.
Depending on the level and role of the participant, certain activities were also done to collect additional information. Most of this involved evaluating some of the themes that came from foundation.
This "5 Biggest Problems" task was done with most of the people we sat with and interviewed. The goal was to identify blind spots and test our own assumptions at different organizational levels. Outputs were summarized for our customers so they could benefit from the learnings as well.
For roles with decision making authority, the team also asked about technology bets. These were largely focused on where their budget was planned to go over the next couple of years and why.
A collaging exercise was done with other roles in order to help us visualize and understand expectations around an ideal future state.
Where willing, leadership in the organization was asked to present the outcome of their activities to their colleagues and us. Discussion typically followed, along with points and counterpoints on each perspective.
In addition to the field work, we also ran a series of interviews with early-career employees at companies that were considered to be "innovators" (Apple, Stitch Fix, LuLuLemon, etc.). These end-users we asked about their internal systems, and what was and wasn't meeting their expectations.
Affinitizing the findings from our various interviews and activities allowed us to develop 9 design principles that would help drive ideation and concepting in the next phase of work.
Major technology bets and success metrics also provided some additional goals and mandatories that we would use when evaluating our own solutions.

Envision (11 weeks)

The envision phase involved translating our learnings from discovery into a fully-fledged concept. The initial phase occurred in two concurrent steps, one being a series of validation exercises with customers on the statements we generated, and the other being the development of a pair of narrative storyboards showing those value statements applied to customer problems uncovered during research. The storyboards went through multiple revisions with customers before getting translated into a series of concept designs, and then a short video, outlining the concept and our first raft of solutions. The team also prepared a series of decks for various stakeholder groups across the organization that delved deeper into the findings, the Helix strategy, and how to execute off of it.

Helix concept video

Helix concept video we developed as a primer for the ideas we generated out of our research. Contains audio

Video stills for the end user UX: Issue reporter
End user: Issue capture
End user: Issue capture from dialog image
End user: Ticket builder
End user: Reporting questionnaire
End user: SLA reporting with defaults
End user: Feedback
End user: Final notes
End user: DWP Event summary
End user: Policy cross-sell
Service desk stills: Proactive issue resolution
Service Desk: Ticketing workspace (from DWP)
Service desk: Ticket details
Service desk: Task details
Service desk: Recommendations
Service desk: Asset profile with heads up
Service desk, Service health monitoring
Service desk: Activations
Service desk: Shadow IT asset registration
Service desk: Ticket recording
Service desk: Messenger
Service desk: Issue resolved
Service desk: Kudos and leaderboard

Envision focused on the creation and development of our core concept, as well as testing and iterating on some of the core ideas coming out of the concept generation process.
The main concept, Helix, was personified in our concept materials due to the large amount of interpersonal factors that were at play in our findings and solutions. The robot wasn't mandatory, but was more a vehicle for the type of personality we wanted the solutions to have.
Our original principles were refined to reflect the types of solutions we thought a Helix experience should provide organizations and their users.
Individual features from the video were collected into an interactive experience that showed the concepts in action. This experience was used to test and refine the ideas with customers before extending the concept with the broader business unit.
Each concept, and the overall video were scored by a broad set of customers on a number of factors. Follow up occurred with some participants to get more detail, and refine our approach.
While the feedback was coming in, the design team began pulling together a three day workshop that would allow designers, architects, and PMs from across the business unit to apply the Helix principles to their own products.
Workshop attendees would work together in their product groups to identify and choose up to 5 use cases that aligned with the Helix charter.
Just like we did with the video concept, attendees were encouraged to craft a narrative around their use cases, and the improvements enabled via Helix.
Storyboards were used to describe ideal outcomes and the solutions that enabled them.
Discussion between teams allowed us to build on ideas and come up with ways to integrate solutions between product areas.
After the ideas were worked out. Separate sessions were done with design to help them visualize their ideas.

Build (2018 through 2020)

Following a string of participatory design sessions, with both customers and their users, the concepts was considered final enough to move into broader design. This occurred over a few distinct stages, starting with a series of feature workshops. These workshops introduced PMs, designers, and architects to the concept, and then asked them to work in cross-functional teams to develop feature ideas aligned to it. Following the workshop sessions, the team worked specifically with the designers for each group to flesh out their top ideas and define high-level use cases. Those feature statements were then collected in a backlog and run through concept value test sessions with a number of uninitiated customers.

At the end of this process the team had a broad list of Helix-aligned features, prioritized by our customers, and backlogged across the entire organization. The team then held one final group session with architecture and product management to collect initial estimates, refine use cases based on open questions, and rank those features into feasible time frames for delivery. Following the sessions each product had three features they were responsible for in each of the timeframes we were asked to target. Many features fell across multiple teams, thus enforcing the need to integrate efforts across the business unit, as was a key aspect of both the concept and the ask.

The build phase was about narrowing our options to a reasonable set of high value efforts that team could pursue each year. It involved testing our ideas, establishing priorities, and developing and executing on our shared roadmap.
Working with a team to help identify and describe integration opportunities for a proposed Helix feature.
Technical architects were frequently brought in to help us refine cross product solutions, and ensure feasibility.
This is an example of a ticket swarming and automation concept that tied together a number of individual solutions.
Intelligent notifications were a frequent area of opportunity across products. This concept outlines notifications for improving efficiency in business workflow creation, a backbone for a lot of our service management solutions.
Concept that can determine alternate service options in order to save money.
Issue prioritization and impact concept for ticketing scenarios.
Solution recording and remediation concept.
Freeform was a concept that allowed for auto detection and setup of business logic based on application building blocks.
Ticket decomposition concept for breaking down tickets into tasks
Ability to make requests for common analytics needs. This concept predates LLMs.
Profile builder concept. Data from individual profiles could be used across BMC products.
Proactive issue resolution concept. These were just a handful of the 100+ ideas that were generated through the workshops.
Once the concepts were all finalized the team leveraged an internal voting process to stack each idea based on a number of factors.
Scoring was done both between and within the various product areas to allow us to prioritize across individual product silos.
Estimates were taken into account individually, and across the entire business unit. This allowed us to plan for integration needs and better operationalize design across specific areas of business over time.
Once the high level priorities were sorted and ranked. The team worked with various areas of product management to collect and collate the requirements.
Since most requirements were housed in individual Jira instances, we ended up starting with a master list of requirements that would later be fed down to individual teams.
The team worked from the highest priority, and most immediate items back, eventually breaking down and transferring all of the initiatives down to the individual teams.

Proof of concept work

As feature iteration was occurring across the UX organization, the core team was asked to partner more closely with a couple of teams to help develop a handful of POCs for various business objectives. The POCs covered a number of needs, including things like business development, sales and marketing, and new product concepts.

Proof of concept for a chatbot-based PC refresh scenario, used largely for sales. Because of the context, the team was asked to go a bit heavier on the inclusion of the Helix character.

Proof of concept for a revised integration studio application, leveraging some of the core smart integration ideas that came out of the workshops. This was meant to serve as a starting point for ideation heading into detailed design.

Outcomes

In total, the Helix project produced 44 major feature concepts affecting the entirety of the DSM catalog, as well as 77 smaller features identified as gaps or opportunities during the discovery and envision phase of the project. Each one of these features was cataloged, fleshed out with requirements, and outlined in design before being ported over into each product team’s individual Jira instance. From a commitment perspective, each participating team was able to complete their required features within the first year of the concept rollout, for a total of 6 major Helix features being released within and across teams. Furthermore, teams were also able to close 24 of the original 77 smaller feature requests by the end of 2018. Anecdotal feedback from sales estimated that at least 28 major deals or renewals were closed between 2018 and 2022 as a result of Helix functionality, including partnerships with Ford, Ericsson, and Darden Restaurants.

Helix features ended up having an outsized affect on our observability and ticketing products, with some customers able to achieve large reductions in outage, MTTR, and issue resolution times. In 2020, BMC Helix became the brand moniker for all data-driven ITSM products and services within the DSM division. In 2024, BMC Helix was spun off of BMC as a separate entity, focusing on innovation in data, automation, and AI with in the IT Service management space.

Summary

Tangible outcomes

Forty-four major concepts with initial design, broken down and ported into DSM roadmaps
Six major cross-product concepts launched across DSM in the first year
Seventy-seven individual helix features outlined and sent to product backlogs
Twenty-four individual features closed by the end of 2018
At least 28 major deals and renewals closed resulting from Helix features in 2019-2020
Helix observability features linked to 76% increase in service health, 60% reduction in MTTR, and a 64% reduction in outages
Helix recorder and digital workplace features allowed some customers to get to 90% root cause identification and see a 65% reduction in issue resolution time

Impact

BMC Helix ITSM considered a leader in IT service management in Gartner’s 2020 Magic Quadrant
Helix concept became the major theme of Exchange 2021, BMC’s user conference
Helix is now a major platform within the ITSM business
Major features still releasing, as mandated, for each product area, as of 2021
Helix features drove major updates to dynamic service modeling, automated remediation, chatbot/virtual agent, and issue reporting
Ten Helix-based components and services released to the organization as building blocks via ADAPT as of 2021
BMC Helix transitioned to a separate entity, spinning off of BMC as it’s own company, as of 2024

Back to portfolio

Helix

What were we solving for

Research questions

The work

Foundation (3 weeks)

The project's foundational phase relied on internal knowledge gathering and a lot of future activity planning.

This is the initial business question that prompted the work. Indicators across a number of sources were predicting the shrinking and centralizing of service management within large organizations; a huge change from where we were currently.

In response to this question the cross-functional team was asked to deliver on these three goals.

The initial foundation phase was about establishing a baseline of understanding from which to build hypotheses from. This is a portion of the output from internal interviews we did across all levels and areas across the company.

Interviews with our customer advisory board, as well as service, sales, and support yielded a number of near term trends that spoke to various opportunities and lines of questioning.

Customers and support agents also spoke to a number of things they observed in their workforce/clients.

Across all of these interviews, notes were taken on the types of technologies people assumed would driving a lot of change over the next two years.

Sales staff were also asked to talk about organizational hurdles that they believe affected bmc's ability to respond to the needs of their clients and prospects.

A list of project mandatories was created from these interviews to both guide discovery and help define success.

In addition to the mandatories, a series of shifts were outlined that defined the major changes we'd need to react to, both in our products and the organization.

Discovery (5 weeks)

The discovery phase took the learnings from foundation and extended them beyond our internal sphere of knowledge. It was in this phase where we looked to test some of our assumptions, dive deeper into the factors driving certain trends, and develop a grounded future product strategy.

Most of the discovery process took place in the field, and leveraged a mix of activities. For folks closer to the work, like service desk agents and end users, this took the form of in-context interviews.

Depending on the level and role of the participant, certain activities were also done to collect additional information. Most of this involved evaluating some of the themes that came from foundation.

This "5 Biggest Problems" task was done with most of the people we sat with and interviewed. The goal was to identify blind spots and test our own assumptions at different organizational levels. Outputs were summarized for our customers so they could benefit from the learnings as well.

For roles with decision making authority, the team also asked about technology bets. These were largely focused on where their budget was planned to go over the next couple of years and why.

A collaging exercise was done with other roles in order to help us visualize and understand expectations around an ideal future state.

Where willing, leadership in the organization was asked to present the outcome of their activities to their colleagues and us. Discussion typically followed, along with points and counterpoints on each perspective.

In addition to the field work, we also ran a series of interviews with early-career employees at companies that were considered to be "innovators" (Apple, Stitch Fix, LuLuLemon, etc.). These end-users we asked about their internal systems, and what was and wasn't meeting their expectations.

Affinitizing the findings from our various interviews and activities allowed us to develop 9 design principles that would help drive ideation and concepting in the next phase of work.

Major technology bets and success metrics also provided some additional goals and mandatories that we would use when evaluating our own solutions.

Envision (11 weeks)

Helix concept video

Video stills for the end user UX: Issue reporter

End user: Issue capture

End user: Issue capture from dialog image

End user: Ticket builder

End user: Reporting questionnaire

End user: SLA reporting with defaults

End user: Feedback

End user: Final notes

End user: DWP Event summary

End user: Policy cross-sell

Service desk stills: Proactive issue resolution

Service Desk: Ticketing workspace (from DWP)

Service desk: Ticket details

Service desk: Task details

Service desk: Recommendations

Service desk: Asset profile with heads up

Service desk, Service health monitoring

Service desk: Activations

Service desk: Shadow IT asset registration

Service desk: Ticket recording

Service desk: Messenger

Service desk: Issue resolved

Service desk: Kudos and leaderboard

Envision focused on the creation and development of our core concept, as well as testing and iterating on some of the core ideas coming out of the concept generation process.

The main concept, Helix, was personified in our concept materials due to the large amount of interpersonal factors that were at play in our findings and solutions. The robot wasn't mandatory, but was more a vehicle for the type of personality we wanted the solutions to have.

Our original principles were refined to reflect the types of solutions we thought a Helix experience should provide organizations and their users.

Individual features from the video were collected into an interactive experience that showed the concepts in action. This experience was used to test and refine the ideas with customers before extending the concept with the broader business unit.

Each concept, and the overall video were scored by a broad set of customers on a number of factors. Follow up occurred with some participants to get more detail, and refine our approach.

While the feedback was coming in, the design team began pulling together a three day workshop that would allow designers, architects, and PMs from across the business unit to apply the Helix principles to their own products.

Workshop attendees would work together in their product groups to identify and choose up to 5 use cases that aligned with the Helix charter.

Just like we did with the video concept, attendees were encouraged to craft a narrative around their use cases, and the improvements enabled via Helix.

Storyboards were used to describe ideal outcomes and the solutions that enabled them.

Discussion between teams allowed us to build on ideas and come up with ways to integrate solutions between product areas.

After the ideas were worked out. Separate sessions were done with design to help them visualize their ideas.

Build (2018 through 2020)

The build phase was about narrowing our options to a reasonable set of high value efforts that team could pursue each year. It involved testing our ideas, establishing priorities, and developing and executing on our shared roadmap.

Working with a team to help identify and describe integration opportunities for a proposed Helix feature.

Technical architects were frequently brought in to help us refine cross product solutions, and ensure feasibility.

This is an example of a ticket swarming and automation concept that tied together a number of individual solutions.

Intelligent notifications were a frequent area of opportunity across products. This concept outlines notifications for improving efficiency in business workflow creation, a backbone for a lot of our service management solutions.

Concept that can determine alternate service options in order to save money.

Issue prioritization and impact concept for ticketing scenarios.

Solution recording and remediation concept.

Freeform was a concept that allowed for auto detection and setup of business logic based on application building blocks.

Ticket decomposition concept for breaking down tickets into tasks

Ability to make requests for common analytics needs. This concept predates LLMs.

Profile builder concept. Data from individual profiles could be used across BMC products.

Proactive issue resolution concept. These were just a handful of the 100+ ideas that were generated through the workshops.

Once the concepts were all finalized the team leveraged an internal voting process to stack each idea based on a number of factors.

Scoring was done both between and within the various product areas to allow us to prioritize across individual product silos.

Estimates were taken into account individually, and across the entire business unit. This allowed us to plan for integration needs and better operationalize design across specific areas of business over time.

Once the high level priorities were sorted and ranked. The team worked with various areas of product management to collect and collate the requirements.