Begin with something familiar
A file upload, live source, or sample gives the work a concrete starting point.
From a spreadsheet to a useful chart.
Audimate was a freelance product design project. I designed the path from bringing in a spreadsheet to checking its structure, building a chart, and turning the result into a dashboard.
- Product design, UI, and design system
- Freelance project
- Self-serve analytics product
- 2022 / expanded 2026
How much should someone have to understand before they can see their own data?
I was designing for people who already knew the spreadsheet in front of them. They should not also need to learn a BI tool's language before finding the first answer.
Show what Audimate understood
Columns and detected types stay visible before the dataset is saved.
Keep cause and effect together
Fields, chart shelves, and the preview stay on the same screen.
Make failure recoverable
The error names the row, explains the mismatch, and offers a next step.
The chart was never the hardest part. The uncertain moment came earlier: did the product read the file correctly, and could the person trust what it found?
The first screen asks for data, not chart settings.
A person can upload a file, connect a source, or open sample data. I held back the chart language until Audimate had something concrete to work with.
The import needed its own beginning, middle, and end.
- Choose a CSV, connect live data, or open a sample
- See Audimate read the rows and infer column types
- Check what it found before saving
- Drag fields into a chart and adjust the result
- Add the chart to a dashboard and share it
The builder explains itself through position.
Data fields stay left, chart shelves stay in the middle, and the result stays right. Moving a field changes the chart in the same view, so the relationship is easier to follow.
Dimensions and measures are technical terms, but pretending they do not exist would make the product harder to trust. I kept them visible and let the layout explain how they behave.
The project also covered sign-in, data sources, field mapping, settings, and export. The workflow had to hold together beyond a single dashboard.
Returning to the work exposed what the first file was missing.
The original 2022 file was screen-led. When I returned to it for this case study, I rebuilt the foundations and components before extending the product with more states.
Teach through structure
Fields, shelves, and previews stay together, so the builder explains the model while people work.
Keep status visible
Parsing progress, inferred types, saved state, and file errors stay visible. People are not left guessing what happened to their data.
Use one visual language
The dashboard, builder, tables, and public site share the same type, colour, spacing, and control patterns.
The public story follows the same three steps.
Bring in a spreadsheet. Build a chart. Make a dashboard. I used the same sequence on the landing page because explaining the product should not require a second mental model.
A freelance product design project, revisited with clearer rules.
The 2022 engagement produced the core flow and visual direction. Later case-study work added missing states and system structure. I do not have launch, adoption, or task-time metrics, so I am not presenting them as outcomes.
The useful lesson was simple: show people what the product understood before asking them to trust the result.