Illustration and brand identity by Matt Heilman


Storage Service Configuration

Service configuration is one of the more complicated parts of the Castle experience. It's also a required step in getting the cluster to a usable state.

Block and Object Configuration

I wanted to start off with a few high level sketches to get an idea of where Block and Object storage configuration might overlap. After a few revisions it was decided that we would split up this task and I'd move forward with block configuration.

Block Configuration

This sketch was my first step (after research) into designing a storage block configuration experience. I wanted to show the major functions of this feature together at a high level.

This is where we started to dig a little deeper into creating a volume and understanding relationships between ISCSI targets, clients, volumes and volume groups.

A lot of what we're doing at this point is just trying to figure out the amount of work this feature might cost us.


I built this working prototype to help me communicate the block setup UX to the engineering team. In my experience, interactive prototypes and demos are a much more effective way to present UX than static wireframes.

View Prototype

Visual Design

The prototype was effective in helping us make some decision as to what we could actually ship in this milestone. One of the big cuts was the client manager along with 1:1 client to volume connections. Although users could technically still create a volume within a group for a single client.

Invision Demo


Because you don't want just anybody to have access to your object store data.

As a user, I need to upload my SSL certificate through the Castle UI.

In the first sketch we explored two cases to solve for:

Since this was going to be a service level feature, it was pretty easy to decide that it should live in service level settings.

But what about adding this feature to service configuration? After further discussion we agreed that it made sense to add this feature to the service configuration UX.


Now that we were happy with the user flow. I was able to move forward with wireframes. This is where we define copy, interaction design, error cases and layout.

Uplaoding an SSL cert to a working object store service.

Uplaoding an SSL cert during service configuration.

SSL toggle

Visual Design

I used sketch to finish off the visual design along with Invision plugins to communicate final design requirements to engineers.

Invision demo

First Run (Cluster Setup)

This section will take you through my process of creating a first run user experience for Castle v1. A cloud based storage solution funded by Quantum Corp.

As a user I need a way to set up my Castle cluster.

This user story was the starting point of designing this feature. Step one was to do some research on first run experience. Here a few helpful resources I found to give me insight on how other people are solving this for their particular product.

An early high level flow showing some of the steps we might want to consider in the setup process.

Whiteboard Sessions

The PM and I went to the whiteboard to get a high level view of what we thought might be the basic requirements in the setup process. We then shared these sketches/flows with the lead engineer to get recommendations on any possible features or steps we may want to consider adding to the setup process.

As we moved forward with collaboration we started adding the features recommended by engineering. This gave us more clarity around what the requirements were going to be for this feature, in this milestone. This also gave me the opportunity to experiment a little bit with the layout. In this example I was considering a contextual experience.

In this stage of the design process we were able to identify areas of more complexity (cost) in the setup process. For example, password recovery was going to need to become its own separate and we still were not sure if we were going to require a license key from users to complete setup.

License Key

A late entry to the list of requirements for the setup UX was the user license agreement upload. There were 2 methods we wanted to look at. A file upload method and a copy paste method.

Because the license terms dictate the number of nodes a user can add to their Castle cluster, we needed to take another look at the "select nodes" step as well.

As we dove deeper into this experience, we made a decision to go with a file upload UX instead of the form upload one. We also took a look at how we might present the license details during this process as well as error cases.


With the bulk of the UX decision-making done (hopefully), I moved to higher fidelity with wireframes. This is where we start to define error cases, copy, interaction design and layout.
Invision Demo

Unfortunately, this is where my work on Castle comes to an end. As Quantum struggled to perform well as a company the new CEO decided to close the Castle offices on February 9th 2018.

Password Recovery

A very common problem with tons of existing solutions. However, most of those solutions assume there is an internet connection. But due to the nature of setting up brand new clusters, we also need a user-friendly solution to an offline recovery experience. I began my research by looking at O.S. recovery experiences and went from there.

As a user, I need to be able to reset my password

This is my initial sketch for the password recovery flow during login. Here I'm trying to solve for an online or offline case. While working on this I started thinking about other areas of the app where a user might want to update or change a password. I thought there might be areas of overlap in those two experiences so I sketched that out to get a higher level view at it.

During the review of this sketch more questions arose around user management than password recovery. The outcome was that we needed to create a new task specifically for account management and possibly prioritize it for our next milestone.

The Castle Design system

During the development of Castle we agreed to switch to Sketch as our primary design tool. This opened up an opportunity to update the current design system so that it would work well with the advanced features in Sketch.

Atomic Design

My first step was to reorganize the current pattern library using the atomic design method. Here is a blog post by Brad Frost on Atomic Design. He literally wrote the book on it.

While migrating assets into Sketch I decided to leave the elements we weren't currently using behind. Our current pattern library was full of clutter and I wanted to make it easier to find design components.

Sketch and Nested Symbols

We needed a way to control repeating assets so we could update them quickly. Sketches' symbol overrides feature gave us a lot of control and flexibility. We could now propagate changes across multiple artboards as well as customize specific states of those symbols quickly. The overall nature of symbols worked great with the Atomic Design system. A designer can now drag individual symbols from the UI kit onto their file and get all the functionality of those symbol overrides.

Moving to Sketch optimized the design workflow as well. Designers could now open the sketch file, add the components they would need for their design to their design file. All the symbols contained in those components are then added to the users file automatically. Another win with Sketch and the Invision plugin is that we no longer had to spend times creating redlines manually. Since sketch is built on HTML, CSS we could now output sketch artbords to a file that a front end developer could inspect and get the necessary layout information needed.

With this project I learned how to use the advanced features of sketch and would consider myself at an expert level with this tool.

Download the Castle UI kit v1.2

Disk and Node Management

Node Management

Disk Management