IBM DevOps Pipeline

A better way to manage and deploy app code

Project Details

Done for

IBM Bluemix


Winter 2014/2015

Main Collaborators

  • Design Lead: Matt Nesbitt {Austin, TX}
  • UX Designer: Rachel San {Toronto, ON}
  • Dev Lead: Curtis D'Entremont {Raleigh, NC}
  • Researcher: Chris Kelly {Raleigh, NC}

javadb pipeline test Pipeline   IBM Bluemix Devops Services1

A team with mixed technical skill sets can easily manage and deploy code for a web app with the DevOps Services Pipeline.

IBM Bluemix is a platform to make it faster, easier, and cheaper to develop and deploy modern cloud applications. Part of the work involved in creating a cloud app is building the code, testing it, and moving it between different server spaces – for instance, a "development" space for work-in-progress, to a "production" space for the public. This process is known as a "pipeline," because it's a bit like controlling water in a pipeline, by opening and closing valves.

I collaborated with my team in IBM DevOps to redesign the former Pipeline from IBM DevOps Services to one that would not only be more usable to new users and more useful for advanced users, but also better fit with the look, feel, and experience of Bluemix.

A little background…

Not every project at a big company makes it into the light of day – or more commonly, not until it’s seen a few rounds of refinements, sometimes with different designers handling the release than those who started the process. In fact, by the time I worked on the DevOps Pipeline, I’d been able to contribute to three mini-projects at IBM Designcamp, and one set of functionality for a product which has since morphed and changed in the hands of other designers.

The thing is, that churn is exactly as it should be, and that’s part of what I love about designing for the internet: whereas architecture requires sledge hammers or bulldozers to rewrite mistakes, or print graphic design requires a new press run to fix a typo, digital products just need vigilant eyes and a bit of grit to constantly improve what’s been designed and coded in the past.

The work I helped do for the DevOps Pipeline encompasses that beauty of the web and cloud software. For one, the Pipeline is a tool to make it easier for teams to continuously deploy new code to make their projects better. Secondly, the Pipeline itself already existed before I joined the project to revitalize it. However, it had some user experience limitations, and a visual design that wasn’t up to the standard of IBM Bluemix, the app-building platform this tool was being integrated into. But before laying those out – there’s some jargon here to clarify.

An important concept in modern software production is DevOps – a collection of practices and ideas that seek to make teams more efficient in building apps, and more able to support and maintain those products.

One set of practices within DevOps falls under the umbrella of continuous integration: continually adding new code to existing code to ensure everything is working, all the time, and ensuring that all code automatically tests itself for functionality. This way, when a piece of new code isn’t working, it is faster to identify and fix.

One challenge of continuous integration is that it can lack transparency to stakeholders in the organization who aren’t well-versed in the project architecture and code. Sometimes, a project’s leadership prefers to verify that each update is up to their expectations, so they can “pull the trigger” to release each new version. This slightly more-controlled approach is known as continuous deployment. To better allow teams to tailor and coordinate on their own unique deployment strategy, Bluemix needed to have a Delivery Pipeline. To best help all users, Bluemix needed this pipeline to help users visualize and control which versions of an app’s code were running in different environments, and how the code moved from testing phases to production – available to its end-users.

Luckily, IBM DevOps Services – another product – already had a pipeline interface, and it was being integrated into Bluemix. However, UX and UI improvements were needed to lift this pipeline to a place that could meet user expectations and add value to Bluemix. Some work had already been done by Rachel San, a UX designer in Toronto, and the dev team she was working with. They needed support to get it finished for Bluemix bigger batch of updates in March, so I was brought into the project in December to help further refine the designs, and to work with the dev team to get a great product implemented.

The Challenge


The previous major version of the DevOps Pipeline.

The previous product already had much of the raw functionality that was needed for Bluemix users. However, it was never given the design attention it deserved. For the redesign, we had three primary goals:

  1. Create a user experience that is simple and seamless, but configurable and forgiving.
  2. Make the system learnable for new users and efficient for advanced users.
  3. Experientially and visually introduce the IBM Design Language – including the unique Bluemix flavor of it – to make the interface more appealing and more accessible.

(And finally: work within time and technical constraints to get it all done as a team).

Dashboard IBM Bluemix

