A CoPilot Story (Pt 2): Our Product Creation Process…
…and Designing Deploying An Application Via A Docker Compose File
A CoPilot Story Table Of Contents
2. The Product Creation Process and Designing Deploying Via A Docker Compose
The Challenge
A great deal of the background of this project was covered in the previous post, however, in short we were tasked with creating an industry leading application and infrastructure management platform; which would incorporate Joyent’s cloud infrastructure (Triton) and container orchestration offerings (Container Pilot). As of this moment, we are releasing an experimental product that goes some way to achieving this goal, called CoPilot.
The Team
Being tasked with designing a visionary application and infrastructure management platform we knew we had quite a challenge ahead of us.
One of our earliest challenges was mapping out a team structure that would allow each speciality to focus on their core strengths and also encourage constant communication.
Working on such a technical product it was integral that the designer’s ideas were met with the engineer’s practicalities (and technical education) as well as the product owner’s requirements.
Our team structure was set out to make sure we covered the basis of a successful product team:
Over the course of the year project we generally had a team of 4–6 people with all the above elements covered; with support from Joyent in engineering and product owner capacities.
The Planning Process
Defining Principles
With such a lofty challenge it was important that we all had a set of principles (or values) that would inform our work on a daily basis. These principles ensure that the final product would have a degree of consistency as well as work towards accomplishing the larger goal.
Our principles were as follows:
- Fulfill the needs of different users/personas
- Compete with other product offerings in the market by providing a delightful user experience, as well as providing all encompassing functionality
- Be on the cutting edge of technology and design
- Keep everything simple, lean and constantly test and share our assumptions.
- Add elements of delight that would allow the product to go beyond simply allowing the user to accomplish their task
- Be open-source from the beginning
It’s worth noting that although some of these principles weren’t written down, sometimes without even agreeing, we all understood the importance of these goals in our work: they were imbedded in our daily culture.
Defining Narratives
A narrative (sometimes called an epic in agile development) was defined as a large body of work that could combine many user stories. A user story was defined as the smallest unit of work.
After analysing the existing Triton product and talking to Joyent about their plans for the future, we arrived at a total of twenty six narratives that should be incorporated into the product.
This is a great deal of work so we immediately set about prioritising these narratives. To do this we plotted these narratives on the below axis:
Narratives that end up in the top right hand corner of the diagram are the most important for the success of the product and are also not that difficult to design and implement. On the other hand, those narratives in the bottom left quadrant are those that are least important to tackle and also very difficult to accomplish.
There were of course some discrepancies between design and engineering in terms of an narrative’s placement on the axis, however the idea at this stage was to simply get an estimate: so a quick happy medium between designers and engineers was always achieved.
From this scoping exercise, it was important to then split up these narratives into Alpha, Beta and Growth release milestones for the team to work towards. The team came up with our prioritisation and the product owner from Joyent took this and consolidated this with their own expectations:
The above table was constantly referred to in meetings, workshops and standups to determine our progress towards releasing a product.
We also created a GitHub project board to track our progress where we plotted our confidence in terms of completing the designs for a particular narrative.
The Design Process
With the prioritisation table above it was clear to us what stories needed to be worked on first, and to explain our design process, we will use the narrative of deploying by uploading and writing a docker compose.
Although the next section is confined to this specific case study of a singular narrative’s progression through our process, the same design process has been used for all of the narratives in this project and those of high confidence are documented on the GitHub project board with specific case studies being explored in future posts in this CoPilot story.
Our general design process is as follows.
Defining Narrative
At this stage it’s important to get under the skin of the user and define the exact problem they are trying to solve with the product at this stage of their experience.
Our initial story title of “Deploy by uploading & writing a docker compose” isn’t incredibly informative. In fact, even the term “docker compose” would be confusing to someone outside of this design project (a docker compose is a definition of all services of the application).
However, a problem statement like the below clearly explains what this narrative should try and achieve for the user; and the Key Performance Indicator’s (KPIs) are great indicators in terms of how to measure the success of future testing sessions:
Every project deployed on CoPilot is configured with a docker compose. It has been outlined that a user should be able to upload a previously written docker compose and also write a new docker compose in the browser to complete this task. When completing the latter, it is important that there are ample educational components so that a novice can complete the same task as well as an expert.
Key performance indicators (KPIs):
1. The user gains an understanding of their application from the manifest file before deployment
2. The user is able to learn the technical details of the manifest file
3. The user can understand the next steps to deploying their application
4. The user is able to understand any errors in their manifest file
Identifying Relevant Personas
After defining the problem in greater detail we are now able to match this user story with some relevant personas. We match the narrative to the personas by analysing their needs, wants and worries and then how this matches up to the KPIs we have stipulated in the definition of the narrative.
Of our four personas, we decided this narrative was most relevant to the below two personas:
After analysing the above two personas, it’s evident that each one would require differing experiences to fulfill their goals, therefore, it’s important to keep both of these differing requirements in mind when designing possible solutions.
Conducting Background Research
from the outset it’s clear that a key design component of this story would be a text editor. This was now the perfect time to take some inspiration from other coding editors already on the market: that might inform our design decisions.
Research that was tied specifically to the product also involved the designers truly understanding the functionality of a Docker Compose file (as explained by my colleague Antonas here) and understanding the syntax of the code that would inform the design decisions.
Conducting First Workshop
At this stage it’s important to get members from across the whole team together to discuss and sketch possible solutions. We gather all designers, engineers, and when possible, the product owner. It’s vital that everyone involved with the project creates the shared understanding of the final solutions.
Our workshops are structured in a very similar fashion to the Design Studios described in Lean UX.
From our first workshop on this narrative we came up with the following sketches:
Creating Wireframes
From this design studio, the whole team agreed that a great way for a user to complete their manifest file would be an autocomplete drop down method. The next step was to create high-fidelity wireframes to put into a prototype and then feedback to the team and product owner to see if we were on the right track.
When designing individual wireframes it’s important that the design reflects that of a wireframe a fellow designer is working on; although we are still developing at the moment; we should still be focusing on building up one consistent product.
For this reason a shared UI Library was created that all design components would be taken from:
The three strands of our creation process: principles, narratives and UI library are the building blocks of our Confidence Framework that this post serves as an introduction to, and will be followed up with by a more comprehensive post at a later date.
Creating First Prototype
Once the wireframes were finalised in Sketch they were then imported into Marvel and the following prototype was created:
Presenting To The Product Owner
With a prototype in place, it was time to present the concept to the product owner from Joyent for feedback.
From this presentation it was highlighted that our current solution was too complex and that it needed to be scaled back to simpler linting/error correction features on products such as Sublime Text (as highlighted in our previous research).
Iterate Design
Further iterations were conducted with an improved visual design for the educational component banner and educational information was embedded throughout the manifest file as comments: handholding the user through the creation of a file as well as providing a much easier technical implementation:
User Testing
Throughout the design process we are constantly thinking about how we can increase the confidence in our designs. It’s much better to make mistakes on paper than once concepts have been put into Sketch (and it’s much better to make mistakes in Sketch then in code!). However, nothing increases our confidence more in a design than positive user feedback, and positive user feedback is defined by a testing session that shows us meeting the KPIs we had originally defined for this narrative.
After writing our testing script, sourcing users and running through the testing sessions, the following feedback was collated:
From this user feedback it was apparent that the manifest file did a good job in terms of illustrating to a user what application they were about to deploy. However, it could have been improved in offering some pre-packaged services (this then lead to the development of the Container Pilot Catalogue to be covered in a future post).
In this case study we are only illustrating two iterations of the design but in practice there are normally a great deal more. And in fact, we had at least five different wireframes created for this design here.
Technical Prototype
This stage isn’t always necessary to make us confident enough to commit our designs to development, however in this example, due to the designs relying upon a text editor that is extremely hard to model in a static image prototyping tool, a technical prototype was deemed necessary:
If you’re interested in how we split up our engineering tasks and how we conduct sprint we’ll post a link to a future post on this here soon!
Next Steps
Due to project demands, there wasn’t enough time to test the technical prototype so it was placed directly in the final product. With us launching CoPilot we are excited to gather user feedback on this narrative.
In Summary
This piece explains how we set up our team to create CoPilot. It also goes in depth into our design process providing reasoning behind our design decisions which lead to the final product.
Using the example narrative of deploying an application by writing or uploading a docker compose file this post also explains the design process utilised on this project. We only work at the resolution of our confidence, operating in build, measure feedback loops to gradually move towards a design that can be shipped (that we are confident will actually work).
A CoPilot Story Table Of Contents
2. The Product Creation Process and Designing Deploying Via A Docker Compose
