Reframing a quick-win request into a user-validated strategy
Sometimes the most important design work happens before design. This project is about pushing back with purpose, validating a feature request nobody had questioned, and reshaping a roadmap based on what users actually needed.
The Challenge
⚠️ In data tools, a schema is the structure of a database: the tables, columns, and relationships that define how data is organised. For data engineers using Matillion, schemas are referenced constantly while building pipelines. But in Matillion's newer product, schema information was buried. Engineers couldn't see what they needed without building a pipeline first, which created friction at every step.
A stakeholder proposed a quick fix: add a search bar to the schema panel.
It seemed reasonable. But search is only useful if engineers can already see the information they're searching through. The real question wasn't "should we add search?" It was "why can't engineers find what they need?"
Without knowing that, the team risked shipping the wrong improvement.
My Role
I led:
- Problem definition and challenge of the original brief
- Discovery planning and interview planning
- Competitive analysis of how other data tools handle schema visibility
- Five internal data engineer interviews
- Stakeholder alignment and playback
- Reframing and design direction shaping
The real design work happened before Figma opened.
Results
✅ 12.3% increase in stakeholder confidence
✅ Stakeholder alignment on merging two overlapping projects into one roadmap
✅ Scope reframed from "add search" to "fix schema usability end-to-end"
✅ A validated problem definition that everyone agreed on
Context
Schemas power nearly every pipeline in Matillion's Data Productivity Cloud. But in the early versions of the product, schema management lacked the visibility that engineers had relied on in the previous Matillion tool. They were slower, less confident, and more frustrated.
A stakeholder requested a quick win: just add search to the schema panel.
But the request didn't match what I'd been hearing across teams. Search might help. But it might not. So the question was: what problem is search supposed to solve?
Why I Pushed for Validation
Because shipping the wrong improvement is worse than shipping nothing.
If search wasn't the real problem, adding it would have created UI noise, ignored the deeper workflow pain, and reinforced local assumptions rather than real user needs. This project became a test of pushing back with purpose.
Research and Insights
I started with desk research and competitive analysis, looking at how the following handled metadata visibility, search, and table previews:
- Snowflake
- dbt Cloud
- Notebooks and IDEs
- Matillion's own legacy product
Matillion ETL, their legacy product, used as a reference point in the schema research. It highlights how users could search, view, and interact with schema metadata, including tables, SQL, and properties, directly within the canvas, offering a streamlined, automated workflow that informed design decisions for the new Data Productivity Cloud.
Then I ran 5 internal data engineer interviews to uncover:
- How schemas fit into their actual workflow
- What information they prioritised
- How they searched, viewed, or reused schema data
- What the previous Matillion tool did well that the new product lacked
- Where the real pain points were
What users told me:
- "I can't see the schema metadata unless I build a pipeline."
- "Previewing tables takes too many clicks."
- "Building pipelines is slower because nothing is pre-populated."
- "The old tool used to give me context instantly."
- "Search isn't the main issue. I need visibility."
Reframing the problem
- "I need to see metadata instantly, without building a pipeline first."
- "I need to preview table data with fewer clicks."
- "I need components to be pre-populated so I don't waste time on basics."
Search was a symptom.
Lack of visibility and context was the real problem.
Building the playback
I built a playback deck showing:
- Side-by-side comparisons of competitors and the legacy product against the current state
- Best-practice patterns from other data tools
- Direct quotes and insights from interviews
- The gaps affecting productivity
I reframed the decision from: "Should we add search?"
to
"How do we make schema interactions intuitive, visible, and low-friction?"
Stakeholders understood the difference immediately.
Execution
The research revealed two overlapping projects running in parallel:
- Schema Enhancements
- Pipeline Creation Modals
Both required better schema metadata, visibility, and sampling.
I proposed merging them into a single, user-centred project to:
- Increase impact
- Reduce rework
- Align UX across workflows
- Simplify engineering implementation
Validation and Playback
In the playback session:
- Stakeholders responded strongly to the story around user impact rather than features
- They agreed the initial request was too narrow and supported merging the initiatives
- What had started as a quick-win feature request had evolved into a validated, user-driven roadmap for schema management
Outcomes and Impact
Results
While the project didn't ship before I moved on, it delivered measurable value internally:
✅ 12.3% increase in stakeholder confidence
✅ Stakeholder alignment on merging two projects into one roadmap
✅ Scope reframed from "add search" to "fix schema usability end-to-end"
✅ A validated problem definition that the whole team agreed on
Business outcome
🎯 Business value:
- A future design that reduces engineering build time
- A more competitive schema experience compared to Snowflake and dbt
- A workflow that supports faster pipeline creation
- A more intuitive onboarding experience for new users
- Reduced support burden through clearer schema navigation
- Stronger trust in Matillion's UX practice
The cost of skipping validation
If the team had shipped search without this research, they would have added a feature that addressed a symptom rather than the cause. Engineers would still have struggled to see schema metadata. Two overlapping projects would have continued running in parallel, duplicating effort. And the roadmap would have been built on assumptions rather than evidence.
Pausing to ask why cost one month. Skipping it would have cost several sprints of misdirected work and a feature that didn't move the needle.
Reflection
This project taught me that the most valuable design work often happens before design.
Asking why and backing it with evidence helped avoid a shallow fix and move toward a meaningful workflow improvement. I didn't just design a solution. I reshaped the problem.
Next steps
- Schema sampling
- Metadata visibility improvements
- Pre-populated components
- Connected schema-to-pipeline workflows