A CoPilot Story (Pt 5): Designing The Service & Application Catalogue
Continuing the story
A CoPilot Story Table Of Contents
2. The Product Creation Process and Designing Deploying Via A Docker Compose
5. Designing The Service & Application Catalogue
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):
- Less technically capable personas should be able to use this catalogue to confidently deploy an application they have an understanding of
- 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:
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:
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:
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:
- 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.
- 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:
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:
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 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:
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:
- Didn’t provide a state that could be shared
- Didn’t work well on mobile
This lead to our fourth design that didn’t incorporate modals:
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
2. The Product Creation Process and Designing Deploying Via A Docker Compose
5. Designing The Service & Application Catalogue
