Working on my own with no previous knowledge of the storage management space, I was tasked with understanding current paradigms held by storage administrators and how to take 4 distinct screens and evolve them into a product with a clear information architecture with multiple navigation points.

Interviewing “Users” & Learning the product

Because the product did not yet have contracted customers, it was impossible to conduct customer interviews. As an alternative, the client and I conducted an heuristic evaluation of the latest QA build and interviewed product managers and sales engineers to learn the reactions of potential customers to the product.

Orthodoxies being flipped by the product's release into the market.

Orthodoxies being flipped by the product's release into the market.

We learned that this product was essentially upending the storage administrator’s job. Admins were wary of giving it full access because they were used to handling issues themselves.

MANAGING VOCABULARY

The product while reframing the current storage admin’s job, is also introducing new language to define (and redefine) core concepts. Rules to designate movement do not currently exist, but do have a relationship to the places where data is stored. The terminology is different according to the particular enterprise in question, but the concepts needed to be clearly linked in the product so that users could predict where settings could be managed.

Especially as an outsider, these distinctions were challenging, but using artifacts such as these workflows below helped me further articulate how the concepts and the interface needed to work together.

CRUD Workflows

With some understanding of terminology and product paradigms, I was able to drill in deeply into the CRUD (Create, Read, Update and Delete) workflows to understand how data was associated with each object in the system. This required dynamic and flexible data tables that included only the necessary information, but offered transparency on what was being done with each object. 

From Interaction Specs to Implementation

I worked closely with the client’s visual designer (also my core contact) and a contracted development team in order to implement the designs. 

Throughout this process, there were considerable changes throughout the designs to account for stakeholder feedback and in some cases my own misunderstanding. This process was invaluable in catching errors throughout the process and streamlining the interface so that the product could launch as soon as possible. 

For example, I had clustered the two categories related to mobility of files into a single area, but my client rightly pointed out that data movement may not be solely be the result of Objective rules, so while the concepts where related they were not exclusive to each other. We also reviewed copy to ensure clarity for users, though the product will be fully tested when in a beta stage.

FINAL DELIVERABLES

Since my work was iteratively shared with the agile development team, there was not a large hand-off at the end of the project. I was able to document the key interactions for implementation and review code in progress to ensure interactions where correct.

Visual design was also implemented at a later time to ensure that functionality was connected to the right APIs and usability was sound.




ds-final-deliverables.jpg
QA build of the product as of Aug 2017.

QA build of the product as of Aug 2017.