With General Motor's transition to the cloud, much of the company’s data has began migrating from local servers to the cloud. Some data will remain on-prem most will move to different cloud providers. Our team needed to figure out the challenges associated with this transition and create a tool to help users find the data they need. For this project, I worked with two other UX designers. I created the project from ideation to the final high-fidelity prototype.
User Problems
1. No centralized Internal Data Catalog for all GM.
Data can exist on local servers or on one of many cloud providers like AWS or Azure
2. Users need more information about data limitations and available resources.
There is a lack of documentation regarding the proper way for requesting access to data, subscriptions, repos, etc.
3. No coding standards and cost structure.
Having no coding standards leaves a lot of room for error, which can drive up costs and issue warnings
Solution
A central hub for data exploration.
- The data catalog will document available datasets and important metadata likesome text
- location,
- descriptions,
- Data lineage
- usage instructions.
- Clear documentation on how to on-board to cloud providers, how to gain access to data and how to take code to production will also be provided.
- Coding standards for cost efficiency and a community where people can get access to this information.
These features will all work together to help users save time and keep development costs low.
User Interviews
The main user groups for this tool would be data scientists and developers at General Motors.
I wrote a script to conduct semi-structured interviews to understand which data tools they use and how.
The interviews consisted of 13 participants and 4 different user types, users were recruited by contacting employees in target organizations for the tool.
- 5 Leads
- 3 Data Scientists
- 3 Engineers
- 2 Developers
Results
These were the main pain points the majority of users were having.
Getting Access to data can take months and cause users to run in circles to find someone to approve their access requests.
Users who are having to transition to the cloud aren't being provided with necessary support or guidelines.
Users are ramping up costs with development and are still not able to get needed resources like CPU without proper flows set up.
I summarized the notes into an affinity map, organized by user’s likes, dislikes, and needs for all the data tools they use.
This map helped us view the results in a more consumable manner and allowed us to easily identify areas of opportunity. Surprisingly, most of our users were already on Databricks, despite the move to cloud tools being recent. This provided a lot of interesting feedback for me, as I assumed most people were still on-prem/local and would mainly have pain points with the Maxis tools.
Personas
Following the affinity mapping, I summarized the data into three different personas.
Assumption Mapping
To think about the product itself, I made sure to highlight any areas where we were still making assumptions. The map allowed us to decide the most desirable and feasible features.
We had to make assumptions because GM as a whole still lacked information about working with cloud data. We would need to find a way to collect information about best-practices, such as by collaborating with other teams to get that information.
Stakeholder Workshop
Before continuing with the design process, we wanted to confirm the vision, goal and high level features of the new product with our stakeholders.
I helped prepare and lead the workshop by organizing an agenda with clear goals for the workshop. The four main topics were:
- Data Discovery,
- Data Marketplace,
- SQLGPT & Existing products,
- future products.
My team and I created How Might We questions for each topic, using the assumption mapping results to think about the questions.
The workshop was a two day event that required our director to participate. We had each team member add sticky notes for their responses to each question.
Workshop Outcomes
- Buy-in with our stakeholders increased as they were impressed with our research and designs so far, making them enthusiastic for our future designs.
- We used the results of the workshop to create action items
- Required features for the data catalog
- Questions we still need answered or researched, such as data domains to group the items into.
User Flows
With the list of required features finalized, I was able to create one current user flow and future user flow for each persona and use case. Having both allows me to compare the differences and to have a point of reference later in the design process.
I highlighted steps with key information that we will likely return to when sketching by adding purple notes or red notes for steps we weren’t completely sure about.
Because of how extensive the user flows are, this is just a snippet of one of the future use case flows. You can view all the user flows here.
Inspiration
To help myself think about different designs, I look at similar products or features and noted how I can implement similar designs.
Crazy 8's
After revisiting all the research, re-reading the product requirements and viewing the user flows again, I was ready to begin sketching crazy 8’s.
Information Architecture
The user flows and crazy 8’s revealed there were still some clarity needed for the information architecture and the metadata for the data items. There was still not a clear list of metadata for the data item page and I needed to know the final list of content to include in our designs.
To get the information, I attended multiple meetings with stakeholders on adjacent teams. The stakeholders from my organization were also present at these meetings, so they were able to sign off on the requirements.
With the new requirements obtained, I organized an information architecture chart to help us note and visualize the needed information.
Low Fidelity
I then designed Low-Fidelity wireframes, focusing on simple/short navigation and having clear search features and filtering for data items.. Below are some of the wireframes I designed, along with dots that my team members voted to include in the high-fidelity designs
Home Page. I made two options, one with a set of extra tabs on the homepage and the other with a side nav.
Data Search Page. Two options, one has suggested searches and data items, but the rest of the data is grouped into categories. The second option has filters for the search and lists all data items without using groups.
Data Item Page. Three options, mostly just changing the order of the information and including some extra features, like use cases and sample queries.
High Fidelity
After the low-fidelity wireframes, a lot of time was spent experimenting with the UI’s look and feel. Eventually we decided on a light-subtle theme due to the nature of the UX and amount of information we needed to present. The main purpose was to not overwhelm users with too many colors and information. The blue theme also helps product feel more associated with General Motors.
Below are the final designs, along with my reasoning. After designing the final prototype, I had the opportunity to conduct usability 4 tests with users we interviewed at the beginning of the project. These designs have feedback from the tests applied to them already. The main feedback was about filters on the data search page and metadata organization on the data item page.
To increase my efficiency when designing, I used features like autolayout and components, along with Dev Mode to simplify the handoff to our developers.
Home Page. Users can search for data items and apply filters. Filters can be saved for later use and the 'Clear all' button can remove all of the applied. There's a domains dropdown on the top nav for users to browse for data by groups.
Search Page. Users can apply a new search to the data catalog. The filter button will either show or hide the filter panel. Data can be sorted by different metrics like popularity, date added, and alphabetical order.
Data Item Page. Users can see a description, followed by the data profile and data lineage. Data lineage and Metadata information are collapsible in case user's want to focus on the other information on the page. The owner of the item will also be able to edit the description and some metadata.
.png)
Conclusion
The product is currently in development, with v1 soon to launch. The Data Catalog was an exciting challenge as it was the first project I worked on from idea to development at General Motors. Though I wasn't able to see it launch, I was able to present the final designs at our organization's all hands, and users were very excited for it to release as they said the search functionality and item page information would save them a lot of time when looking for data.
I managed to get all necessary information and feedback despite the barriers around communication and siloing in the large IT organization. Checking in with both our manager and PM during stand ups and additional syncs helped break down large problems and understand technical limitations.
Since I didn’t have prior knowledge about the cloud space, I improved my technical knowledge and creativity by thinking about a lot of possible solutions to our user’s problems. If I could change one thing, I would have liked to have more time to conduct usability tests earlier in the design process.