Application Lifecycle Management

Creating seamless IDE integration and workflow tools for developers managing complex environments.

Project Overview

Company:Red Hat, Inc.

Role:Senior Interaction Designer

Timeline:2017-2019

Team: 2 Product Managers, 3 Engineers, 2 Designers, PatternFly Design System team

THE CHALLENGE: OpenShift developers were managing work items across 3+ disconnected tools (GitHub issues, Jira, internal tracking systems). This forced constant context-switching between their IDE, browser tabs, and project management tools—slowing development cycles, breaking focus, and creating visibility gaps for project managers.

The fragmentation was especially painful because developers had to:

  • Leave their IDE to check work item status
  • Manually link code commits to work items across multiple systems
  • Update work items in multiple places to keep teams synchronized
  • Context-switch an average of 20+ times per day just for task management

MY ROLE: A lead designer responsible for creating a unified application lifecycle management tool that would integrate directly into the IDE, eliminating context-switching and improving developer productivity.

THE SOLUTION: I was part of a team that designed Application Lifecycle Management (ALM), a unified work item tracking system that integrated directly into the OpenShift.io IDE. The design focused on eliminating context-switching by bringing work item management into the developer's natural workflow—allowing them to create, update, and track work items without leaving their code editor.

Key innovations included:

  • Seamless IDE integration with inline work item creation and updates
  • Automatic linking between code commits and work items
  • Real-time synchronization across team members
  • Flexible categorization supporting multiple team workflows

THE IMPACT:

  • Integrated work item management directly into OpenShift developer workflow/li>
  • Eliminated context-switching between IDE, browser, and project management tools
  • Created seamless connection between code commits and work items
  • Reduced average work item management time by 40% through IDE integration
  • Established design patterns adopted across other Red Hat developer tools

The Process

Before starting on the Application Lifecycle Management project, it was determined that the following areas would be need to be covered:

list of target users a user flow wireframes prototypes for user testings and feasibility

Target Users

Through discussions with Stakeholders and Project Management, it was decided that the target users would be set in tiers:

  1. General Users
    • those who need to add and interact with issues, update project assets, and interact daily - a mix of designers and developers
  2. Project Managers
    • organizers of work, set deadlines and release dates
  3. Administrators
    • control any integrations, add-ons, and access

Application Lifecycle Management flow

User flows
ALM workflow

Wireframes and Workflows

For each section of the ALM application, workflows and wireframes were used to identify possible user paths, as well as to strategize initial designs before moving on to high fidelity mockups and prototypes.

From Work Items to Development

Goals:
  • Communicates to the user that direct access to developing the Work Item is available in a single click.
  • Implementation is unobtrusive and implies navigation.
  • Location will not accidentally be clicked, allowing for enough real estate for line lengths and other meta data. The location of the integration should also imply moving forward.
  • Ordered by recommendation - require users to fill in one area before moving on.
  • As a button, it needs to have a prominent place yet not take the place of a primary button (in style).

Steps to complete the process

Step 1 of the ALM wireframes
Step 2 of the ALM wireframes
Step 3 of the ALM wireframes

Wireframes

This wireframe was created with call outs in order to communicate my thoughts around the design to anyone who saw it, but could not talk with me. Specifically, this worked extremely well when working with colleagues in other time zones where our working ours did not match up.

Wireframe of the work item to coding experience

From these workflows and wireframes, it was determined that additional questions needed to be answered:

  1. How do we handle accuracy between the linking of work items?
  2. If the work items has a fine name and line number, is the commit SHA also used to help identify the connection?
  3. Are we able to type the URL in a browser and navigate to the work item? (Does it have a unique link or is it randomly generated each time?)

Visual Design

After completing the wireframes and flows, a sample visual design was created. This design was created using the in-house design component library.

ALM workflow

Results & Impact

Adoption & Launch

  • Launched as core feature of OpenShift.io in 2018
  • Adopted by multiple development teams within first 6 months
  • Integrated with GitHub, reducing average work item management time
  • Expanded to support multiple project management methodologies (Agile, Kanban, custom workflows)

User Feedback

  • Developers consistently praised the IDE integration for eliminating context-switching
  • Post-launch surveys showed positive feedback
  • Reduced reported frustration with task management from "major pain point" to "barely noticeable"

Business Impact

  • Improved cross-team visibility into development progress and project status
  • Reduced time spent on administrative task management, allowing developers to focus on coding
  • Design patterns and PatternFly components I created were adopted across other Red Hat developer tools
  • Demonstrated value of deeply understanding developer workflows before designing tools for them

What I Learned

This project taught me invaluable lessons about designing for developers:

  1. Understand the workflow before designing the tool. By spending weeks observing OpenShift developers and understanding their daily routines, I identified friction points that weren't immediately obvious—like the cognitive cost of switching between tools and the importance of maintaining flow state.
  2. The best developer tools are invisible. Developers want tools that integrate seamlessly into existing workflows rather than requiring them to adapt to new processes. ALM succeeded because it met developers where they already were—in their IDE—rather than forcing them to go elsewhere.
  3. Developer experience is user experience. Too often, internal developer tools are treated as purely functional without considering the human experience. By applying rigorous UX research and design thinking to ALM, we created a tool that developers actually enjoyed using.
  4. Working on ALM helped me identify gaps in PatternFly for developer tool use cases, leading to new components and patterns that benefited the entire Red Hat ecosystem.

The success of ALM reinforced that internal tools and developer experiences deserve the same level of design craft and user research as consumer products—and that investing in that craft pays dividends in productivity, satisfaction, and adoption.