A working React and Vite prototype of test case creation with models in Eggplant Studio. I built it with Claude Code from my initial Figma design so that product, engineering and customer-facing teams could click through the real interaction before a line of production code was written.
Project Overview
Eggplant Studio is Keysight's redesign of Eggplant Functional (EPF), moving a standalone desktop test tool into a Visual Studio Code extension. The aim of the wider programme was to lower the barrier for engineers new to test automation while keeping the SenseTalk scripting and image-based testing that experienced users rely on.
Model-based testing is one of the ways Eggplant users describe the application they are testing: its states, and the actions that move between them. A test case is a path through that model. The new feature needed to let people build that path by selecting steps directly in the model, and to show clearly how far along the test case they were.
A static Figma mockup could show the screens but not the behaviour that mattered most: which steps are available next, what happens when you change your mind, and how progress updates as the test case grows. I built a functional prototype so those behaviours could be seen, discussed and tested.
The Problem
Reviewers had to imagine the step-by-step interaction from still frames, which slowed decisions and hid edge cases.
The Goal
A clickable, realistic flow that product, developers and Technical Consultants could use and critique early.
TIMELINE
2 weeks
ROLE
• As UX Researcher and UX Designer on Eggplant Studio, I led research and design for onboarding, and the feature panels, working closely with the Product Owner and developers. On this feature I owned the work from first design to working prototype.
• Designed the test case creation flow in Figma, in keeping with VS Code's visual language so it feels native to the editor.
• Wrote the skills file that gave Claude Code clear requirements, behaviours and constraints to build against.
• Built and iterated the React and Vite prototype with Claude Code in VS Code.
• Used the prototype in reviews with the Product Owner, developers and Technical Consultants, then fed findings back into the design.
TOOLS
Figma, Visual Studio Code, Claude Code, React + Vite
DESIGN PROCESS & STRATEGY
The strategy was to move from static design to working software as early as possible, so the team could judge the interaction by using it rather than by reading annotations.
1. Start from the people using it: Studio's three personas shaped the requirements. Each arrives at model-based test creation with different experience, so the flow had to guide newcomers without slowing down experts.
2. Design the flow in Figma: I designed the model view, step selection states and the progress panel to sit within VS Code's panel layout and themes, so the feature reads as part of the editor rather than a separate tool.
3. Write a skills file for Claude Code: Before building, I wrote down the requirements in a skills file: what each state looks like, which steps can follow which, how progress is counted and how the UI should respond to each action. Clear requirements kept the generated code aligned with the design intent.
4. Build the working prototype: Working with Claude Code in VS Code, I turned the Figma design into a functional React and Vite prototype. Selecting steps in the model builds the test case, and a progress panel tracks each step. This allowed richer interactions than a static mockup could show.
5. Review, test and iterate: The prototype went into review with the Product Owner, developers and Technical Consultants, who act as proxies for customers whose sensitive content rules out direct access. Because it was running code, changes from each round could be made and shown again quickly.
KEY RESULTS & IMPACT
Faster design iteration: Changes to the flow could be built and reviewed in the same session, instead of waiting for a new round of static frames.
Richer interactions, earlier: Step availability, selection and progress were testable as real behaviour, well before production development.
Clearer conversations: Product, engineering and Technical Consultants reacted to the same working flow, which made feedback more specific and decisions easier.
Personas
Three personas anchored the redesign, each representing a different path from EPF into Studio: a manual tester new to automation, an experienced EPF user migrating workflows, and a developer already fluent in VS Code.
Alex, the manual tester learning test automation for the first time
Vicky, the automation engineer bringing her existing Eggplant Functional workflows into Studio
Carl, the developer who already knows VS Code well
Test Cases Interactive Prototype