The look and feel of Bluemix.

The Process

The groundwork of the redesign had been laid when I joined, but there were still lots of tricky challenges and countless details to resolve before publicly launching, so I had plenty to sink my teeth into.

In-progress Pipeline Designs, as of early December 2014


Mockup from Rachel: the main pipeline view, showing a pipeline with parallel stages


Mockup from Rachel: a stage’s job configuration

Rachel San had worked with stakeholders and users to identify much of the content in the pipeline, but it still existed in the form of mid-fidelity wireframe/mockup hybrids. These didn’t yet align closely with the look and feel of Bluemix, and still had the opportunity for greater improvements in accessibility. Specifically, Bluemix is designed around a paradigm of mostly-white cards on a navy blue background, and IBM interfaces must meet AA standards of color contrast in typography, to ensure their usability for users with visual impairments. Taking these wireframes and refining their visual presentation was a my primary task in the project, especially in the first weeks of it.

The job of refining presentation was a lot more than sharpening corners and choosing colors, however. I worked with Rachel, Curtis, and with the feedback of my design lead, Matt Nesbitt, to ensure that all of the team was aligned on these refinements. I collaborated with these teammates to enhance the product usability, by adapting the content into mobile views and by well-considered adjustments to the placement and sizing of elements.

Later, as the product came closer to launch, we knew that to make it useful even to new users, we needed to introduce user-assistance (UA) for on-boarding, and during key moments. I got to work with multiple IBM writers to make sure this text was concise, informative, and fit our system well. To make it more useful to everyone, we also needed to consider notifications: confirmations of tasks completed, error alerts, and next steps. I designed the specifications for these instances of UA and notifications – again, starting with the design foundations of IBM Design and Bluemix, and with the continual feedback and collaboration of Matt, Rachel, and others.

Of course, some of the most important feedback on these designs was from users. To find the weak points in the flow of our pipeline configuration, the clarity of our UA text, and effectiveness of our error notifications, I was able to work with Rachel San and researcher Chris Kelley to run usability tests. At some points in the design process, we were hosting multiple usability tests a week, in a cadence of making mid-fidelity prototypes, testing, refining based on what we had learned, and then repeating.

Another major component of work in this project was in communicating the designs to our developers. That largely meant working with Rachel San to break up our designs into their key screens, then delivering those via web documentation, in a hybrid of redlines and style guide-style tables. I would have liked to create more in the way of HTML/CSS/jQuery prototypes for this, but we were delivering these designs more quickly than I would have been able to code up something so complex, especially with my coding skill-level as of 6–8 months ago. However, it did prove to be immensely helpful to have my solid working knowledge of the Chrome inspector tools. I could accurately see how the designs were being implemented, and offer specific CSS to resolve problems of sizing and spacing.


The Pipeline is a living product, so if you visit it today, it’ll be even better than it was when I moved to a different team, back in March. However, at that point, I was proud to be leaving it better than it was at the start, thanks in part to my fellow designers and myself, and also due to the terrific team of developers who were making it all a reality.

javadb-pipeline-test Pipeline - IBM Bluemix Devops Services 2015-04-17 12-20-21

Here’s the main page of the product, including a couple examples of error and notification messaging.

javadb-pipeline-test MyStage Config - IBM Bluemix Devops Services 2015-04-17 12-20-57

When users drill into the configuration of a stage, they can set the input, jobs, and properties.

javadb pipeline test MyStage Config   IBM Bluemix Devops Services3

The job load of each stage is scaleable, to allow for building, testing, deploying, and more.

javadb-pipeline-test Build Stage Build 1 - IBM Bluemix Devops Services 2015-04-17 12-20-45

Users can view the job history and logs of a stage.

15-php bmix test Build Stage Build 2   IBM Bluemix Devops Services

If a user needs to look through a lot of logs, they can expand the terminal view in the job history.

What I learned

This project was a deep dive into the world of software development. Through it, I learned about concepts like DevOps, continuous integration, and functional and unit testing. I collaborated with remote teammates every day, I worked with developers to align on a shared product vision and implement it, and I utilized brand guidelines for a pragmatic, functional UI.

I’ve since moved onto new challenges at IBM, but the knowledge and skills I grew by designing for the Pipeline continue to help me in my work today.