Press "Enter" to skip to content

Case Study / User Research to create tools for DevOps

Overview
From 2002 to 2012, Electric Cloud grew to moderate success in providing tools for making enterprise software. From 2013 onward, they wanted to claim a share of the growing market for Continuous Delivery solutions.


Participants
From its relationships within a loyal customer base, the Product Management team engaged to understand needs and pain-points that emerged while adopting new DevOps practices.


The Challenge
Companies that build and maintain software as their core product and services, are cautious with disclosing information about their operations. Their activity in using Electric Cloud’s tools were guarded behind on-premise installation. Information would be obtained through methods of direct inquiry.


The Approach
Our user research practices evolved in 3 phases in an on-going process over 6 years, drawing input through a Customer Advisory Board, and a monthly Field Design Partnership with the Solution Architects, and the Support Team – those in closest contact with the users.

The UX design function was as observer on the advisory board, and the driver of collaboration with the field.

My role: Observer. Facilitator. Presenter.
I visited customers’ work environments, conducted interviews, and sat in on the PM’s inquiries, as well as the advisory board sessions during which customers shared insights and made requests.
I scheduled design partnership sessions with the field, presenting concepts and early iterations of new features. The feedback validated, or course-corrected design in progress.


Implicit biases
As an enterprise software company providing a tool to deliver enterprise software, there can be a tendency to assume problems are commonly understood.
The counter balance to this bias is recognizing that each organization has a different culture, capabilities, resources, idiosyncrasies, and approaches.


•••• Attitudes

  • Pride in running a tight ship with few incidents during releases
  • Conservative towards change from fear of putting systems at risk
  • Honest in self-examination, and open to improve

•••• Culture

  • Regimented to operate within set roles and responsibilities
  • Collaborative, yet territorial by domain expertise
  • Communicative within a framework of authority and team structure

•••• Top Pain-Points

  • Misaligned values between teams
  • Teams accustomed to tribal silos
  • Context change using disparate tools
  • Lack of visibility into overall activity
  • Paths to drill-down into solving errors

•••• Summary of findings

  • DevOps is first a cultural change within the organization
  • Value is perceived in a tool that helps transition incrementally
  • Cost of training mitigates adopting new features
  • Teams create workarounds that challenge intended UX

Outcome
Here are some examples of features and improvements that were developed from our initiatives. Some were synthesized from broad requests, while others were specific to habits and pursuits of optimization.

Filter Errors
Inquiries brought to attention the need to isolate errors during deployments more easily and the capability to drill down to their origin.

Change History
The greatest concern DevOps teams expressed was not knowing who had made changes, what exactly was changed, and when.


Service Catalog
Generally authoring tools start users from ready-made templates. In our case, this represented a broad range of objects, services and integrations.

Autonomy to grow
Users also wanted the autonomy to implement their templates beyond OOTB options. We responded with editors to create catalogs.


Dashboards
Even while offering capabilities ahead of the curve, sometimes users simply requested features they’d seen in a competing product.

Create. Read. Update…
Dashboards to view the system’s activities was not a difficult request to fulfill. We offered functionality to author them.


Role based navigation
Users communicated that the comprehensive functionality for Dev and Ops teams, as well as Release Management was overwhelming.

Display UI by Persona
The Solution Architects also suggested that displaying only the functionality for specific POC use cases would simplify how they present.


Scale Releases
From customers’ feedback, we met the emerging needs to flexibly scale releases with capabilities for multiple teams to add their pipelines.

Maintain visibility
To uphold the attribute of visibility, we had to find a way to display the progress across all the stages of the pipelines added to a release.


Related case studies

Consumerize Enterprise UX
DevOps Web Application

Core Function UI redesign
Release Automation