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
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?
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.
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
Other projects




