Creating Reports
Bridging the gap between two product segments
My role: Lead Product Designer
Company: Preql
v1 report creation modal (Old)
V.S.
“Create Report” (New)
Overview
Preql has two primary product areas - Definitions and Reports. The two were developed separately so users were experiencing a disjointedness in the product. It was not abundantly clear to users how the two were related or how to best navigate from one to the other. There was a need for a more unified experience.
Enter… “Create Report”
In this case study I will focus on the primary flow that would connect Definitions and Reports - “Create Report”. This flow is the most robust and comprehensive method enabling users to build on what they’ve established in Definitions by visualizing it in Reports.
Preql Report example
The Challenge: Create a UI and UX that feels simple, when it’s not.
After defining a set of requirements with leadership, I set off to create a simple and beautiful experience that would honor the complexity of a user’s data. The biggest challenge of creating a no-code product feature for non-technical users was figuring out a UI that would gracefully display a large set of data and a UX that would allow users to interact with the data seamlessly. Not only that, but then balancing how and when to obscure logic behind the data engineering transformations that go into table creation. I love table joins! 😅
Accordion / Preview interaction prototype
Choosing the UI
To streamline the user experience and simplify the development process, we implemented a guided approach by requiring a sequential selection of assets. Users must complete one step before advancing to the next, and choices in the initial step impact subsequent options. We considered UI options such as a stepper and accordion, ultimately choosing the accordion for its ability to neatly nest content and display all steps in a single view. This, along with a preview table showcasing live output, aligns with Preql's “transparency” design principle.
Accordion UI close-up
Where to host the accordion?
I created three options for hosting the "Create Report" feature: a side drawer, modal, and full page. We opted for the modal based on established design patterns. Side drawers were prevalent for quick views or editing existing assets, and the full page format didn't quite fit for this type of feature in our product at the time. The modal was chosen because it had been successfully employed for "Create Report" previously and ensured the feature received the necessary user attention to complete the workflow.
Modal option for Create Report
How and when to display SQL logic
The question of whether or not we communicated SQL logic occurred when joining data from more than one application (AKA different data formats). Asset selections that triggered a join resulted in fewer choices in the second step due to uncertainties about joinable aspects of the data. In the initial design phase, we refrained from informing users about different join types as we were undecided on the technical approach. Additionally, we decided that introducing warnings and unfamiliar logic at this stage could potentially impede the user's workflow. This decision, while of relatively low impact, was something we aimed to refine over time.
Example of warnings as a result of SQL logic (for future implementation)
Final design
With the approach defined as previously explained, along with the addition of a preview table and confirmation page, the design was ready to layout and hand off to engineering. Here is an example flow of the design!