Company / IBM
Role / Designer working with a senior designer, a content designer, a researcher, a product manager, and 4 developers
Tools / Sketch, InVision, Whimsical, Slack, Box, WebEx, Trello
Timeline / 9 months
One of the key responsibilities of a DevOps engineer is to create a full- stack workload for the company they’re working for. In other words, they’re the ones setting everything up backstage, so that you can access Netflix or Slack or Zoom 24/7, with no interruptions.
However, as you can imagine, this is no easy feat. It can get tedious really quickly, especially when it involves setting up hundreds, or even thousands, of machines.
Thus, I was part of a project to offer support for Ansible automation capabilities on IBM Cloud.
Cloud computing can get complicated, so let me set the scene for you with an analogy.
If you own an iPhone or iPad, you’ve probably seen, or even used, the Shortcuts app. I think this app is totally underrated, because it has some really cool capabilities that most people don’t know about.
For instance, you can create a shortcut where every time you say “Hey Siri, I’m getting pulled over,” your phone will automatically send your location to a specified emergency contact, and start taking a video with the front camera.
Now, imagine if you had to do these things as you saw the red and blue lights flashing in your rearview. You’d probably be way overwhelmed, right? 😫
The Shortcuts app is a great example of how automation can really come in clutch in the consumer space.
Similarly, DevOps engineers get way annoyed with having to do certain tasks by hand.
However, instead of telling Siri to send their location or take a video, they ask Ansible (an automation tool) to install web servers and create databases.
Now, installing a web server or creating a database in the first place is no easy task. But imagine doing that up to hundreds of times?
Spoiler alert: it’s not very fun. That’s where Ansible really shines. It takes something difficult, and turns it into an easy and repeatable process.
Okay, now that you understand why Ansible is so great, you understand why it made sense for us to support Ansible on IBM Cloud.
Our goal was then to figure out what the Ansible experience would look like on IBM Cloud.
At the beginning of the project, there were two directions we could’ve gone in: aligning with IBM Cloud or aligning with Ansible. I explored both.
Whenever you create or buy something on IBM Cloud, you generally follow this pattern:
Now, this is great if you’re buying something (like a Kubernetes cluster or a virtual server) and you need to perform a transaction with the customer.
However, if we’re talking about creating something that’s free (like an Ansible playbook), it doesn’t really make sense to create things one way, and then edit things in a completely different way. This just ends up increasing the cognitive load for the user. In other words, it’s bad UX 🙅🏻♀️
Next, I looked at Ansible. Here, the experience of creating something is identical to that of editing something.
It’s like when you create a data table on Excel. When you want to edit that data table later on, you know exactly how to do it, because you had gone through the same process to create it.
So that was good. The user didn’t have to go through another learning curve to edit something.
However, I found that this flow gave little opportunity for us to guide the user through the create experience 🤔
So — you guessed it — I looked into combining the two approaches.
Although I had initially wanted to do away with the create page completely (so that we could have more consistent create and edit experiences), this would have been completely inconsistent with IBM Cloud’s existing create patterns.
Thus, as a compromise, I intentionally designed the create page to be as minimal as possible, so that the bulk of the create flow would actually reside on the resource detail page.
Moreover, I also had to figure out how to guide the user through the create experience (as opposed to just throwing them into the deep end and having them figure it out for themselves). So here are a few high-fidelity changes that I made:
And *drumroll please* all of these explorations and high-fidelity changes resulted in this final prototype.