A CoPilot Story (Pt 5): Designing The Service & Application Catalogue

Continuing the story

A CoPilot Story Table Of Contents

1. Welcome to CoPilot
2. The Product Creation Process and Designing Deploying Via A Docker Compose
3. Designing Metrics
4. Designing Notifications
5. Designing The Service & Application Catalogue
6. Designing Versioning

Defining Narrative

In Alpha, the only way for a user to add services was by editing or uploading a new project manifest, however, this action requires in depth technical knowledge.

In Beta, we want to make the process of deploying an application more accessible by providing a library of services (or a container pilot catalogue) that a user can benefit from to easily add services to begin scaffolding their application.

Key performance indicators (KPIs):

  1. Less technically capable personas should be able to use this catalogue to confidently deploy an application they have an understanding of
  2. The user should be able to deploy an application rapidly using this catalogue

Identifying relevant personas: two personas were highlighted as important to this story, each with two very different requirements:

Persona Jorge
Persona Nicola

Conducting Background Research

To begin working on this narrative it was important to draw some analogies with existing products.

An interesting place to start was the one click apps utilised on Digital Ocean:

This feature on Digital Ocean provides users with an incredibly quick, efficient, easy way of deploying a selection of applications.

It was also important to consult the already existing inspiration for what would turn into the service catalogue, which was the Autopilot Pattern org on GitHub:

This existing org on GitHub provides a great starting point in understanding the potential future services and applications that could make up The Container Pilot Catalogue

Our product owner also provided us with a schedule of when new services would be added to the catalogue, as well as some high level information on each that could be used in our designs.

Drawing some initial conclusions from the research

Upon conducting some initial research, two things were now apparent:

  1. Users should be able to add entire applications, as well as services from the catalogue. It was identified that the addition of simply adding services would not be enough for some users.
  2. Consul should be a default service. All Container Pilot applications (which would specifically run on CoPilot) would require consul, and so unless a user explicitly states so, Consul would be added to any application deployed on CoPilot.
To understand why Consul is needed you can refer here (coming soon) to an explanation in a previous post.

First Workshop

To structure the workshop, the sketching sessions operated upon the assumption that the interactions with the service and -now- application catalogue should be on the Project Manifest page, and therefore, the Project Manifest page will have the following functionality:

  • Easy addition of an application from a library of applications
  • Easy addition of a service from a library of services

Furthermore, the below functionality, as decided upon in the Project Manifest Story the following functionality should also be present:

  • Paste application code in editor
  • Paste service code into editor
  • Manually code application in editor
  • Manually code services in editor

Now with the basic requirements set up, the whole team gathered round for some sketching sessions. A selection of these sketches are presented below:

Team sketches for the Container Pilot Catalogue

Creating Consolidated Sketch:

To make sure the correct wireframes were implemented, that reflected a joint decision making process from all members of the team, a consolidated sketch was settled on before committing to wireframes:

The consolidated sketch for the flow of the Container Pilot Dashboard, showcasing two different flows (it’s pretty confusing so if you want to try and deduce the different flows here it might take you a while!)

Due to the intricacies of this particular story, it meant that the team couldn’t all decide on a singular flow, hence the multiple options above. It was decided to mock up multiple flows in prototype form and then make a decision in terms of which was the best design.

That said, what all flows did have in common was delivering the user straight into the product after creating a deployment group, so the user could get a sense of the product’s functionality before creating anything: and spending money on deploying services.

Creating Prototypes

The first prototype presented the user with a call to action to add services, and then the application catalogue by default being shown.

The first prototype for the Container Pilot Catalogue, interactive prototype here

The reasoning behind envisaging the above flow was the idea that by removing as many clicks as possible to be able to deploy an application would make this process easier and encourage it. On the other hand, it was noticed that this put too much emphasis on deploying an application over adding services.

The second design had two call to actions, side by side, of equal weight, to add services and add applications:

This prototype was received more positively within the team, however it was highlighted there wasn’t enough information for the user to judge what they would expect on the next screen, and also the difference between each call to action (especially for more technically inexperienced personas) was not clear enough.

The third design added more educational components when added to the call to actions:

A video walkthrough of a prototype for the Container Pilot Catalogue. The interactive prototype is here.

The design team was gradually coming to a consensus that we were reaching a conclusion. But on the other half of the team, the engineers presented some serious misgivings towards the use of a modal UI component for the addition of services and applications.

The engineer’s outlined disadvantages of modals in terms of that they:

  1. Didn’t provide a state that could be shared
  2. Didn’t work well on mobile

This lead to our fourth design that didn’t incorporate modals:

A video walkthrough of a prototype for the Container Pilot Catalogue. The interactive prototype is here.

Surprisingly, (at least from the designer side of the team) it was felt that dropping the modal actually improved the flow for this story.

Next Steps

the last design should be user tested to validate this proposed design before it’s committed to production. If resources are available, a modal flow and a non-modal flow could also be A/B tested in user testing.

A CoPilot Story Table Of Contents

1. Welcome to CoPilot
2. The Product Creation Process and Designing Deploying Via A Docker Compose
3. Designing Metrics
4. Designing Notifications
5. Designing The Service & Application Catalogue
6. Designing Versioning
Like what you read? Give Alex Jupiter a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.