Redesigning the Data Display

Okera provides a central place for companies to manage, protect, and analyze their data. In order to do this, users first need to find and view the relevant data objects (e.g. tables, databases). In 2020, the Okera Customer Success team was receiving many complaints from customers that the existing data page did not allow them to take certain important actions and did not display data in a clear way.

I worked closely with customers, and with the Customer Success and Sales teams to redesign Okera’s main data page. I developed a new page with expanded capabilities and an improved layout, resulting in greater user satisfaction and a reduction in complaints.

A little background on data objects in Okera.

In order to manage and protect their data in Okera, users first need to import it into the Okera catalog.

Okera stores imported data as datasets. A dataset is a specific collection of data, e.g. a table containing information about employees based in California. 

Each dataset in Okera belongs to a database. A database is a grouping of multiple related datasets, e.g. multiple datasets containing state employee information might belong to an overall ‘US employee information’ database.

Datasets and databases are both considered data objects.

A wide variety of users may interact with datasets and databases in Okera, for example: 

• Administrators import and organize data in Okera. They create and maintain databases which store imported datasets. 

• Data owners oversee the quality and security of a given database or dataset. They need to manage access to both databases and datasets, and they need to ensure these data objects are tagged and named correctly. 

• Data analysts derive business insights from data. They need to find and view the data contained in datasets. 

Okera needs to provide a way for all of these different users to perform their data-related tasks in the UI.

Problem Discovery

Users were confused and frustrated by the existing solution for displaying data objects.

In 2020, Okera displayed all imported data on the ‘Datasets’ page:

Despite being one of Okera’s oldest and most important pages, the Datasets page was not popular with users. Representatives from the Sales and Onboarding teams found that new customers often had difficulty using the page, while the Customer Success and Product teams heard frequent complaints about it.

These complaints and points of confusion fell into three general categories:

1. Users couldn’t see or take action on databases.

The Datasets page was - as its name suggests - exclusively focused on datasets. Users could edit, organize, and create permissions on datasets, but couldn’t take any of these actions on databases. Users couldn’t even create new databases or view database metadata on this page - they had to instead use the SQL Workspace, which required specific coding knowledge.

This was because the page had initially been developed with data analysts in mind. Data analysts don’t typically interact with databases directly, so developers had not bothered to include databases as interactive objects. As Okera grew, however, it was quickly becoming necessary for users like data owners and administrators to view, edit, and create new databases in the UI. 

For example, following the release of the new Permission Builder, data owners began asking Okera’s Product team when they would be able to view and manage database-level permissions in the UI. The Okera Customer Success team also heard frequent requests from administrators for the ability to create and tag databases in the UI:

2. Users were unsure about object hierarchy.

The Datasets page showed all imported datasets in one long list. Users could filter this list by database, but had to read the list somewhat closely to tell which dataset belonged to which database.

Additionally, new customers who were not well-acquainted with Okera’s model had a hard time understanding the database/dataset hierarchy because the UI did not visually clarify that databases contained datasets. 

The Sales and Onboarding teams reported that many new users struggled with understanding what a database even was and how it related to datasets:

This issue affected all users, including data analysts who needed to understand the broader context of the data they were working with.

3. Users were frustrated by poor spacing and information density.

The Datasets page contained large amounts of complex information such as dataset schemas, but this information was displayed in cramped spaces where users had to scroll in multiple directions to fully view it. 

When users clicked on a dataset, a pane appeared showing all dataset information. The list of datasets on the left remained persistently visible so dataset information was restricted to a fairly small area. This meant that it was often difficult to fit all dataset details into the available space and a lot of information was truncated.

In feedback sessions, users of all roles often mentioned feeling frustrated by having to work in such a limited space.

I decided to redesign the Datasets page to address these issues.

As a result of these problems, users often had to complete their work on pages other than the Datasets page, which slowed them down and made their work more error-prone. Additionally, user confusion meant that the Sales and Customer Success teams were inundated with basic questions that could have been answered by a clearer UI.

After hearing about these issues for several months, I sat down with my product manager to discuss possible solutions. We decided to build a new Data page that would display both databases and datasets. This page would…

• Let users take the same actions on databases that they could on datasets

• Prioritize information density

• Visually clarify the object hierarchy

