Design Philosophy - Embracing Simplicity
Informed by both competitor research and user feedback, I came to understand that for a professional tool clients interact with daily, simplicity is crucial. Thus, the philosophy of 'less is more' organically emerged as the guiding principle throughout the entire design process.
To optimize functionality, the query tool was strategically divided into three parts: filter, query result, and asset details. I will delve into the specifics of each section in the following discussion.
Filters
The filter part, being the first interaction point for users, necessitates some level of data science knowledge. Further complicating the matter is the relationship between different filters, which adds an additional learning curve. In the previous design, users often expressed confusion about whether Filter A and Filter B were related through an "and" or an "or" clause. The embedded filters further escalated this complexity.
In response, I applied principles of Gestalt Psychology, using visual cues to group filters, making them easier to understand at a glance. I also used placeholders to guide users on the type of content they should input in the dropdown list.
Additional changes include:
- Finalized the dropdown list groupings to ensure alignment with the users' mental models based on several rounds of discussion with C-level executives, data scientists, AI engineers, and loyal customers. I also proposed using a mega menu to provide a broader view of all dropdown options and group them into different categories (favorites, by data science group, by alphabetical order).
- Based on user requests, I introduced two new features: 'query from query library' and 'query from query history'. The 'query from query library' feature allows users to save frequently used queries for easy retrieval, while the 'query from query history' feature saves time on repetitive tasks. For example, if a user needs to create different charts using the same query but in different chart types.
Query Results
Upon setting all the filters, users can then review all asset information that meets the specified criteria. The query results also serve as a bridge connecting filters to asset details. However, slight variations exist across different pages. For example, in the previous design, the Explore page allowed users to upload images and add values to a data field within the query results. Conversely, the Dashboard page provided users with the option to click on a column title to drill down. These inconsistent presentations led to user confusion and increased cognitive load.
To address these issues and ensure consistency across all parts of the query tools, I adopted the following design strategies:
- I reviewed each variant on different pages, working with domain experts to critically assess and unify or remove some of these variants.
- I standardized the appearance and interaction of these variants. Previously, functions like hiding/showing fields, uploading images, and adding values were scattered in different places with various formats, requiring extra attention from users to learn and remember. I proposed using a 'more' button on the right side to house expanded functions and dynamically show/hide some buttons based on the variant.
- I facilitated a seamless transition from filters to details by integrating a 'back' icon at the top for returning to filters, and standardized access to each asset's details via a right arrow icon situated on the right side of each asset.
- I recognized that table content could contain different data types. Drawing insights from competitors, I formatted these in various ways. For instance, list type fields were grouped into labels, time fields displayed in date and time format, and binary fields showed 'yes' or 'no' instead of '1' or '0'.
- I determined a string length limit to prevent excessively long table content, which could cause a table break.
Details
The 'details' part, which contains the most comprehensive information for each asset, is grouped into two categories: one based on the data sources the user integrated into Lucidum, and the other following Lucidum's grouping consistent with the filter part's dropdown list. Previously, the 'details' section was a dead-end. Users were unsure of the next steps after viewing the clusters of values.
After defining specific use cases with users and domain experts, I implemented the following changes:
- I added a breadcrumb at the top for cross-search functionality, enabling users to drill down from asset information to user information. For instance, if an employee rents a company laptop and doesn't return it within the designated time, the IT manager could query the device, go to the details section, click to view the user details, scroll to their manager, and communicate with them regarding the situation.
- I standardized the interaction within this section, including pagination, table scrolling, sorting logic, tab format, etc.
Design handoffs
Once the groundwork was laid, I developed a use case outlining various paths, including the optimal path, error paths, and potential edge cases. Interestingly, the number of edge cases grew throughout the development process, thanks to the collaborative contributions of team members, including stakeholders, developers, and quality assurance personnel.
Along with detailed Figma files demonstrating specific user journeys, I also collaborated with a frontend engineer to establish a standard for component handoff. We developed a document to set rules for naming conventions (Page_Function_Component). I adhered to these rules when creating components and their variants in the Figma Design System. The frontend engineers also followed this naming convention when creating corresponding components on their end. This approach made each implementation trackable and easily modifiable. Additionally, we utilized the auto layout feature to ensure strict adherence to specifications.
Design System
After defining several options, we began sharing prototypes with engineers for testing. When certain features were validated, I was able to refine the designs and initiate the construction of a more detailed design system for ongoing development.
As for the development pipeline, I partnered with the frontend developers to implement the components in Storybook - a workshop for building UI components and pages in isolation. The next step was to deploy these components on the platform. This strategy was designed to progressively shift our development towards a more systematic approach, aimed at reducing future technical debt.
