Helping operations teams find and use governed data without SQL

As the on-site FDE, I was the direct technical contact for customer requirements. I implemented most changes requested through customer feedback, with direct ownership of the search-results upgrade, the data-governance features, and the detailed Query Builder interactions.

“Our employees cannot use SQL. Help them access and use the data.”

Customer, project kickoff

The request assumed that SQL syntax was the bottleneck. But writing a query only helps after a user knows which data exists, understands how it is organised, and can decide what to ask for.

The real gap appeared earlier in the workflow. Operators needed a way to discover and understand the available data before they could query it.

The first version reached the 200-user beta. Then I received direct feedback that the results screen did not communicate enough context.

“We can tell the portal is trying to provide a lot of data, but we cannot tell what information is available or what the screen is trying to show us.”

Beta user feedback, paraphrased

The screen returned data, but users could not understand what they were looking at or how each result related to the wider structure. To identify the cause rather than patch the visible symptoms, I used and compared other data-search products myself. That research showed how hierarchy, filtering and result context reduce the user’s interpretation burden. I used those findings to define the improvement direction and rebuilt the experience.

• From a result-first screen to guided exploration.
• From flat search results to hierarchy and filtering.
• From assuming users knew the catalog to showing where each result belonged.

This was not a greenfield application. The solution had to fit into an existing enterprise environment.

• The Databricks platform already existed and was maintained by a partner team.
• Data governance and access boundaries could not be bypassed by the portal.
• The primary users were operators, not analysts or engineers.
• Several companies owned different layers of the delivery, so technical and organisational boundaries had to stay explicit.
• I joined two weeks before beta testing, so I had to understand the existing code and customer context while delivering against an immediate deadline.
• The first release had to support 200 users while remaining compatible with a wider enterprise rollout.

My team owned the portal layer and Power BI delivery. We did not replace the Databricks platform. I owned the portal’s technical direction and hands-on implementation while coordinating the report work between the customer and our modeler. That boundary kept the product focused and made responsibilities legible across the delivery team.

The Query Builder covers the full user flow from query generation and execution to viewing and exporting results. Its remaining gap is query validation, not execution. The governance workflow measures quality and contamination signals from Databricks, presents them to governance administrators, and supports a managed correction process through the portal.

The initial request often describes the nearest visible obstacle, not the underlying workflow problem. Here, SQL was visible — but discoverability came first.

If I ran the project again, I would put a stripped-down results experience in front of five operators during the first week, to test whether users understood the information structure before the team invested in a wider rollout. I would also design query validation at the same time as generation, rather than treating it as a later production concern.