ShuttleOps

A no-code CI/CD platform to automate application delivery and management on the cloud.

Overview

I’ve worked on ShuttleOps for almost 2 years now, collaborating with a multi-disciplinary team of developers, DevOps specialists, and Product Managers alongside other stakeholders. I lead the design from the very beginning stages of the product taking it from an idea to a launched product going through several iterations to find a solution that meets requirements for our target users, aligned with the brand and business strategy. This case study outlines my journey working on complex problems, finding solutions, failures, and learnings throughout the process.

The problem we’re solving

Companies pushing for application delivery automation spend countless number of hours, integrating tools, writing scripts and troubleshooting problems. DevOps specialists work tirelessly to create solutions for their clients across clouds using several technologies which pose a whole new set of problems in terms of feasibility and in turn maintenance. This process is repetitive and, to large extent manual that requires attention and expertise in the field.

The main goal is to create a CI/CD solution that takes the manual parts of the process away, while giving the DevOps specialists the control they require over the application delivery customized to their needs. At the same time, making it easier for developers with lesser knowledge about DevOps in SMB’s (small and medium sized businesses) the ability to deploy their applications to the cloud, worrying about the goal and not the underlying technologies themselves.

Constraints

As every project comes with constraints, this product came with its own set of constraints at different stages, which gave me the opportunity be heavily involved and eventually formulate the design strategy for the product. Some of the constraints were

• For the first 5 months, our goal was to assemble an MVP with minimum functionality with requirements that were still being discovered. To deliver on that strict timeline, we had to base our design off the Google material design system so we could easily extract the functionality into the application and not get lost in creating pixel-perfect components

• ShuttleOps is an application for a spectrum of users that could be someone who had little to no knowledge about DevOps to a user who is a power user. To do that, we had to work in a way that allowed the application to be smart enough to default enough through best practices but at the same time provide a way for the power users to have the same control as they would in individual applications within one app

  
  
  

Research

Goal: Identify the current process for the user to deliver applications, what tools are involved, troubleshooting, the pain points, and any deal breakers in terms of functionality.

The initial discovery was kicked off with a combination of user interviews and rapid prototyping of components being brought into Adobe Xd. The user interviews included a broad spectrum of questions from basic deployment flows to tools being used for specific purposes in certain parts of the process. A few of the key findings from the process are listed below:

Impact: These findings steered the direction of the design towards a model where engineering was tasked to figure out how to pre-configure defaults by extracting information through plan files and for our team to create a flow that could allow the user to easily deploy their app with least amount of changes needed to be done through the UI.

Definition and ideation

As we gained clarity about the process and requirements through collaboration with our engineers and DevOps specialists we formulated that our initial designs were too automated for our general user taking away the control that they needed. This forced us to go back to the drawing board and clearly define a persona who we were targeting and create low-fidelity wireframes to have concrete requirements.

Refinement

As the product got more definition and we gathered more feedback from demo’s and user testing we explored different types of themes that would fit our ideas about what the product should project. Some of the explorations are shown below:

(Current) Final Design

The road up to this design was long and filled with learnings, which lead me to pioneer our company’s first design system its usage, adoption and maintenance during

This design contained four main sections that represented the main actions required for a user to deliver and manage applications in the cloud, namely Connect, Build, Deploy, and Manage.

While designing ShuttleOps, I lead the initiative to pioneer the design system for the product. It is currently being transitioned into ZeroHeight to document it better, provide more context to developers and anyone who wants to know how the components are being used within the application.

Challenges and compromises

ShuttleOps having started with just an idea and ever-changing requirements as we figured things out, it presented some challenges of its own. Listed below are some of the challenges that I encountered and some solutions

• To deliver an MVP no matter how perfectly we want a design to look everyone has to agree that form follows function and there has to be a trade-off between pixel-perfection and functionality of the product.

• The absence of technical requirements since the product was an integration of a number of platforms caused requirements to change quickly and often. It made it quite challenging to keep the designs up to date with any changes in the specific parts of the product that came about after the design was already done.

Takeaways/learnings

Working on this product gave me a lot of autonomy and freedom to try out new things and at the same time create a structure that I could work around.

• Not all designs get executed, even though they might fulfil all the requirements. Sometimes it just doesn’t fit into the context of the product or might not have the brand alignment it requires etc.

• Design systems are not merely a component library. It is an ecosystem, as you don’t only have to create components, you have to figure out how it translates to a developed screen and its adoption by the developers where it in reality becomes of value.

• User research holds high importance in defining the direction of the product, we need to understand who is our target customer what their needs are as we can’t sell a solution to a problem that a user does not have.