DevTools IDE
Product Designer
Web Data Extraction
Inspired by IDEs, I designed a developer-focused app to troubleshoot webpages and solve the issues of switching between multiple browser tools. I collaborated with product leaders and developers to research, understand their problems, and brainstorm ways to improve developer workflow efficiency.
DevTools IDE
Product Designer
Web Data Extraction
Inspired by IDEs, I designed a developer-focused app to troubleshoot webpages and solve the issues of switching between multiple browser tools. I collaborated with product leaders and developers to research, understand their problems, and brainstorm ways to improve developer workflow efficiency.
DevTools IDE
Product Designer
Web Data Extraction
Inspired by IDEs, I designed a developer-focused app to troubleshoot webpages and solve the issues of switching between multiple browser tools.
DevTools IDE
Product Designer
Web Data Extraction
Inspired by IDEs, I designed a developer-focused app to troubleshoot webpages and solve the issues of switching between multiple browser tools. I collaborated with product leaders and developers to research, understand their problems, and brainstorm ways to improve developer workflow efficiency.
5+
Tools consolidated
MVP
Shipped
Figma
Primary tool
2022
Year
5+
Tools consolidated
MVP
Shipped
Figma
Primary tool
2022
Year
5+
Tools consolidated
MVP
Shipped
Figma
Primary tool
2022
Year
Challenge
A Fragmented Workflow
Web scraping sounds simple until you're actually doing it. Developers using Puppeteer and Playwright to run headless browsers were juggling four or five different windows just to figure out why a page wasn't rendering correctly. The process was fragmented, slow, and frustrating, especially when you're trying to move fast. My job was to understand exactly where the friction lived, and design something that made it disappear.
Challenge
A Fragmented Workflow
Web scraping sounds simple until you're actually doing it. Developers using Puppeteer and Playwright to run headless browsers were juggling four or five different windows just to figure out why a page wasn't rendering correctly. The process was fragmented, slow, and frustrating, especially when you're trying to move fast. My job was to understand exactly where the friction lived, and design something that made it disappear.
Challenge
A Fragmented Workflow
Web scraping sounds simple until you're actually doing it. Developers using Puppeteer and Playwright to run headless browsers were juggling four or five different windows just to figure out why a page wasn't rendering correctly. The process was fragmented, slow, and frustrating, especially when you're trying to move fast. My job was to understand exactly where the friction lived, and design something that made it disappear.
Challenge
A Fragmented Workflow
Web scraping sounds simple until you're actually doing it. Developers using Puppeteer and Playwright to run headless browsers were juggling four or five different windows just to figure out why a page wasn't rendering correctly. The process was fragmented, slow, and frustrating, especially when you're trying to move fast. My job was to understand exactly where the friction lived, and design something that made it disappear.
Developer workflow involves heavy context switching between developer tools. Three to five windows open at once just to debug a single page. This was the starting point.
Developer workflow involves heavy context switching between developer tools. Three to five windows open at once just to debug a single page. This was the starting point.
Developer workflow involves heavy context switching between developer tools. Three to five windows open at once just to debug a single page. This was the starting point.
DESIGN PROCESS
From Research to Shipped Product
01
5W1H alignment
Got the team asking the same questions before any research began.
02
User interviews
Talked to developers who were living the problem every day.
03
Affinity mapping
Grouped raw data into patterns and surfaced what mattered most.
04
Storyboard and wireframe
Mapped the user journey before touching high-fidelity.
DESIGN PROCESS
From Research to Shipped Product
01
5W1H alignment
Got the team asking the same questions before any research began.
02
User interviews
Talked to developers who were living the problem every day.
03
Affinity mapping
Grouped raw data into patterns and surfaced what mattered most.
04
Storyboard and wireframe
Mapped the user journey before touching high-fidelity.
DESIGN PROCESS
From Research to Shipped Product
01
5W1H alignment
Got the team asking the same questions before any research began.
02
User interviews
Talked to developers who were living the problem every day.
03
Affinity mapping
Grouped raw data into patterns and surfaced what mattered most.
04
Storyboard and wireframe
Mapped the user journey before touching high-fidelity.
DESIGN PROCESS
From Research to Shipped Product
01
5W1H alignment
Got the team asking the same questions before any research began.
02
User interviews
Talked to developers who were living the problem every day.
03
Affinity mapping
Grouped raw data into patterns and surfaced what mattered most.
04
Storyboard and wireframe
Mapped the user journey before touching high-fidelity.
Research
Aligning the Team with 5W1H
Before any research happened, I needed to make sure the team was asking the same questions. I used the 5W1H framework to get everyone aligned on what we were building and why.
Why are we building this? Who's going to use it? When and where does the frustration actually happen? What does the solution look like? How will we know if it worked? Simple questions, but asking them out loud together as a team saves you weeks of going in the wrong direction.
Alignment
The 5W1H session became the north star for every decision that followed.
Research
Aligning the Team with 5W1H
Before any research happened, I needed to make sure the team was asking the same questions. I used the 5W1H framework to get everyone aligned on what we were building and why.
Why are we building this? Who's going to use it? When and where does the frustration actually happen? What does the solution look like? How will we know if it worked? Simple questions, but asking them out loud together as a team saves you weeks of going in the wrong direction.
Alignment
The 5W1H session became the north star for every decision that followed.
Research
Aligning the Team with 5W1H
Before any research happened, I needed to make sure the team was asking the same questions. I used the 5W1H framework to get everyone aligned on what we were building and why.
Why are we building this? Who's going to use it? When and where does the frustration actually happen? What does the solution look like? How will we know if it worked? Simple questions, but asking them out loud together as a team saves you weeks of going in the wrong direction.
Alignment
The 5W1H session became the north star for every decision that followed.
Research
Aligning the Team with 5W1H
Before any research happened, I needed to make sure the team was asking the same questions. I used the 5W1H framework to get everyone aligned on what we were building and why.
Why are we building this? Who's going to use it? When and where does the frustration actually happen? What does the solution look like? How will we know if it worked? Simple questions, but asking them out loud together as a team saves you weeks of going in the wrong direction.
Alignment
The 5W1H session became the north star for every decision that followed.
RESEARCH
Talking to Developers
I went straight to the source. I conducted interviews with the developers who were living this problem every day, not to validate assumptions, but to understand their world before forming any.
My favourite kind of interview question is an open one. Tell me about the last time you had to debug a page. Walk me through what that looked like. What slowed you down? What did you wish existed?
Too much context switching
Bouncing between four or five windows was the single biggest source of friction.
No unified environment
Tools existed but none of them talked to each other or lived in the same place.
Strong IDE mental model
Years of working in VS Code meant developers had clear expectations for how a tool should behave.
Tools built around them, not for them
Existing solutions required too much adaptation. Developers wanted something that felt native.
Interview and Affinity Mapping
Raw interview notes, messy on purpose. The patterns only show up when you sit with all of it at once. Themes grouped and surfaced.
RESEARCH
Talking to Developers
I went straight to the source. I conducted interviews with the developers who were living this problem every day, not to validate assumptions, but to understand their world before forming any.
My favourite kind of interview question is an open one. Tell me about the last time you had to debug a page. Walk me through what that looked like. What slowed you down? What did you wish existed?
Too much context switching
Bouncing between four or five windows was the single biggest source of friction.
No unified environment
Tools existed but none of them talked to each other or lived in the same place.
Strong IDE mental model
Years of working in VS Code meant developers had clear expectations for how a tool should behave.
Tools built around them, not for them
Existing solutions required too much adaptation. Developers wanted something that felt native.
Interview and Affinity Mapping
Raw interview notes, messy on purpose. The patterns only show up when you sit with all of it at once. Themes grouped and surfaced.
RESEARCH
Talking to Developers
I went straight to the source. I conducted interviews with the developers who were living this problem every day, not to validate assumptions, but to understand their world before forming any.
My favourite kind of interview question is an open one. Tell me about the last time you had to debug a page. Walk me through what that looked like. What slowed you down? What did you wish existed?
Too much context switching
Bouncing between four or five windows was the single biggest source of friction.
No unified environment
Tools existed but none of them talked to each other or lived in the same place.
Strong IDE mental model
Years of working in VS Code meant developers had clear expectations for how a tool should behave.
Tools built around them, not for them
Existing solutions required too much adaptation. Developers wanted something that felt native.
Interview and Affinity Mapping
Raw interview notes, messy on purpose. The patterns only show up when you sit with all of it at once. Themes grouped and surfaced.
RESEARCH
Talking to Developers
I went straight to the source. I conducted interviews with the developers who were living this problem every day, not to validate assumptions, but to understand their world before forming any.
My favourite kind of interview question is an open one. Tell me about the last time you had to debug a page. Walk me through what that looked like. What slowed you down? What did you wish existed?
Too much context switching
Bouncing between four or five windows was the single biggest source of friction.
No unified environment
Tools existed but none of them talked to each other or lived in the same place.
Strong IDE mental model
Years of working in VS Code meant developers had clear expectations for how a tool should behave.
Tools built around them, not for them
Existing solutions required too much adaptation. Developers wanted something that felt native.
Interview and Affinity Mapping
Raw interview notes, messy on purpose. The patterns only show up when you sit with all of it at once. Themes grouped and surfaced.
Design Solutions
Storyboarding and Wireframes
Before wireframing anything, I storyboarded the user journey. Not the happy path, the real one. What's the developer doing right before they open this tool? What are they feeling? What do they need to happen in the next 60 seconds?
Developers already have a deeply ingrained mental model from years of working in IDEs. I leaned into that hard. The layout wasn't meant to teach them anything new. It was meant to feel instantly familiar the moment they opened it.
Storyboard
Getting out of the UI and into the actual moment. What is the developer thinking right before they open this?
Wireframe
Layout built around the IDE mental model. Familiar structure, no learning curve which make tasks efficient.
Task Flow
Walking through the exact steps a developer takes to debug a page. Pressure testing the logic before going high-fidelity.
Design Solutions
Storyboarding and Wireframes
Before wireframing anything, I storyboarded the user journey. Not the happy path, the real one. What's the developer doing right before they open this tool? What are they feeling? What do they need to happen in the next 60 seconds?
Developers already have a deeply ingrained mental model from years of working in IDEs. I leaned into that hard. The layout wasn't meant to teach them anything new. It was meant to feel instantly familiar the moment they opened it.
Storyboard
Getting out of the UI and into the actual moment. What is the developer thinking right before they open this?
Wireframe
Layout built around the IDE mental model. Familiar structure, no learning curve which make tasks efficient.
Task Flow
Walking through the exact steps a developer takes to debug a page. Pressure testing the logic before going high-fidelity.
Design Solutions
Storyboarding and Wireframes
Before wireframing anything, I storyboarded the user journey. Not the happy path, the real one. What's the developer doing right before they open this tool? What are they feeling? What do they need to happen in the next 60 seconds?
Developers already have a deeply ingrained mental model from years of working in IDEs. I leaned into that hard. The layout wasn't meant to teach them anything new. It was meant to feel instantly familiar the moment they opened it.
Storyboard
Getting out of the UI and into the actual moment. What is the developer thinking right before they open this?
Wireframe
Layout built around the IDE mental model. Familiar structure, no learning curve which make tasks efficient.
Task Flow
Walking through the exact steps a developer takes to debug a page. Pressure testing the logic before going high-fidelity.
Design Solutions
Storyboarding and Wireframes
Before wireframing anything, I storyboarded the user journey. Not the happy path, the real one. What's the developer doing right before they open this tool? What are they feeling? What do they need to happen in the next 60 seconds?
Developers already have a deeply ingrained mental model from years of working in IDEs. I leaned into that hard. The layout wasn't meant to teach them anything new. It was meant to feel instantly familiar the moment they opened it.
Storyboard
Getting out of the UI and into the actual moment. What is the developer thinking right before they open this?
Wireframe
Layout built around the IDE mental model. Familiar structure, no learning curve which make tasks efficient.
Task Flow
Walking through the exact steps a developer takes to debug a page. Pressure testing the logic before going high-fidelity.
Visual and UI Design
Designing for a Developer's World
Before touching a single screen, I built the component library that would power the entire product. Spacing scales, typography, interactive states, and colour decisions all documented and ready for the team to build from. Having the system in place first meant every UI decision that followed was consistent, intentional, and fast to implement.
Working with the fundamental elements of visual design and arranging them according to design principles, they form the building blocks of everything you see in the product. Learning to achieve consistency across a growing interface is what separates a product that feels designed from one that just feels built.
Visual and UI Design
Designing for a Developer's World
Before touching a single screen, I built the component library that would power the entire product. Spacing scales, typography, interactive states, and colour decisions all documented and ready for the team to build from. Having the system in place first meant every UI decision that followed was consistent, intentional, and fast to implement.
Working with the fundamental elements of visual design and arranging them according to design principles, they form the building blocks of everything you see in the product. Learning to achieve consistency across a growing interface is what separates a product that feels designed from one that just feels built.
Visual and UI Design
Designing for a Developer's World
Before touching a single screen, I built the component library that would power the entire product. Spacing scales, typography, interactive states, and colour decisions all documented and ready for the team to build from. Having the system in place first meant every UI decision that followed was consistent, intentional, and fast to implement.
Working with the fundamental elements of visual design and arranging them according to design principles, they form the building blocks of everything you see in the product. Learning to achieve consistency across a growing interface is what separates a product that feels designed from one that just feels built.
Visual and UI Design
Designing for a Developer's World
Before touching a single screen, I built the component library that would power the entire product. Spacing scales, typography, interactive states, and colour decisions all documented and ready for the team to build from. Having the system in place first meant every UI decision that followed was consistent, intentional, and fast to implement.
Working with the fundamental elements of visual design and arranging them according to design principles, they form the building blocks of everything you see in the product. Learning to achieve consistency across a growing interface is what separates a product that feels designed from one that just feels built.
The MVP
One Tab. No More Switching.
The first release brought the core debugging workflow into one place. API parameters, raw HTML elements, and application logs. One tab. No more switching.
Features
API parameters to debug and test webpages directly in the interface. Elements panel returns raw HTML, just like Chrome DevTools but fully integrated. Logs give developers a view behind the scenes of the application in real time.
Actions
Simulates real human-browser behaviour so developers can reproduce rendering issues without throwaway scripts.
Scripts
Custom automation and a standard library of pre-built functions for advanced use cases.
The MVP
One Tab. No More Switching.
The first release brought the core debugging workflow into one place. API parameters, raw HTML elements, and application logs. One tab. No more switching.
Features
API parameters to debug and test webpages directly in the interface. Elements panel returns raw HTML, just like Chrome DevTools but fully integrated. Logs give developers a view behind the scenes of the application in real time.
Actions
Simulates real human-browser behaviour so developers can reproduce rendering issues without throwaway scripts.
Scripts
Custom automation and a standard library of pre-built functions for advanced use cases.
The MVP
One Tab. No More Switching.
The first release brought the core debugging workflow into one place. API parameters, raw HTML elements, and application logs. One tab. No more switching.
Features
API parameters to debug and test webpages directly in the interface. Elements panel returns raw HTML, just like Chrome DevTools but fully integrated. Logs give developers a view behind the scenes of the application in real time.
Actions
Simulates real human-browser behaviour so developers can reproduce rendering issues without throwaway scripts.
Scripts
Custom automation and a standard library of pre-built functions for advanced use cases.
The MVP
One Tab. No More Switching.
The first release brought the core debugging workflow into one place. API parameters, raw HTML elements, and application logs. One tab. No more switching.
Features
API parameters to debug and test webpages directly in the interface. Elements panel returns raw HTML, just like Chrome DevTools but fully integrated. Logs give developers a view behind the scenes of the application in real time.
Actions
Simulates real human-browser behaviour so developers can reproduce rendering issues without throwaway scripts.
Scripts
Custom automation and a standard library of pre-built functions for advanced use cases.
FIGMA PROTOTYPE
Conclusion
What This Project Taught Me
Working closely with the Product Manager and dev team throughout, not just at handoff, was what made the difference. The tool was better because the people building it were part of shaping it from the start.
01
Respect existing mental models. Don't teach developers a new way to work. Meet them where they already are.
02
Developers are the best testers. They give direct, honest feedback and they notice everything.
03
Collaborate throughout, not just at handoff. The best ideas came from conversations, not from design reviews.
Conclusion
What This Project Taught Me
Working closely with the Product Manager and dev team throughout, not just at handoff, was what made the difference. The tool was better because the people building it were part of shaping it from the start.
Respect existing mental models. Don't teach developers a new way to work. Meet them where they already are.
Developers are the best testers. They give direct, honest feedback and they notice everything.
Collaborate throughout, not just at handoff. The best ideas came from conversations, not from design reviews.
Conclusion
What This Project Taught Me
Working closely with the Product Manager and dev team throughout, not just at handoff, was what made the difference. The tool was better because the people building it were part of shaping it from the start.
01
Respect existing mental models. Don't teach developers a new way to work. Meet them where they already are.
02
Developers are the best testers. They give direct, honest feedback and they notice everything.
03
Collaborate throughout, not just at handoff. The best ideas came from conversations, not from design reviews.
Conclusion
What This Project Taught Me
Working closely with the Product Manager and dev team throughout, not just at handoff, was what made the difference. The tool was better because the people building it were part of shaping it from the start.
Respect existing mental models. Don't teach developers a new way to work. Meet them where they already are.
Developers are the best testers. They give direct, honest feedback and they notice everything.
Collaborate throughout, not just at handoff. The best ideas came from conversations, not from design reviews.