Rubrik Polaris

Rubrik has been disrupting the backup and recovery space quickly and successfully since 2014, delivering instant application availability for recovery, search, cloud and development. 

Here was our approach:

• Review product requirements & define design process
• Visit customers & define our persona
• Make user-flow diagrams
• Create information architecture
• Sketch, wireframe and build working prototypes
• Research and design our visual system
• Validate
• Establish and evangelize our design system

This initiative kicked-off around the same time I started working at Rubrik, and thought there was no better time to schedule some customer visits and meet the people I'd be designing for. I traveled to New York, Boston, and also set up remote interviews with the design team. Participants also took a survey I made asking them about the products they use, what their routine looked like, what computer and browser they used at work, and so on.

I ran an empathy-mapping exercise to externalize all the data we had collected thus far. A person emerged from this exercise and I was able to build our primary persona profile. Benny is now referenced in most design critiques, product meetings, and has been widely adopted by our product and engineering teams.

We identified key requirements that had to be included to build the MVP, then mapped out user-flows based on those requirements (a lot of white-boarding and scenario workshops were involved). 

To ensure that our new product was scalable, I created a sitemap to visualize our future information architecture for when the product is fully realized. With this sitemap, we were able to define our MVP and, more importantly, see how it should scale.

MVP templates

Once we scaled-down our product for the initial release and fine-tuned our roadmap, I templated our site-flow to better visualize the MVP. 

Customers preferred to use Rubrik the same way they would use a banking application. They want to log in, see what they need to see, and logout. With that in mind, we prioritized starting our prototyping phase with the dashboard/overview area, having a goal of presenting the right information as clearly as possible.

Our product team's hypotheses for the dashboard was that the user would like to see aggregated cluster data, aggregated cluster capacity, and cluster location. To validate these hypotheses, I conducted virtual card-sorting studies and a desirability analysis with a group of customers, to determine the following: 

• What value does aggregated capacity bring to a backup admin? Is it useful?
• We know maps are cool, but why would a backup admin need one for their clusters? 
• What are the goals of the people using Rubrik every day and how can we optimize for that?

Results of this study were very interesting. Turns out the backup admins using Rubrik everyday found aggregated data and capacity useless. They did think the map was “cool,” but not actually that useful. Most of them stated that they could see their managers making use of this aggregated view and would like it up on a monitor at their office. All of them plainly stated that they wanted to be able to log-in, see the health and activity of their individual cluster, and log back out. 

These findings led us to needing two views; a view showing individual cluster health for backup admins, and an aggregated view for their managers. I noticed a parallel in Invision's enterprise application that inspired me: If you log in as a contributor, you land on the page you care about: your Projects. A contributor will still have access to the enterprise dashboard, but it's not the first thing they see. We decided to try that model. So if a backup admin (our primary user) logs in, they'll land on a page showing individual cluster health. If a manager logs in, they'll land on a dashboard with aggregated cluster data and that "cool" map. (See design in Visual system) 

Prototyping \ Activities

To improve the activity feed, we were able to take learnings and research from our existing product and use them as baseline requirements. I worked closely with product and our sales engineers to understand what wasn’t working with our existing feed, what was missing, and how we could improve it for this product. 

Key objectives:

• Expose more information to the user when it is appropriate and helpful 
• Allow the user to troubleshoot failed jobs and make it meaningful/gratifying
• Improve activity item find-ability 

Challenge: Scope. A lot of features were de-scoped for our Beta and GA releases in order to deliver a product as soon as we could.

Explorations

While we were prototyping, we also began our visual system research. Here were some of our tactics:

• Researched our competitors' solutions to see what was working and how we could differentiate ourselves
• Used our persona research to gain inspiration from the products and brands our users told us they use
• Sent around an internal survey to our product, engineering, and marketing team to include them in the designing of the face of the product.
• Interviewed and surveyed all of our stakeholders to take advantage of their domain knowledge as well as involve them in the design
• Collaborated with marketing in developing a mood-board to level-set our expectations

Final Designs

Using our staging environment, I reached out to five customers asking if they would be willing to participate in a usability study. We wanted to test our "create a report" flow and see if the information on the cluster list page was easily digestible. From this study we were able to make immediate improvements, caught two major bugs, and added the larger-scoped feedback to our roadmap. 

I worked closely with our engineering team as well as the design team to create and maintain a scalable design system everyone could benefit from. 

I ran an Atomic Design workshop where we took an inventory of our elements using our high-fidelity designs, and categorized them by atomic level. From there we critiqued what was there and worked as a team to unify our patterns.

After the workshop, I put together a Sketch file that housed all of the components we had source files for, so the members of the team could start putting them to use. Using an inventory list we cultivated from the workshop, I have also started writing a Design System: Component Guidelines document to cover accessibility guidelines, usability guidelines, explain usage, and provide any additional specifications that the design and engineering team might need to sustain consistency as the app matures. 

It might still be in it's infancy, but the design system has been well adopted and appreciated by many teams. I am proud to say that every element, shade, and decision in this design system has been made with purpose and care.