Overview

Since joining Shesha, the team has been putting real effort into making noticeable change to the tool we're building. In one of these sessions, a specific complaint kept surfacing: users were frustrated and openly confused about why our dataTable component was set up the way it was. That complaint is what pulled me in. I led the research effort, working closely with AI to move faster through discovery, while the team and I dug into the why and the how behind a component that had quietly become one of the hardest to configure.

Since joining Shesha, the team has been putting real effort into making noticeable change to the tool we're building. In one of these sessions, a specific complaint kept surfacing: users were frustrated and openly confused about why our dataTable component was set up the way it was. That complaint is what pulled me in. I led the research effort, working closely with AI to move faster through discovery, while the team and I dug into the why and the how behind a component that had quietly become one of the hardest to configure.

CLIENT

Shesha

YEAR

2026

DELIVERABLES

Product Research User Flows High Fidelity Screens

ROLE

Product Designer

Gustave Flowbert

Impact

Achievement

This product is still working its way through the pipeline, so the figures below are early, internally reviewed indicators – fuller user metrics will follow in later stages.

  • Decreased technical debt by 15%, based on an internal cumulative metric.

  • 20% conversion of new users to the tool following the rollout of this feature.

  • Cut setup time for the feature by more than 8 minutes.

Problem

How we dug ourselves into this technical hole

Shesha’s dataTable component was set up in a way that made even simple tables slow and complicated to configure. Its data binding was still rudimentary, and it didn’t support flexible data binding – especially for client-side binding.

Why?

Mental Model Mismatch

Users expect to point a table directly at data, not create a context wrapper first.

Extra Steps

More configuration screens = more opportunities for errors and confusion.

Harder to Learn

New users must understand an abstract concept (context) before they can display simple data

Mental Model Mismatch

Users expect to point a table directly at data, not create a context wrapper first.

Extra Steps

More configuration screens = more opportunities for errors and confusion.

Harder to Learn

New users must understand an abstract concept (context) before they can display simple data

Approach

The road to getting the component to a new state

Working on a two-person design team is always fun, but it can also spark a small uproar over task delegation. The design lead handed me the research: question everything, then come back with an answer.

When I looked closely at the component in its original state, the questions piled up fast – fast enough that I built a running “questions board” just to hold them all.

The pattern I kept circling back to: we were behind on the small UX details that make data binding feel effortless – but the gap was closable without touching our core architecture. Other tools had clearly found a way to add power without adding friction, each with its own learning curve. To understand how, I analysed 5 competitor platforms, relying on Claude to accelerate the research so I could go deeper in the time I had. 

With the use of Claude, I analysed 5 leading platforms:
Here’s what I measured:

  • What data sources you can bind FROM (databases, app state, URL parameters, user session, etc.)

  • What UI properties you can bind TO (visibility, text, styles, defaults, etc.)

  • How easy it is to create those bindings (visual tools vs. writing code)

That matrix was the turning point. It showed exactly where we were ahead, where we’d fallen behind, and – more importantly – a realistic path to closing the gap.

That research pointed to one clear answer: an expression-syntax-based binding solution. Proposing it, though, was where things got harder. 

In our meeting with the engineering lead, I walked through the research and the proposed solution. It didn’t land the way I’d hoped – instead of a green light, I left with 3 new problems to solve:

  • If a form was already bound to this Team entity, there was no way to simply tell the data table to display `data.members`.
    You’d need a separate data table context, a re-fetch, or a string of extra configuration steps.

  • The component’s event system was incomplete and unclear.

  • There was no straightforward way to bind the right-side form to whichever row was selected on the left.

None of these were things I’d missed by accident – they were the kind of integration issue that only surfaces once you start asking how a change to one component ripples through the rest of the system. 

Gustave Flowbert
Gustave Flowbert

Solution

Thinking of an easy solution for a complex problem

Getting real pushback meant going back to the drawing board. 

This time, I needed to tackle the configuration approach itself, and how it cascaded through the rest of the dataTable’s behaviour:

The component needed to support client-side binding 
The Component needed an event-handling system needed to be finalised
The component needed row-selection binding

Conclusion