Metal as a service @Ubuntu
user research | IA | sketches | wireframes | Interaction design |
MAAS (metal as a service) is an application used to speed up and make easier server provisioning, provides automated hardware inventory, and allows for network and storage discovery and configuration.
For a large part of the time a spent working for Canonical | Ubuntu, I was the lead UX designer on Metal as a Service (also known as maas for short). I worked alongside senior stakeholders, outlining the product vision and roadmap; the engineering team, juggling technical requirements and understanding feasibility; and leading the UX design, working with a visual designer.
Following are a few specific examples of features I designed.
Machine summary
Machine summary is one of the most used pages within MAAS. It was designed a number of years ago and had not been updated for a while. As I was designing a number of separate parts of the application connected to features the back-end engineering team was working on, I realised that a large part of the information would be useful on this overview page.
The redesign of this page began though an informal discussion and a back-of-a-napkin sketch while discussing requirements for a number of other projects with some of the key stakeholders. Usually, I would have continued exploring options in a low-fidelity format through sketches, however, as I have been working with the responsible team for a long time, I knew that the best way to spark insightful discussion would be via high-fidelity wireframes that they can truly imagine being the “real” product. This was a feasible approach as all the elements I was using are part of the shared design system we use in Canonical.
Wireframes
In the first version of the redesign, I kept as much of the design as close as possible to the old in order to help the stakeholders focus on only the newly added network card. During this phase of the design I mainly collaborated with the networking specialists on the team, ensuring that we are displaying the important information about the physical layer of the network connected to the specific machine. We iterated a number of times on the content of the tables displayed.
Soon I started working on a new feature - the NUMA topology of a machine, and realised we need to add this data to the summary screen too. (I held a one-day workshop with another UX designer, a visual designer, and a few of the front-end engineers designing the way we are representing the NUMA topology, this is not discussed here.)
With this addition, the new information on the screen was suddenly significantly more than what we had previously, thus alongside the MAAS visual designer we began exploring different representations of all the information while keeping the informational hierarchy.
After a number of iterations and reviews with all the key stakeholders, including product and engineering managers, head of design, and the CEO, we arrived at a modern, minimalist design, allowing for all the key information to be available at a glance, as well as quick links to the relevant places where the users can dig deeper into the details.
A number of good interaction and UX patterns emerged through this work that are now proposed to be included as part of the Canonical design system - Vanilla.
Storage pools
In this project I was tasked with creating the UI for a new feature allowing the users to select which storage pool(s) they would like to use when composing a new virtual machine using the resources they have available.
This design task focused solely on selecting which storage pool to use, not on any other part of the form presented above.
user research
In order to thoroughly understand the problem I interviewed key stakeholders including the back-end engineering managers building the tool and the field engineers who use MAAS on a daily basis to create new open-stack distributions. Interviewing them allowed me to pin-point the user needs and understand the journeys they follow when using this feature. (They have been able to use the command-line interface (CLI) to perform the tasks previously.)
Additionally, I interviewed many of the Information Systems' Engineers gathering all the possible types of data that will need to be displayed as well as real-life information. This allowed me to ensure that all the proposed design would properly cover edge cases and exceptions.
sketching
As there are many ways to present information I decided to start by sketching a number of possible solutions visualising the data differently and putting an increasing amount of emphasis on that feature.
The sketches above present the data as first - a simple list, assuming that the user knows exactly what they are looking for and requires no help at all with making a decision, second - a complex dropdown, presenting the data visually, letting the user capture the most important information at-a-glance, and third - as a full-page grid, taking the most emphasis of the whole journey, assuming this is the most important decision they'll have to make.
These sketches were presented to the key stakeholders for the project, agreeing that the second and the third option would be explored further as they help the user in making the decision.
wireframes
As the application is built following a design system, moving straight to high-fidelity wireframes was quick, even though nearly all the elements were new and not part of the system.
The wireframes were then iteratively user tested and improved, aiming to create the most understandable view of the complicated data - allowing the user to quickly scan all of the information and make a decision based on the combination of free space, type of storage and its location.
The final design clearly displays all the pieces of information required, as well as providing informative explanations where a problem had occurred.