KATALYST / UX CASE STUDY • AI TEST MANAGEMENT
Simplifying software testing.
Connecting test design, execution and reporting in one workspace—so teams can focus on quality.
Product experience / Website concepts / Design system
01 / Organize the test library
02 / Review an AI-generated draft
PRODUCT
Katalyst
AI-powered test management
Role
UX / Designer
User research, Competitor Analysis, Information Architecture, User Flow, Wireframe, Prototyping
DESIGN TOOL
Miro, Figma
Problem statement into Solution
Duration
6 Months
From Apr 2025 - Aug 2025
450
Source screen artboards
20
Product screen families
04
User roles
02
AI input methods
01 / THE PRODUCT
One platform. The full testing lifecycle.
Katalyst centralizes test planning, case creation, execution and reporting. Manual work, AI-assisted authoring and automated testing connect inside a shared project workspace.
FOR TESTERS
Design. Execute. Record.
Build cases, follow assigned runs and capture clear results with the evidence needed to review them.
FOR LEADS & ADMINS
Plan. Review. Monitor.
Organize test scope, assign responsibilities and use visible run status to guide the next decision.
The product opportunity
AI can accelerate a first draft. The experience still needs to make that draft understandable, reviewable and ready for execution.
01
Structured test work
Suites, cases, plans and runs keep reusable test content separate from each execution.
02
Connected context
JIRA and GitHub bring requirements and development workflows closer to testing.
03
Visible outcomes
Assignments, pass / fail metrics and recent runs support everyday follow-through.
02 / PROBLEM & OBJECTIVES
Testing work is connected. The experience can feel fragmented.
The source personas point to time spent writing cases, switching context during execution and following up on progress. These are documented inputs from the file.
01 / AUTHORING
Too much manual writing
Recording every action and expected result takes time. Missing detail can weaken a case before execution.
02 / EXECUTION
Losing the next step
Moving between the product, test instructions and evidence makes it easy to lose position.
03 / OVERSIGHT
Unclear progress
Leads need ownership, completion and evidence quality without repeated status requests.
HOW MIGHT WE
Help a team turn requirements into reviewed tests—and make the next action clear at every step?
OBJECTIVE 01
Reduce repeated effort
Use reusable suites, import / export and reviewable AI drafts.
OBJECTIVE 02
Preserve context
Keep case details, step outcomes and evidence together.
OBJECTIVE 03
Expose responsibility
Connect assignments and status to an actionable overview.
03 / USERS & RESPONSIBILITIES
Two daily jobs. Four levels of access.
Ravi and Aravind are the existing personas in the source file. Their needs guide the narrative; Admin, Lead, Tester and Viewer come from the supplied product brief.
RAVI / JUNIOR QA TESTER
“Help me finish the right test.”
Create accurate cases, follow the next step, attach evidence and complete assigned work without losing context.
NEEDS
Numbered steps Clear pass / fail decisions Fast evidence attachment Visible assigned work
ARAVIND / QA LEAD & ADMIN
“Show me what needs attention.”
Review coverage, allocate work and inspect incomplete execution or missing evidence.
NEEDS
Assignment visibility Step-level progress Review and approval states Trustworthy run summaries
01
Admin
Configure the workspace and access.
02
Lead
Plan work and review progress.
03
Tester
Create and execute assigned tests.
04
Viewer
Inspect permitted work and results.
Role descriptions summarize responsibilities. Exact permissions should be checked against the configured access rules.
04 / COMPETITOR ANALYSIS
AI is expected. Clarity is the opportunity.
A desk review of official product sources compares capability emphasis. This is not a usability benchmark or a claim that one platform outperforms another.
PRODUCT | VERIFIED EMPHASIS | DESIGN IMPLICATION |
|---|---|---|
TestRail | AI script generation, Jira coverage checks and BDD workflows. | Make traceability and review states clear. AI alone is not a differentiator. |
Jira-based testing with AI-generated automation scripts from manual cases. | Reduce the handoff between test design and engineering context. | |
Centralized test management with AIDEN-assisted authoring and automation. | Make the move from AI output to trusted execution explicit. |
KATALYST / PROPOSED POSITIONING
One readable workflow from requirement to result.
Sources checked 30 September 2026. Katalyst capabilities are based on the supplied brief.
05 / DESIGN STRATEGY
Make every handoff feel like the next step.
The design connects reusable test content, human review and visible execution. Four principles guide the screen journeys that follow.
01
Start from context
Keep a requirement, JIRA reference or existing suite close to the task being created.
02
Keep humans in control
Treat generated cases as drafts. Make review and approval explicit before execution.
03
Reveal state and ownership
A test needs more than a title: status, priority and responsibility explain what happens next.
04
Design the recovery path
Empty, error, import and permission states deserve the same clarity as the main journey.
06 / INFORMATION ARCHITECTURE
A shared workspace. A clear place for every task.
The architecture follows the product navigation and groups work by intent: understand progress, design tests, execute a plan and manage the project.
ORGANIZATION → PROJECT
Choose the context before choosing the task.
OVERVIEW
Dashboard
Assigned work Recent runs Pass / fail metrics
DESIGN
Test library
AI Test Case Drafts Test Cases / Suites Import & Export
DELIVERY
Plan & execute
Test Plans Test Runs Results & evidence
PROJECT SUPPORT
Settings & integrations
Project configuration JIRA / GitHub connections Tags, environments and logging
WORKSPACE SUPPORT
People & governance
Organization and user settings Role-based access Profile and administration
Adjacent source modules include ADMS, unit testing and newer module-launcher concepts. They remain visible in the atlas without changing the core test-management narrative.
07 / END-TO-END JOURNEYS
From requirement to a visible result.
The same case library supports manual and AI-assisted creation. Review is the handoff that makes a draft ready for planning and execution.
Journey A / AI-assisted authoring
01
Provide context
Requirement text or a JIRA link.
→
02
Generate drafts
A first pass at structured cases.
→
03
Review & refine
Check steps, metadata and expected results.
→
04
Organize tests
Approve and place cases into the library.
Journey B / Plan, execute and learn
01
Define scope
Create a test plan and select cases.
→
02
Assign a run
Make responsibility and the work visible.
→
03
Execute tests
Record manual outcomes or automated results.
→
04
Review progress
Inspect failures, evidence and run summaries.
RECOVERY PATHS
Generation fails → retry or edit manually. A draft needs work → request changes. A test fails → retain evidence and re-run when ready.
Open the complete flows, including import and administration ↗
08 / GETTING STARTED
Get into the right project. Then make the next action obvious.
Authentication and project selection establish context. Empty and recovery states help people continue when there is no work yet—or access needs to be recovered.
01 Sign in to the workspace
A focused entry point for an existing team member.
MAIN PATH
USER GOAL
Access the testing workspace.
WHY THIS DESIGN
A dedicated sign-in screen keeps the first task specific and recognizable.
NEXT STEP
Choose the project to work in.
02 Choose a project
Separate workspaces before opening the test library.
MAIN PATH
USER GOAL
Find the correct project context.
WHY THIS DESIGN
Project cards give the workspace a clear starting point and keep unrelated test work separated.
NEXT STEP
Open the project dashboard.
03 Understand an empty workspace
The empty state is part of onboarding.
EMPTY STATE
USER GOAL
Know what to do when no projects are present.
WHY THIS DESIGN
The empty view establishes that there is no existing work and points toward creation.
NEXT STEP
Create a project with the required permissions.
04 Recover account access
A recovery route from the sign-in journey.
RECOVERY PATH
USER GOAL
Regain access without losing the task.
WHY THIS DESIGN
A dedicated recovery state makes the required next action explicit.
NEXT STEP
Complete recovery and return to sign-in.
09 / AI-ASSISTED TEST DESIGN
Generate a starting point. Keep review in human hands.
The brief supports generating cases from requirement text or a JIRA link. The supplied screens show the next critical stage: organizing generated drafts and deciding which cases are ready.
INPUT 01
Requirement text
Start from the written behavior that needs testing.
INPUT 02
JIRA link
Use linked requirement context to start generation.
05 Track generated draft batches
Generation, review and completion appear as visible states.
MAIN PATH
USER GOAL
Find the right generated test batch.
WHY THIS DESIGN
Batch-level status gives the user a place to monitor work before reviewing individual cases.
NEXT STEP
Open a batch and inspect its cases.
06 Review cases in context
Related cases are grouped by validation area.
MAIN PATH
USER GOAL
See which cases still need a decision.
WHY THIS DESIGN
Case-level approval states distinguish work that is pending, updated, approved or rejected.
NEXT STEP
Open an individual draft for detailed review.
07 Inspect, edit and approve a draft
The review drawer keeps the case context visible while exposing steps, expected results and approval actions.
USER GOAL
Check the draft
Confirm the scenario and expected behavior before trusting the output.
DESIGN DECISION
Show defaults honestly
The source notes that some metadata uses defaults. Reviewers should correct it where needed.
NEXT STEP
Approve or revise
Use Reject, Edit or Approve to make the handoff explicit.
10 / TEST CASE LIBRARY
Turn individual cases into reusable coverage.
A hierarchical library organizes suites, sections and cases. Search and filters help testers find existing work before creating another case.
08 Navigate the case library
Sections and nested groups reflect the structure of the work.
MAIN PATH
USER GOAL
Find an existing scenario quickly.
WHY THIS DESIGN
Grouping, search and visible approval status support scanning and reuse.
NEXT STEP
Inspect a case or add one to the relevant section.
09 Create a structured test case
The creation drawer preserves the library behind it.
MAIN PATH
USER GOAL
Write a case another tester can execute.
WHY THIS DESIGN
Title, precondition, test type, priority, steps and expected results give the scenario a consistent shape.
NEXT STEP
Save the case and send it through review.
10 Narrow the library by status
Filtering supports a specific review or execution task.
FILTER VARIATION
USER GOAL
Locate cases that share the same state.
WHY THIS DESIGN
Status is a practical way to move from the full library to work that needs attention.
NEXT STEP
Open one of the matching cases.
11 Start from an empty library
No content is a meaningful product state.
EMPTY STATE
USER GOAL
Understand how to begin.
WHY THIS DESIGN
The first action establishes the structure of the library before it grows.
NEXT STEP
Create or import the first set of test cases.
11 / PLANS & RUNS
Give the work a scope. Give each run an owner.
A test plan describes what needs to be covered. A run turns that scope into assigned execution that can be monitored and reviewed.
12 Define a test plan
Name the scope and set the due date.
MAIN PATH
USER GOAL
Establish a clear unit of testing work.
WHY THIS DESIGN
A concise plan form captures the intent before the team selects its cases.
NEXT STEP
Choose the cases that belong in the plan.
13 Resolve a duplicate plan name
The validation state sits beside the field that needs attention.
VALIDATION STATE
USER GOAL
Correct the problem without restarting.
WHY THIS DESIGN
Inline feedback explains why creation cannot continue and keeps the entered context visible.
NEXT STEP
Use a distinct name and create the plan.
14 Select cases for the plan
A drawer brings the library into the planning context.
MAIN PATH
USER GOAL
Build the intended test scope.
WHY THIS DESIGN
The existing hierarchy supports selection without recreating test content.
NEXT STEP
Confirm the selection and prepare a run.
15 Assign work in a test run
Selection and assignment connect scope with responsibility.
MAIN PATH
USER GOAL
Make it clear who should execute the cases.
WHY THIS DESIGN
Bulk selection supports assigning related work together.
NEXT STEP
Testers open the assigned run.
12 / EXECUTION
Follow the steps. Keep the evidence with the result.
Execution is where a planned scenario becomes an observed outcome. The source includes manual and automated variants with step details, evidence and completion states.
16 Execute a manual test
Actions, expected results and recorded outcomes share one view.
MAIN PATH
USER GOAL
Run the scenario without losing position.
WHY THIS DESIGN
Numbered steps preserve sequence and connect the observed result to its expected behavior.
NEXT STEP
Save progress or complete execution with evidence.
17 Inspect automated execution
A related structure supports automation results.
AUTOMATION VARIATION
USER GOAL
Understand what the automated test did.
WHY THIS DESIGN
Keeping case context and step outcomes together helps reviewers interpret a failure.
NEXT STEP
Review the outcome and investigate failed steps.
01
Sequence is visible
A tester can locate the current step and understand what remains.
02
Evidence is contextual
Attachments belong with the case or execution they help explain.
03
Completion is deliberate
Saving progress and completing a run communicate different states.
13 / DASHBOARD & REPORTING
Show what needs attention. Make progress easy to inspect.
The dashboard brings assigned work and recent run information into a single starting point. It helps a tester resume work and a lead understand the current state.
18 / START WITH OWNERSHIP
Assigned work first
A tester can move from the overview into work that already has an owner and priority.
19 / REVEAL STATE
Readable status signals
State labels and metrics help the team scan progress before opening the details.
20 / CLOSE THE LOOP
Inspect the run
The summary is a starting point for reviewing results, evidence and re-execution.
Run-level detail connects the overview to execution
Numbers inside the product screens are source design data. They are not measured project outcomes.
14 / INTEGRATIONS & ACCESS
Connect the tools. Keep responsibility clear.
The brief connects Katalyst to JIRA, GitHub and CI/CD workflows. Project-level integration settings and role-based access provide the administrative side of that experience.
21 Configure the GitHub connection
Integration setup sits within project settings.
MAIN PATH
USER GOAL
Connect the project with its development workflow.
WHY THIS DESIGN
Keeping configuration in the project context makes its scope easier to understand.
NEXT STEP
Complete the required connection settings.
22 Review role permissions
Permissions reflect the responsibilities of a selected role.
MAIN PATH
USER GOAL
Understand what a user can access or change.
WHY THIS DESIGN
A role-based model allows Admin, Lead, Tester and Viewer responsibilities to be configured consistently.
NEXT STEP
Review and apply the intended access rules.
JIRA
Requirement context
Generate cases from a linked requirement and connect testing to the intended behavior.
GITHUB
Development context
Bring the project closer to the code and engineering workflow.
CI/CD
Automated execution
Trigger automated tests within a pipeline and track the resulting execution.
The connected model summarizes the supplied capabilities. Pipeline behavior requires implementation verification beyond these design screens.
15 / IMPORT & EXPORT
Bring existing work in. Make the mapping visible.
Import and export reduce repeated authoring. The source explores column mapping, validation and export formats across 43 artboards and states.
23 Map source columns to fields
Preview the imported file and review the schema mapping.
MAIN PATH
USER GOAL
Preserve the meaning of existing test data.
WHY THIS DESIGN
Required fields and mapping choices make the import structure inspectable before validation.
NEXT STEP
Validate the mapped file and resolve any issues.
24 Export selected test cases
Choose the available format and confirm the selected scope.
MAIN PATH
USER GOAL
Move reusable test content out of the platform.
WHY THIS DESIGN
Explicit format and case-count choices help the user understand the export.
NEXT STEP
Export and use the file in the intended workflow.
01
Upload
Start with the existing case file.
02
Map & validate
Match source columns to required fields and review issues.
03
Confirm
Check the scope before committing the import.
Open all import, mapping, validation and export variations ↗
16 / WEBSITE CONCEPTS
Two ways to introduce the same product.
These responsive website concepts translate the supplied product brief into a public-facing story. They are proposed directions, shown alongside the existing product UI.
VERSION 01 / LIGHT
From requirement to release.
A calm, product-first direction introduces AI-assisted design and the connected testing workflow.
VERSION 02 / DARK
Plan. Run. Know.
A stronger contrast direction leads with visibility and a shared view of the testing cycle.
Responsive versions
The same hierarchy is adapted for a narrow viewport: value proposition, product proof, capabilities and a clear next action.
These are mobile website adaptations. The source product screens in this case study are desktop web application screens.
17 / PRODUCT EVOLUTION
One product. Several interface explorations.
The file contains earlier screens, later navigation patterns and a broader module-launcher exploration. Comparing them helps explain the changing scope without claiming an unverified release history.
EARLIER SOURCE
Dashboard exploration
An earlier dashboard direction from the original rough-work page.
LATER SOURCE
Testing workspace
A horizontal navigation pattern brings the main testing areas together.
SCOPE EXPLORATION
Module launcher
A launcher explores entry points across testing and adjacent product areas.
WHAT THE COMPARISON MAKES VISIBLE
Navigation should explain where users are, what work belongs here and how they return to the next task.
18 / DESIGN SYSTEM
Consistency turns screens into one product.
The interface uses the existing Katalyst variables, Roboto text styles and reusable components. Product controls below are live instances of the original library.
Primary
#9C27B0
Secondary
#2682DD
Success
#2E7D32
Error
#D32F2F
Roboto
48 / 40 / 32 / 24 / 16 / 14
A clear testing workflow starts with readable information.
Roboto remains the product UI typeface. Poppins is used for the editorial case-study presentation, following the supplied reference.
Inputs & actions
Default / Focus / Error / Enabled / Disabled
Status & review
State labels preserve meaning beyond color.
01
Reusable structure
Fields, actions and state indicators use the source library.
02
Explicit feedback
Default, focus, error, disabled and review states are documented.
03
Accessible review
Validate contrast, keyboard focus and non-color status cues in implementation.
19 / INTERACTIVE PRODUCT TOUR
See the workflow in motion.
An eight-step Figma walkthrough connects sign-in, project selection, the dashboard, test cases, AI review, planning, execution and results.
08 SCREENS / 300 MS TRANSITIONS
From the first action
to the final result.
Use Next and Previous to explore the sequence. Each transition connects a stage of the product story.
View the source case study ↗Dashboard → Assigned work → Run details
PURPOSE
Continuity
Transitions connect the stages without competing with the interface.
BEHAVIOR
Dissolve / 300 ms
The existing tour uses an ease-in-out dissolve between screens.
IMPLEMENTATION NOTE
Respect reduced motion
A production implementation should provide an immediate transition when reduced motion is preferred.
20 / VALIDATION & REFLECTION
Define success before claiming impact.
This case study synthesizes the brief and design file. No usability-test findings, adoption data or time-saving measurements were supplied, so impact remains a validation question.
6–8
Participants
Include testers and leads with relevant responsibilities.
05
Core tasks
Generate, review, organize, execute and inspect results.
02
Study rounds
Use the first round to refine; use the second to re-check.
PROPOSED MEASURES / NOT OBSERVED RESULTS
EFFICIENCY
Time to a reviewed case
Compare manual case creation with AI draft generation plus human review.
QUALITY
Corrections before approval
Record missing steps, incorrect expected results and default metadata that require edits.
CLARITY
Task completion & confidence
Observe whether users find assigned work, finish execution and interpret the result.
DESIGN REFLECTION
The value of AI is the quality of the workflow around it.
A faster draft is useful only when the team can inspect it, refine it, execute it and understand the result. The next design iteration should be driven by observed friction at those handoffs.
22 / File Structure
Organized Figma File
21 / COMPLETE SCREEN ATLAS
Every product family. Every documented variation.
The linked atlas contains 450 full-size editable copies across 20 product-screen families. It preserves iterations, empty states, errors, review states and administrative variations.
450
Screen artboards
Current product-page screens and their documented variations.
20
Screen families
From authentication and execution to administration and import.
1:1
Native-size copies
Open the atlas to inspect detailed UI without presentation scaling.
Open the complete screen atlas ↗
Count excludes cover templates, isolated UI fragments and duplicate rough / prototype pages. Historical explorations remain linked in the evolution chapter.