Makula - Views, Filters & Sorting

A saved-views system with a rebuilt filter and sort experience, so teams could hold their own filtered slice of a shared workspace instead of one global list.

RoleProduct Designer
Year2026
Timeline1 month

Overview

I designed a saved-views system with a rebuilt filter and sort experience for Makula’s work order platform, so teams could hold their own filtered slice of a shared workspace instead of one global list.

Problem

Work orders, assets, and related records all lived in one global list. Any filter or sort a user applied changed the page for that session only — there was no way to save it, and no way to give different teams different slices of the same data.

  • Filters reset on every visit. Because view state wasn’t saved, users rebuilt the same filter and sort setup each time they opened the page.
  • No way to scope a view to a team. Filters applied globally to the page, so there was no way to give one team an “open work orders” view and another an “overdue by location” view.
  • Repeated setup slowed everyday work. Across users and teams, this added up to constant re-filtering just to get back to a usable list.

A filtered list that persists instead of resetting

Users can create named views in List, Table, Board, Map, or Calendar layout, each storing its own filter and sort configuration independently of the default view. This turned a filtered, sorted list into a persistent object instead of temporary page state.

Creating a view offers every layout up front, not buried in a settings menu.
Any ad hoc filter and sort combination can be saved as a view directly from the toolbar.

One workspace, several coexisting views

Every view is created as Personal by default. Admins and owners can switch a view to Shared, making it visible to the rest of the team. This let a workspace hold several coexisting filtered views instead of one global list everyone had to share.

A shared view stays locked to non-admins, who are pointed to duplicate it instead of editing it directly.
Duplicating a locked view opens the same save dialog, naming the copy and setting its own visibility.

Why it matters: Restricting who can create a shared view kept views from becoming inconsistent or accidentally overwritten as more teams started using them.

Field first, condition second

I replaced the flat filter interaction with a field-first panel: pick a field — Work Order ID, Asset, Company, Assignee, Created Date — then define its condition. Active filters show as labeled chips in the toolbar, so it’s clear at a glance what’s currently applied.

Picking the field before the condition makes it obvious which filter set a view represents.
The chosen field and condition collapse into a single labeled chip once applied.

The same pattern, applied to sort

I rebuilt the sort panel using the same field-driven pattern as the filter builder — choose a field, choose a direction — and surfaced the active sort as a chip next to the filter chips so it doesn’t get buried.

Sort reuses the exact same field-picker as the filter builder.
Sort and filter share one component, so a user only has to learn the pattern once.

Rename, duplicate, or delete without leaving the page

Each view has its own settings for renaming, changing layout, duplicating, or deleting, all without leaving the page. Teams could iterate on a saved view instead of starting over each time requirements shifted.

View settings live in the same panel used to create the view, not a separate admin screen.
Saved views sit in the same switcher as the default layouts, reorderable by drag handle.

Results

Fewer repeated setups. Saved views meant filter and sort combinations persisted, so teams stopped rebuilding the same setup every session. Faster to skim lists. Scoped, team-specific views made it quicker to get to the relevant subset of work orders instead of scanning the full global list.