Design Process

I started by gathering requirements.

My PM and I began by mapping out all of the key user flows and where they were breaking down on the current page.

Based on these flows, we made a list of requirements for the updated page. We decided that the page needed to retain all of its existing functionality (e.g. the ability to search for datasets across all databases) in addition to incorporating new functionality (e.g. the ability to create a database in the UI). We also decided on some design requirements to tackle the spacing and hierarchy issues.

Our final high-level requirements were:  

• Users can view databases and their details

• Users can take key actions on databases (i.e. create, delete, edit)

• Users can search for a given dataset or database

• Users can easily understand object hierarchy

• Users can view all object details without scrolling horizontally in 95+% of cases

For each major requirement, we worked closely with users and internal experts to iterate on and test various design options.

I developed some initial options for viewing databases.

My first step was to figure out how to display databases, as well as datasets, in a clear and intuitive way on the page.

I held a brainstorming session with my product manager and several engineers. All participants brought examples of other applications that displayed some type of object hierarchy where users could see details and take actions on each object. We discussed what worked and what didn’t about each design. We then sorted these example applications into groups based on the way they organized objects. I then simplified these groups into 2 major models to be explored: 

• The list model: In this model, the first layer of object hierarchy (databases) are listed on their own page. Users can click into a database to access a new page listing the datasets within. However, in doing so, they lose the view of the full list of databases.

• The column model: In this model, users can similarly click into databases to view the datasets within, but a sidebar showing the full list of databases and datasets is persistently visible on the left side of the screen.

I then designed some low-fidelity mock-ups for how the new Data page might look with each model:

After further testing, I decided on a model.

My team was divided on which option to pursue, so I decided to test these concepts further. I made semi-interactive prototypes of each design and organized calls with 3 users and 2 internal experts from Customer Success. I had participants browse databases and datasets with one prototype and then the other, and asked them which model they preferred and why.

3 out of 5 participants preferred the list model because of the additional space it provided, and because browsing through databases and datasets was not a priority for them; they were instead more likely to just search for the dataset they wanted.

One user pointed out that the column model would be worse for their use cases because they only worked with 2-3 databases, so the database column would be mostly empty anyway. This was a case I hadn’t considered because I’d been working exclusively with dummy data. I made an additional mockup of the column model with actual customer data and found two interesting things:

• The columns still took up too much space. The columns took up more screen space than I originally anticipated. I measured the amount of space required to show at least the first 10 characters of database and dataset names in the columns, and I found that, especially at lower screen resolutions, the page would suffer from the same spacing issues as the existing Datasets page.

• It was very difficult to tell objects apart. Customers often had strict naming conventions for databases and datasets. It was common for object names to begin with multiple prefixes that would be repeated between similar files (e.g. two separate datasets could be named ‘sales_usa_secure_2019_lorem’ and ‘sales_usa_secure_2019_ipsum’). This meant that the preview of database and dataset names in the sidebar typically got cut off so that it was very difficult to differentiate objects.

Because of these findings and overall user preference, I decided to adopt the list model, with the possibility for including an optional column view down the line if users requested it.

I added new tabs and buttons for database actions.

Now that I had a working design for displaying databases, I moved on to database actions. There were three general categories of data object actions - creating, editing metadata, and adding permissions to a data object. Only databases could be created.

I kept these updates in line with Okera’s existing paradigms. For editing metadata and adding permissions, I maintained the Details and Permissions tabs from the old page and gave databases their own version of each tab. I then put a ‘Create new database’ button at the top of the main page, following Okera’s style for ‘add new’ buttons.

I introduced a new search bar and filters.

The former page had a simple dataset name search, but users needed to search for both databases and datasets on this page. I developed two options for how this might work:

• Two separate search bars: One search bar for datasets and one for databases. The benefits of this approach we

• One unified search bar: One single search bar for all objects. This would
  

xxx

I tested this design to ensure it was meeting requirements.

I updated the page according to user feedback.

Release & Design Iteration

We released the new page in 2020 to positive feedback.

Users wanted to see even more functionality on this page/

Our existing filter pattern was too limited, so I redesigned it.

I took the opportunity to standardize patterns more broadly.

I developed some design options for data object statuses.

I landed on a design with simple alerts.