SURŌ Platform Management

Designing internal reports for priority workflows

My Role

Product designer


Lead developer




SURŌ is a promotional platform for travel properties. Adding new customers to the platform involves several internal workflows to ensure their properties align with the brand.

Site owners vet new property submissions, edit and publish listings, and schedule photo assignments. Taking these steps ensure the highest-quality properties and imagery that align with their brand. Once a property listing is live, they fulfill orders for promotional services.


Our internal management tools were intended for a small team of users, so we sought to keep the interface simple. However, as requirements expanded, we met the limits of our design.

Our goal was to manage all records in one centralized table.

This approach seemed feasible at first. We could manage all of our early workflows from a single records table, or the isolated records themselves.

Individual reports, we thought, would require too much design and a commitment to use cases not fully defined. And a centralized table would give site owners flexibility to filter for specific attributes and support self-directed tasks.

However, as use cases increased, so did the data site owners needed to view. We expanded columns and nested attributes. That worked for awhile, even with limited screen space. So we leaned into it with a few added tactics to wrangle the complexity.

Early Solutions

We added quick views for priority records and workflows.

This provided an efficient mode of task switching.

Prioritized actions critical to managing the platform...

Provided custom filters for other record states and tasks...

(using inclusive operators to keep the development simple and reduce null results)

Surfaced additional record data and functionality in modals...

Plus some basic table features...

Search filter

Finding records by location, property or account name

Column sorting

Column sorting by alpha, date, or priority

Frozen Header & ID Column

Locking key information in view

Column visibility

Deciding which columns to show or hide

  • Using these features, we could address the limits of screen space.
  • Quick views provided a viable solution for task switching and surfacing priority actions.

Eventually, we reached the limits of this solution, for a few reasons:

  • Screen space: There are limits to the number of columns and attributes you can display.
  • Relational data: We had to display data for related record types, like promotional orders, which have their own set of attributes.
  • Column preferences: Visibility settings that make sense in one view don’t always work for another.

Every new requirement drove our current design further from simplicity. In the end, it felt like we were hacking a table to create distinct reports. So we concluded, why not do that?

Evolution of a solution

Creating distinct views that are a priority to managing the platform

After prioritizing tasks and testing a prototype, we determined isolated reports would be more effective in supporting internal workflows.

Simplified tables and notification cards brought focus to relevant data and to tasks that supported onboarding growth and platform revenue.

Status Attributes

Tracking the state of listing and customer records

In the end, we kept the full table for the all-data view. Doing so helped us track the progress of records in fine detail. Every database schema relies on status attributes to show workflow state.

We originally defined our statuses to track site owner actions (accept, review, publish, etc.), we could also use them track customer actions. That gave us the ability to track onboarding progress and nudge customers at various sticking points:

But we also had the ability to track customer onboarding progress. Defining progress in status attributes provided us a means to design future drip campaigns, based on platform data, not just clicks and open rates.

  • Account not created
  • Listing not started
  • Listing incomplete
  • Payment not submitted
  • Listing not submitted
  • Property visit not confirmed

Instead of designing a view, we used this data to design drip campaigns and automate customer reminders.

Lesson Learned

Create a product roadmap before you start design.

It’s fine to start with an MVP, but know where you’re headed. Having a roadmap will help you efficiently scale product design and code.


We’re currently using the full records table (September 2023), but custom reports are in our development pipeline.

  • Custom reports bring focus to time-sensitive tasks critical to running the platform.
  • Having clear status definitions, for every onboarding stage and business decision, will help us display property records in a variety of reports and design automated drip campaigns.
  • Consistent card and table patterns help us build efficiently and provide flexibility to adjust or design new views as the business evolves.

Next Project

SURŌ Website