Website
Website
Website
Community Saas
Community Saas
Community Saas
BugSpy
BugSpy
BugSpy
Automating website testing so teams can catch problems before users do.
Automating website testing so teams can catch problems before users do.
Automating website testing so teams can catch problems before users do.
BugSpy is a web-based testing platform that automates website checks, helping developers, QA teams and businesses
detect UI issues, console and network errors, screenshots and performance problems in real time.
BugSpy is a web-based testing platform that automates website checks, helping developers, QA teams and businesses
detect UI issues, console and network errors, screenshots and performance problems in real time.
BugSpy is a web-based testing platform that automates website checks, helping developers, QA teams and businesses
detect UI issues, console and network errors, screenshots and performance problems in real time.
Role
Role
Role
Product Designer
Product Designer
Product Designer
Status
Status
Status
In development
In development
In development
Timeline
Timeline
Timeline
May 2025
May 2025
May 2025
Tools
Tools
Tools
Figma, ChatGPT
Figma, ChatGPT
Figma, ChatGPT
Platform
Platform
Platform
Web Application
Web Application
Web Application
Team
Team
Team
Versatile Agency
Versatile Agency
Versatile Agency
Overview
Overview
Overview
Why this Product
exists
Why this Product
exists
Why this Product
exists
A website can look perfectly fine while quietly breaking underneath.
A button might not work as expected. A JavaScript error might be sitting in the console. A network request might fail.
A page might have a layout issue on a particular screen size.
Performance might be degrading without anyone noticing.
Finding these problems manually takes time, and testing becomes even more difficult as products grow and teams ship more frequently.
BugSpy was created to automate part of that process.
Instead of relying entirely on manual testing, BugSpy uses browser automation to test websites, identify potential issues and provide teams with evidence they can investigate.
The challenge was turning a technically complex testing engine into a product that users could understand and act on without needing to interpret raw technical output.
A website can look perfectly fine while quietly breaking underneath.
A button might not work as expected. A JavaScript error might be sitting in the console. A network request might fail.
A page might have a layout issue on a particular screen size.
Performance might be degrading without anyone noticing.
Finding these problems manually takes time, and testing becomes even more difficult as products grow and teams ship more frequently.
BugSpy was created to automate part of that process.
Instead of relying entirely on manual testing, BugSpy uses browser automation to test websites, identify potential issues and provide teams with evidence they can investigate.
The challenge was turning a technically complex testing engine into a product that users could understand and act on without needing to interpret raw technical output.
A website can look perfectly fine while quietly breaking underneath.
A button might not work as expected. A JavaScript error might be sitting in the console. A network request might fail.
A page might have a layout issue on a particular screen size.
Performance might be degrading without anyone noticing.
Finding these problems manually takes time, and testing becomes even more difficult as products grow and teams ship more frequently.
BugSpy was created to automate part of that process.
Instead of relying entirely on manual testing, BugSpy uses browser automation to test websites, identify potential issues and provide teams with evidence they can investigate.
The challenge was turning a technically complex testing engine into a product that users could understand and act on without needing to interpret raw technical output.
My Role
My Role
My Role
I worked directly with the developer throughout the project.
I worked directly with the developer throughout the project.
I worked directly with the developer throughout the project.
My responsibilities included:
My responsibilities included:
My responsibilities included:
UX research
Product discovery
Asking and documenting key product questions
Information architecture
User flow definition
Onboarding
Test running experience
Dashboard UX design
Subscription
Analytics
Test history
Support
Billing
Settings
Profile
landing page
UX research
Product discovery
Asking and documenting key product questions
Information architecture
User flow definition
Onboarding
Test running experience
Dashboard UX design
Subscription
Analytics
Test history
Support
Billing
Settings
Profile
landing page
UX research
Product discovery
Asking and documenting key product questions
Information architecture
User flow definition
Onboarding
Test running experience
Dashboard UX design
Subscription
Analytics
Test history
Support
Billing
Settings
Profile
landing page
Problem & Solution
Problem & Solution
Problem & Solution
What we were
solving
What we were
solving
What we were
solving
The Problem
The Problem
The Problem
Website testing can become repetitive, fragmented and difficult to monitor..
For developers and QA teams
Testing repeatedly across websites takes time.
Issues can exist across different parts of the experience.
Console and network errors aren't always immediately visible.
Performance problems can be difficult to spot manually.
Test results need to be recorded and compared over time.
Teams need a clear history of what has already been tested.
The product challenge
BugSpy needed to make automated testing feel simple.
A user should be able to:
Set up a test → Run it → Understand what happened → Investigate issues → Track results
without having to understand how the automation works underneath.
Website testing can become repetitive, fragmented and difficult to monitor.
For Flexrs
Personal users
Administrators
Affiliates
Cross-border transfers
Wallets
Currency conversion
Stablecoins
Deposits
Withdrawals
Bulk transfers
Team management
Transaction tracking
The product also needed to communicate financial information clearly enough that users could trust the system.
Website testing can become repetitive, fragmented and difficult to monitor.
For developers and QA teams:
Testing repeatedly across websites takes time.
Issues can exist across different parts of the experience.
Console and network errors aren't always immediately visible.
Performance problems can be difficult to spot manually.
Test results need to be recorded and compared over time.
Teams need a clear history of what has already been tested.
The product challenge
BugSpy needed to make automated testing feel simple.
A user should be able to:
Set up a test → Run it → Understand what happened → Investigate issues → Track results
Defining The Product
Defining The Product
Defining The Product
The initial challenge wasn't just designing a dashboard.
I first needed to understand what BugSpy was actually doing behind the interface and what information users would need to make decisions from the results.
I worked closely with the developer to understand the testing engine, the types of errors it could detect and the information available after a test was completed.
That shaped the product around three core questions:
What did we test?
Give users visibility into the test that was run.
What did we find?
Surface UI issues, console errors, network errors and performance signals.
What should I do next?
Make the results clear enough for users to investigate and act on.
The initial challenge wasn't just designing a dashboard.
I first needed to understand what BugSpy was actually doing behind the interface and what information users would need to make decisions from the results.
I worked closely with the developer to understand the testing engine, the types of errors it could detect and the information available after a test was completed.
That shaped the product around three core questions:
What did we test?
Give users visibility into the test that was run.
What did we find?
Surface UI issues, console errors, network errors and performance signals.
What should I do next?
Make the results clear enough for users to investigate and act on.
The initial challenge wasn't just designing a dashboard.
I first needed to understand what BugSpy was actually doing behind the interface and what information users would need to make decisions from the results.
I worked closely with the developer to understand the testing engine, the types of errors it could detect and the information available after a test was completed.
That shaped the product around three core questions:
What did we test?
Give users visibility into the test that was run.
What did we find?
Surface UI issues, console errors, network errors and performance signals.
What should I do next?
Make the results clear enough for users to investigate and act on.
Design Process
Design Process
Design Process
From Idea to
Product
From Idea to
Product
From Idea to
Product
Understanding the Technology
Understanding the Technology
Understanding the Technology
Before designing the experience, I needed to understand what happened when a test was actually run.
What does BugSpy check?
What does a successful test look like?
What happens when something fails?
What information should users see?
Which results require immediate attention?
These questions helped establish the foundation for the product experience.
Before designing the experience, I needed to understand what happened when a test was actually run.
What does BugSpy check?
What does a successful test look like?
What happens when something fails?
What information should users see?
Which results require immediate attention?
These questions helped establish the foundation for the product experience.
Before designing the experience, I needed to understand what happened when a test was actually run.
What does BugSpy check?
What does a successful test look like?
What happens when something fails?
What information should users see?
Which results require immediate attention?
These questions helped establish the foundation for the product experience.
Mapping the User Journey
Mapping the User Journey
Mapping the User Journey
The core journey became:
Sign up → Set up test → Run test → Review results → Track history → Analyze performance
This became the backbone of the application.
The core journey became:
Sign up → Set up test → Run test → Review results → Track history → Analyze performance
This became the backbone of the application.
The core journey became:
Sign up → Set up test → Run test → Review results → Track history → Analyze performance
This became the backbone of the application.
Designing the Dashboard
Designing the Dashboard
Designing the Dashboard
The dashboard needed to give users a quick understanding of their testing activity without overwhelming them with technical information.
I designed it around the information users would most likely need at a glance:
Recent tests
Test status
Detected issues
Performance information
Testing activity
Access to previous results
The goal was to make the dashboard useful without turning it into a wall of metrics.
The dashboard needed to give users a quick understanding of their testing activity without overwhelming them with technical information.
I designed it around the information users would most likely need at a glance:
Recent tests
Test status
Detected issues
Performance information
Testing activity
Access to previous results
The goal was to make the dashboard useful without turning it into a wall of metrics.
The dashboard needed to give users a quick understanding of their testing activity without overwhelming them with technical information.
I designed it around the information users would most likely need at a glance:
Recent tests
Test status
Detected issues
Performance information
Testing activity
Access to previous results
The goal was to make the dashboard useful without turning it into a wall of metrics.
Designing the Test Workflow
Designing the Test Workflow
Designing the Test Workflow
Because BugSpy was still at the design and development planning stage, I focused on defining how users would interact with the testing functionality rather than validating it through live product usage.
Working with the developer, I mapped out the expected journey from setting up a website test to reviewing the information that would eventually be generated.
Because BugSpy was still at the design and development planning stage, I focused on defining how users would interact with the testing functionality rather than validating it through live product usage.
Working with the developer, I mapped out the expected journey from setting up a website test to reviewing the information that would eventually be generated.
Because BugSpy was still at the design and development planning stage, I focused on defining how users would interact with the testing functionality rather than validating it through live product usage.
Working with the developer, I mapped out the expected journey from setting up a website test to reviewing the information that would eventually be generated.
Design Process
Design Process
Design Process
Key product
decisons
Key product
decisons
Key product
decisons
Make money movement predictable.
Make money movement predictable.
Make money movement predictable.
The send-money experience needed to answer the questions users naturally have:
How much am I sending? What will I receive? What rate am I getting?
What fees apply? Where is the money going?
This led to a clearer transaction flow and better visibility of relevant information before confirmation.
The send-money experience needed to answer the questions users naturally have:
How much am I sending? What will I receive? What rate am I getting?
What fees apply? Where is the money going?
This led to a clearer transaction flow and better visibility of relevant information before confirmation.
The send-money experience needed to answer the questions users naturally have:
How much am I sending? What will I receive? What rate am I getting?
What fees apply? Where is the money going?
This led to a clearer transaction flow and better visibility of relevant information before confirmation.
Transaction states needed to be explicit.
Transaction states needed to be explicit.
Transaction states needed to be explicit.
Financial transactions don't simply succeed or fail.
They can be pending, processing, completed, failed, cancelled or require attention.
We introduced clearer transaction states so users could understand what was happening without guessing.
Financial transactions don't simply succeed or fail.
They can be pending, processing, completed, failed, cancelled or require attention.
We introduced clearer transaction states so users could understand what was happening without guessing.
Financial transactions don't simply succeed or fail.
They can be pending, processing, completed, failed, cancelled or require attention.
We introduced clearer transaction states so users could understand what was happening without guessing.
Trust starts with transparency.
Trust starts with transparency.
Trust starts with transparency.
Live rates, clearer transaction information and stronger hierarchy weren't just visual improvements.
They were trust mechanisms.
When money is involved, clarity is part of the product experience.
Live rates, clearer transaction information and stronger hierarchy weren't just visual improvements.
They were trust mechanisms.
When money is involved, clarity is part of the product experience.
Live rates, clearer transaction information and stronger hierarchy weren't just visual improvements.
They were trust mechanisms.
When money is involved, clarity is part of the product experience.
Complexity belongs behind the interface.
Complexity belongs behind the interface.
Complexity belongs behind the interface.
OneRemit has a lot happening underneath.
The interface shouldn't force users to understand the underlying complexity.
The goal was to make sophisticated financial operations feel straightforward.
OneRemit has a lot happening underneath.
The interface shouldn't force users to understand the underlying complexity.
The goal was to make sophisticated financial operations feel straightforward.
OneRemit has a lot happening underneath.
The interface shouldn't force users to understand the underlying complexity.
The goal was to make sophisticated financial operations feel straightforward.
Impact
Impact
Impact
What the
work achieved
What the
work achieved
What the
work achieved
BugSpy is currently in the design and development stage.
I established the core product experience and mapped the major journeys required for the MVP, including:
BugSpy is currently in the design and development stage.
I established the core product experience and mapped the major journeys required for the MVP, including:
BugSpy is currently in the design and development stage.
I established the core product experience and mapped the major journeys required for the MVP, including:
Authentication & Dashboard
Authentication & Dashboard
Authentication & Dashboard
Test setup, Test workflow, & Test history
Test setup, Test workflow, & Test history
Test setup, Test workflow, & Test history
Analytics, Account settings, Profile, Support, Subscription, & Billing
Analytics, Account settings, Profile, Support, Subscription, & Billing
Analytics, Account settings, Profile, Support, Subscription, & Billing
A detailed landing page for users to understand what BugSpy is and start their journey into test running.
A detailed landing page for users to understand what BugSpy is and start their journey into test running.
A detailed landing page for users to understand what BugSpy is and start their journey into test running.
Reflection
Reflection
Reflection
Key learnings
Key learnings
Key learnings
BugSpy strengthened my ability to design for technical products where the underlying system is significantly more complex than the interface users see.
One of the biggest lessons was that good developer-tool design isn't about exposing more technical information. It's about exposing the right information at the right moment.
Working directly with the developer also reinforced the value of asking questions early. Understanding how the technology works before designing the experience made it easier to identify constraints, challenge assumptions and create flows that were realistic to build. The project reminded me that as a product designer, I don't need to be the person writing the automation engine.
I need to understand enough about it to design the experience around it intelligently.
BugSpy strengthened my ability to design for technical products where the underlying system is significantly more complex than the interface users see.
One of the biggest lessons was that good developer-tool design isn't about exposing more technical information.
It's about exposing the right information at the right moment.
Working directly with the developer also reinforced the value of asking questions early. Understanding how the technology works before designing the experience made it easier to identify constraints, challenge assumptions and create flows that were realistic to build.
The project reminded me that as a product designer, I don't need to be the person writing the automation engine.
I need to understand enough about it to design the experience around it intelligently.
BugSpy strengthened my ability to design for technical products where the underlying system is significantly more complex than the interface users see.
One of the biggest lessons was that good developer-tool design isn't about exposing more technical information. It's about exposing the right information at the right moment.
Working directly with the developer also reinforced the value of asking questions early. Understanding how the technology works before designing the experience made it easier to identify constraints, challenge assumptions and create flows that were realistic to build.
The project reminded me that as a product designer, I don't need to be the person writing the automation engine.
I need to understand enough about it to design the experience around it intelligently.
Next Project
Next Project
