The next step was unclear.
Feedback described uncertainty after job creation and difficulty understanding the connections between jobs, execution, credentials, and databanks.
Enterprise SaaS / UX case study 01
Connecting the
testing workflow.
I redesigned an enterprise testing interface across cases, data, jobs and reports, using direct tester feedback to understand where the flow became confusing.
- My contribution
- UX/UI design across the application
- Users & foundations
- Internal testing teams · Enterprise design system
- Scope of this case study
- Two design iterations
Impact not yet measured
The short version
The case at a glance.
- The problem
- Testers struggled to connect test data, cases, job execution and reports. Repeated actions and missing information created uncertainty.
- What I owned
- The revamped UX/UI across navigation, test-case creation, jobs, executions, reports and databanks, adapting an existing component system.
- The design response
- First, align the existing experience with consistent patterns. In a later iteration, add an opportunity to check a test case during creation.
- What supports the story
- Direct conversations with testers, documented feedback and design exports. Time savings have not yet been measured.
01The context
An evolving product.
An increasingly complex flow.
The platform helps an internal team create and execute regression tests on behalf of customers. The product had evolved from code-based testing to a no-code approach, while added features made its existing workflows harder to follow.
The starting point
The original interface did not follow the established design system consistently. Related actions were scattered, and testers were unsure how test data, cases, jobs, and reports connected. Repeated features and missing guidance added confusion.
The first revamp
I retained the core workflow and redesigned its screens around established patterns, with targeted adjustments. The focus was a consistent foundation for internal testers.
My role. I designed the revamped screens across navigation, test-case creation, jobs, executions, reports, and test-data management. I adapted existing components into compositions suited to these workflows, then explored a further iteration.
02Listening first
The people doing the work
helped define the problem.
I spoke directly with the testing team about what made their work slow or confusing. Before changing features, I asked whether the proposed approach would help them or interrupt their work.
Research basis: direct conversations with internal testers. Findings are paraphrased and identifying details are omitted.
Repeated work accumulated.
Testers described cloning and editing cases, managing disabled groups, and repeating report selections when something needed correction.
Finding the right thing took effort.
Large test lists and visible disabled groups made scanning harder. Missing information and unclear names added uncertainty.
Themes paraphrased from research notes. These findings describe the earlier experience; they are not measurements of redesign outcomes.
03Two iterations
First, establish consistency.
Then, extend the workflow.
01 · First revamp
Align the existing experience.
Rework the interface using established patterns and components while keeping the main workflow familiar. Make targeted improvements to the existing flow.
02 · Newer iteration
Check a case during creation.
I introduced a design exploration that lets testers enter test data and run an individual case within the creation experience.
Connecting feedback to the interface
What testers described
The databank upload and download flow was difficult to find and connect to the rest of the work.
In the design
The databank view groups the job reference, case list, iteration table and data actions in one place.
See the databank screen →What testers described
Reporting involved repeated selection and checking. Testers needed to understand what passed and what failed.
In the design
The report combines summary information, outcome filters and detailed case results. This addresses part of the investigation task; it does not establish that report-download repetition was resolved.
See the report screen →Later iteration · Design exploration
Let testers check their work
before moving into job setup.
Earlier experience
The earlier creation flow did not include this in-place check.
Later design iteration
Enter test data, run the individual case, review the result, and save when satisfied.
Intended benefit: an earlier opportunity to identify problems, with the goal of reducing rework during later job setup and execution. Its effect on time has not been measured.
04 · Selected screens
The work, in context.
Four views from the design work. Product and customer identities are replaced, personal details are removed, and all values are sample data. Open any screen to inspect the layout at full size.
The editor brings case details and numbered, grouped steps into one view. The Save and Run action belongs to the later design iteration, exploring a check before job setup.
View full screen ↗
Job setup places configuration and the selected test cases together, so testers can review what the job will contain.
View full screen ↗
A case list, visible status labels and iteration columns organise test data. Upload and download actions sit alongside the data they affect.
View full screen ↗
Summary cards and detailed case results support checking what passed, failed or was skipped. The figures shown demonstrate the report layout; they are not real execution data or evidence of UX improvement.
View full screen ↗These are anonymised design exports. Branding and data visualisations have been adjusted for confidentiality; the source Figma file is unchanged.
05The workflow
From an individual case
to a scheduled check.
This is the intended journey for the newer iteration, including the test run during creation. Explore how that addition would fit into case preparation, job setup, scheduling, and reporting.
Run it while creating it.
Enter the values and test data, run the individual test case, and check whether it behaves as expected before using it in a job.
Later design iterationContinue from recent work
Job setup surfaces recently created test cases so testers can find and select the cases they just prepared.
Set the cadence
Testers configure the job and schedule execution, including monthly or quarterly checks, then review the reports for that flow.
06Design to impact
Two stages of work.
Outcomes still to measure.
Evidence so far
This case study documents design work and user feedback. I do not yet have measured time-saving results. All names, dates, counts, durations and charts in the screen exports are illustrative sample data.
To evaluate the design, I would compare the same tasks with testers and distinguish prototype findings from production results.
- Preparing a case for a jobTime, assistance needed, and corrections before the case is ready.
- Finding the case during job setupTime spent locating and selecting the intended case.
- Completing the workflowSuccessful completion, points of uncertainty, and unnecessary repetition.
Proposed measurement plan. Keep task conditions comparable and distinguish active user effort from automated execution time.
What I learned
Working directly with testers gave me a way to check assumptions in a domain that was new to me. Their feedback helped me connect interface decisions to the work people were actually trying to complete.
Let’s talk.
Reach out about UX roles, my work or a conversation with your team.
Phone+91 70422 84277