DataSphere

Objective based management and data mobility across enterprise storage. Data virtualization and intelligence providing abstraction of storage devices, ease of management and storage optimization.

Team

I worked alongside 2 designers and 1 researcher. Worked with visual design contractor from time to time.

Role

Lead UX designer. I drove overall design strategy, timelines and end-end design solutions, including visual design.

Timeline

We released the first version of the product in 6 months. After that we delivered features in 3 month release cycle.

demo_imgs

Challenge

After building the first version of the product, Primary Data was finding it hard to convert the beta customers into paying ones. During our initial conversation with prospective customers, lack of trust emerged as a common theme amongst customers. While automation and data mobility were received well as value propositions, the shift in mental model was rather a big change for customers. Initial depoloyment highlighted that users could not track their file movements and were not particularily pleased by this. System did not provide enough information about the affect and reason for moving their files and all this seemed like a dark magic to them. They often posed us questions on why was a particular file moved, which most of the sales team did not understand either. Our goal was to build trust with users, so that they can deploy this software in their environments.

pd-15

Approach

A good place to start was to explore an already established trust model, a.k.a trust amongst humans, and gather similarities with our product. The goal was to define the guiding principles that will help us define features, workflows or other cues that will foster user's trust in the digital experience. We could use these principles for our interaction with the internal engineering and product teams to create alignment around trust. We divided the factors into four major categories: control, visibility, validation and troubleshooting. 

pd-131
Building trust is a journey

As in humans, building trust takes time and repeated interactions. The approach was to keep users in familiar grounds and gradually move them to full-automation, without suddenly changing the concepts and providing motivation for them to move to the next phase. An additional challenge was to convince the product management and founding members that customers get value proposition at each phase, to keep customers engaged and help drive the sales. These features would be disclosed progressively, but users could enable them sooner as they develop confidence in the system.

journey_pd

Design

Post the initial visits at customer location, the design team worked with the technical sales to setup the environment and observe issues first-hand. Once we analyzed the results, the team worked in a design spike with key product managers in the room. In this week-long design spike, we explored high-level designs that would help us develop trust with customers.

pd_3
Control

While the features in the first release provided users with control over their data stores, it changed the way users work with their data. We wanted to maintain that familiarity with their environment, so that users do not question the system's credibility. The change in their mental model is done gradually, keeping them in the driving seat all the time. To begin with, we only show them the value of mobility by highlighting the saving potential. As users look to explore it further, we provide streamlined flow to setup the mobility. We discovered that not all application data is equal and hence provided the ability to only choose the applications that aren't production. For the application users care about, they can choose not to move their data. This sense of control allows them to move ahead with mobility without the fear of loosing important data.

control
pd_1

No Mobility: Users get to see the benefit of mobility while planning capacity.

pd_2

Mobility Setup: Users can decide the applications they can optimize.

mobility_recommendation

Mobility Recommendations: Users get recommendations before the system actually move files.

Visibility and Validation

We combined visibility and validation as each visibility should provide appropriate reason for system's decisions. At a higher level, users needed to know amount of files that moved and wheather it affected the badwidth. If not, the user does not need to investigate further. During our discussions, we figured that the main reason for concern was moving important files because of pressure from other files. We highlight that throughout the process and provide way for users to look at those files and act appropriately. Validation of movement is provided at a file level. The expectation is that users would only do it for the most important files.

validate
dashboard

Dashboard: At a glance, users look at the amount of files moved in last 24 hours.

mobility_map

Mobility Graph: Users can look at the movement of their files and mobility reasons.

file_details

Mobility Details: To validate, users can look at the performance and compliance along with mobility.

Alter Behavior (Troubleshooting)

It is fine for the system to make mistakes, or take decisions that are not in user's liking as long as user can get out of it easily and make system realize the mistake. In policy based systems, the concept of troubleshooting becomes quite complex due to the interlinking between pollicies and the objects it's guiding. A small change in a policy can create undesired changes in all the objects related to it. So, any troubleshooting is de-centralized to individual objects. For the first release, we were only providing features to detect issues. Remediation could only be done by manually moving files around.

troubleshoot
volume_list

Storage Map: Users can look at storage or files to begin troubleshooting.

volume_details

Storage Monitoring: Users can get metrics on the storage to figure out the contention point. On these, they can drill down to each file.

Process

As any other organization, Primary Data came with unique challenges to implement design in the organization. The primary one being the geographically separated team for a startup. Design was key in driving the communication between backend, API, UI, product management and sales teams. I was responsible to define design and UI sprints in the process. I also drove a weekly status meeting between all the team leads in Primary Data.

sitemap
api_pd

UI-API Mapping: Mapping the APIs to the information shown in the UI to help implementation.

volume_workflow

End-End Workflows: Including error and corner cases to better explain workflows.

Impact

Primary Data gained 2 paid beta customers as soon as we provided visibility and validation features. The insight into mobility provided the trust that users were lacking. Eventually, the company was able to raise more capital for further development.

“…Now I exactly know where my data is all the time. I am no more nervous…” and “I have a better understanding of what you do…digg the new dashboards…”

pd_4_1

Learnings

Even if it's stealth, find ways to get vital user feedback early. Startups tend to focus on the pace of product development while often deprioritizing feedback cycle. Early feedback can avoid a lot of rework and help prioritize the features.

Design can play a central role in bringing together the product teams and align them towards a common goal. At Primary Data, I worked closely with the Engineering, PM and Sales teams to align on the priorities and implementation of the vision.

twt
med
lnk