Great Product Design Starts with Empathy

Think of Delphix as the OpenTable for the data inside of your business. There are applications that your restaurant staff uses, and there are applications that serve your customers with fresh data that’s critical to your business’ success.

Like a restaurant, your back-of-the-house staff—the database administrators, solution architects and security officers—uses a set of tools that helps them clean and prepare the data. For your customers—who are the developers, QA teams, and BI analysts that consume data to build apps and to run big-data analysis—all they have to do is make a reservation, show up and their data is ready to go.

Over the past two and a half years and a series of more and more frequent product releases, Delphix has seriously invested in the user experience of our software to realize this kind of vision. We’ve charted a course that breaks from the legacy of enterprise software, which used to say: “Our users are engineers like us. If we understand how to use our products, they will, too.”

Enterprise software is built to solve complex technical problems. To avoid passing that complexity onto our users, we need to remove as much of it from our user interfaces and APIs as we can, and that’s exactly what we’re doing.

Our Experience Design team applies a set of predictable and repeatable design principles to guide us through the process of understanding customer problems, crafting a vision and collaborating with engineers to build solutions that help crystalize the value of Delphix technology.

Great Design Starts with Empathy

The most important art for designers to cultivate is the art of listening. There’s always a tension between building software and using it—what the business is trying to accomplish versus what customers need. We design and engineer our software the way we think it should be used, but our customers will use it however it makes sense to them.

The empathy designers gain from listening to both sides is the special sauce.

Here’s a before-and-after view of one of our signature screens. It shows the Timeflow of snapshots taken of a virtual database (VDB).

Timeflow Before, ca. 2017

This earlier Timeflow interface was action and snapshot-centric. But if you look closely, the snapshots here all repeat the same information about time zone, data type, source DB cluster and DB cluster version. And our users told us it wasn’t important.

Instead of all of that repetition, what if we could present a UI that truly meets our users needs? Listening to customers and our technical services teams, we learned what they really needed from the experience: paths to navigate to an environment or between parent and child datasets or to see how big a VDB is. Adding this context gave users the confidence they need to take the right action.

Timeflow After, ca. 2018

“The new design has more information, specifically with Timeflow providing usage summary and parent child details.... Very useful.” -Nitin Bhutada, Alliance Bernstein

The Power of Desire Lines

To redesign Timeflow, we also had to untie a Gordian Knot that is at the heart of database technology: the knot made by production states, virtual copies, refreshes and where they all live on the time-space continuum. It’s quantum-level complexity.

We had to strip everything in our existing UI down to the core concepts, and then rebuild it to suit the kinds of paths users told us they needed to get their work done. This is where desire lines figure in. Take a look at this picture.

Urbanismos Amables: Caminos del Deseo [Source: The Ajovin Post]

Think of the brick walkway on the left as the UI we had two years ago, and the dirt track where the man is walking as the direction we needed to embrace to make our software work for him. Of course it’s not just for him. It’s for our thousands of other users who need to follow that path, too.

We learned that one customer provisions a set of VDBs and doesn’t refresh them for 6 months to freeze a state of their data at a particular point in time. At the same time, they put another set of VDBs through the paces of an application development cycle and manually refresh and rewind them tens or hundreds of times during that same 6-month period.

Meanwhile, another customer automates all of their refreshes and orchestrates their development pipeline with Jenkins—think data as code. They rarely use the UI to refresh VDBs.

How different could these scenarios be? The key is that these very different customers refresh their VDBs from the latest snapshots on their source DBs. In fact, that’s what customers do 80 percent of the time when they refresh their data. This feedback informed the way we redesigned the VDB refresh workflow to optimize for refreshing from the most recent snapshot, and it will be the first VDB operation that we will enable in our upcoming central management solution.

Refreshing a VDB in our new UI

“This GUI is 100 times better than the older one.” -Ruben Catarrunes, Credit Suisse

Sketch, Share, Iterate, Build, Test, Release, Learn...

We’ve also retooled our design and development processes to include improvements and new features into more frequent releases. With our major 5.2 release, job number one was to move to a modern front-end development framework, with a few other high-value areas like Timeflow and Storage Capacity as must-haves. Now that we release every 8 weeks, new features don’t have to wait long to see the light of day.

Here’s an example.

The Datasets Panel in Our 5.2 Release and Improved in Our 5.3 Release.

Customers told us that our icons were hard to understand, and that the hierarchy of groups and datasets was unclear. We reinterpreted the iconography so that dSources are solid and two wave lines project data, whereas VDBs look lighter weight and portable. And we made it clear that datasets belong inside of a group by indenting the icons to reinforce the hierarchy.

As we build our first SaaS offering, which will unlock the power of centrally managed Delphix estates from a single user interface, we’re even more quickly going from initial design sketches to mockups to code. From a whiteboard sketch like this:

…to a visual mockup that developers use to build the feature:

…to a working product interface that we can share live with customers to get feedback:

… is a process that’s gone from months of design, development and release to weeks. This is the result of a major effort in Experience Design, Engineering and Product Management at Delphix, and we’re all excited to get the results of this transformation into your hands to use our new product experiences—and continue the cycle of learning.

Design is a conversation and a collaboration, followed by another conversation—and so on. It’s a conversation where we listen to our customers and learn how Delphix can support your business cases. It’s a collaboration where we include customers in our design process and work together to resolve unmet needs. The ultimate experience for a designer is when a customer can point to our user interface and say “that was my idea”—then we share in each other’s success.

Read more about our latest release of Delphix 5.3, and learn how the Delphix Data Platform provides an enterprise-wide approach to data masking and data virtualization capabilities that can help sync, mark and deliver your data securely and rapidly.