DevTools IDE
Product Designer
Web Data Extraction
Inspired by IDEs, we 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, we 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 always seems easy at first, but once you dive in, it gets messy fast. I saw devs using Puppeteer and Playwright, bouncing between a bunch of windows just to debug why a page wouldn't load right. The whole process felt clunky and slow, which is the last thing you want when you're trying to move quickly. My goal was to figure out exactly what was getting in the way and design something that just made those pain points go away.
Challenge
A Fragmented Workflow
Web scraping always seems easy at first, but once you dive in, it gets messy fast. I saw devs using Puppeteer and Playwright, bouncing between a bunch of windows just to debug why a page wouldn't load right. The whole process felt clunky and slow, which is the last thing you want when you're trying to move quickly. My goal was to figure out exactly what was getting in the way and design something that just made those pain points go away.
Challenge
A Fragmented Workflow
Web scraping always seems easy at first, but once you dive in, it gets messy fast. I saw devs using Puppeteer and Playwright, bouncing between a bunch of windows just to debug why a page wouldn't load right. The whole process felt clunky and slow, which is the last thing you want when you're trying to move quickly. My goal was to figure out exactly what was getting in the way and design something that just made those pain points go away.
Challenge
A Fragmented Workflow
Web scraping always seems easy at first, but once you dive in, it gets messy fast. I saw devs using Puppeteer and Playwright, bouncing between a bunch of windows just to debug why a page wouldn't load right. The whole process felt clunky and slow, which is the last thing you want when you're trying to move quickly. My goal was to figure out exactly what was getting in the way and design something that just made those pain points go away.
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 jumping into research, I wanted to make sure the team was on the same page. I kicked things off with a quick 5W1H session to get everyone clear on what we were building and why.
Why are we building this? Who's it for? When and where does the pain actually show up? What does a good solution even look like? How do we know if it works? These are basic questions, but talking them through as a team up front saves a ton of time later.
Alignment
The 5W1H session became the north star for every decision that followed.
Research
Aligning the Team with 5W1H
Before jumping into research, I wanted to make sure the team was on the same page. I kicked things off with a quick 5W1H session to get everyone clear on what we were building and why.
Why are we building this? Who's it for? When and where does the pain actually show up? What does a good solution even look like? How do we know if it works? These are basic questions, but talking them through as a team up front saves a ton of time later.
Alignment
The 5W1H session became the north star for every decision that followed.
Research
Aligning the Team with 5W1H
Before jumping into research, I wanted to make sure the team was on the same page. I kicked things off with a quick 5W1H session to get everyone clear on what we were building and why.
Why are we building this? Who's it for? When and where does the pain actually show up? What does a good solution even look like? How do we know if it works? These are basic questions, but talking them through as a team up front saves a ton of time later.
Alignment
The 5W1H session became the north star for every decision that followed.
Research
Aligning the Team with 5W1H
Before jumping into research, I wanted to make sure the team was on the same page. I kicked things off with a quick 5W1H session to get everyone clear on what we were building and why.
Why are we building this? Who's it for? When and where does the pain actually show up? What does a good solution even look like? How do we know if it works? These are basic questions, but talking them through as a team up front saves a ton of time later.
Alignment
The 5W1H session became the north star for every decision that followed.
RESEARCH
Talking to Developers
I started by talking to the developers who deal with this stuff every day. Instead of jumping in with my own ideas, I wanted to get a real sense of what their day-to-day looks like.
I like to keep my interview questions open. Stuff like, 'Tell me about the last time you had to debug a page.' I want to hear the whole story: what tripped you up, what you wish you had.
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 started by talking to the developers who deal with this stuff every day. Instead of jumping in with my own ideas, I wanted to get a real sense of what their day-to-day looks like.
I like to keep my interview questions open. Stuff like, 'Tell me about the last time you had to debug a page.' I want to hear the whole story: what tripped you up, what you wish you had.
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 started by talking to the developers who deal with this stuff every day. Instead of jumping in with my own ideas, I wanted to get a real sense of what their day-to-day looks like.
I like to keep my interview questions open. Stuff like, 'Tell me about the last time you had to debug a page.' I want to hear the whole story: what tripped you up, what you wish you had.
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 started by talking to the developers who deal with this stuff every day. Instead of jumping in with my own ideas, I wanted to get a real sense of what their day-to-day looks like.
I like to keep my interview questions open. Stuff like, 'Tell me about the last time you had to debug a page.' I want to hear the whole story: what tripped you up, what you wish you had.
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 jumping into wireframes, I mapped out the real user journey. Not just the ideal flow, but what actually happens. What is a developer doing right before they open this tool? How are they feeling? What do they need to get done in the next minute?
Developers already have years of muscle memory from working in IDEs, so I leaned into that. The layout wasn't about teaching anything new. It just needed to feel familiar right away.
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 jumping into wireframes, I mapped out the real user journey. Not just the ideal flow, but what actually happens. What is a developer doing right before they open this tool? How are they feeling? What do they need to get done in the next minute?
Developers already have years of muscle memory from working in IDEs, so I leaned into that. The layout wasn't about teaching anything new. It just needed to feel familiar right away.
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 jumping into wireframes, I mapped out the real user journey. Not just the ideal flow, but what actually happens. What is a developer doing right before they open this tool? How are they feeling? What do they need to get done in the next minute?
Developers already have years of muscle memory from working in IDEs, so I leaned into that. The layout wasn't about teaching anything new. It just needed to feel familiar right away.
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 jumping into wireframes, I mapped out the real user journey. Not just the ideal flow, but what actually happens. What is a developer doing right before they open this tool? How are they feeling? What do they need to get done in the next minute?
Developers already have years of muscle memory from working in IDEs, so I leaned into that. The layout wasn't about teaching anything new. It just needed to feel familiar right away.
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 I even started designing screens, I put together the component library that would drive the whole product. I set up spacing scales, typography, interactive states, and made all the color calls up front, so the team had everything ready to go. Getting the system sorted first made every UI decision after that way more consistent and a lot quicker to build.
I focused on the basics: visual design elements and how they fit together using solid design principles. These are the building blocks for everything in the product. Making sure things stay consistent as the interface grows is what makes a product feel designed, not just pieced together.
Visual and UI Design
Designing for a Developer's World
Before I even started designing screens, I put together the component library that would drive the whole product. I set up spacing scales, typography, interactive states, and made all the color calls up front, so the team had everything ready to go. Getting the system sorted first made every UI decision after that way more consistent and a lot quicker to build.
I focused on the basics: visual design elements and how they fit together using solid design principles. These are the building blocks for everything in the product. Making sure things stay consistent as the interface grows is what makes a product feel designed, not just pieced together.
Visual and UI Design
Designing for a Developer's World
Before I even started designing screens, I put together the component library that would drive the whole product. I set up spacing scales, typography, interactive states, and made all the color calls up front, so the team had everything ready to go. Getting the system sorted first made every UI decision after that way more consistent and a lot quicker to build.
I focused on the basics: visual design elements and how they fit together using solid design principles. These are the building blocks for everything in the product. Making sure things stay consistent as the interface grows is what makes a product feel designed, not just pieced together.
Visual and UI Design
Designing for a Developer's World
Before I even started designing screens, I put together the component library that would drive the whole product. I set up spacing scales, typography, interactive states, and made all the color calls up front, so the team had everything ready to go. Getting the system sorted first made every UI decision after that way more consistent and a lot quicker to build.
I focused on the basics: visual design elements and how they fit together using solid design principles. These are the building blocks for everything in the product. Making sure things stay consistent as the interface grows is what makes a product feel designed, not just pieced together.
The MVP
One Tab. No More Switching.
For the first release, we pulled together the main debugging information, such as API parameters, raw HTML, and app logs, into a single tab. No more jumping between different tools.
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.
For the first release, we pulled together the main debugging information, such as API parameters, raw HTML, and app logs, into a single tab. No more jumping between different tools.
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.
For the first release, we pulled together the main debugging information, such as API parameters, raw HTML, and app logs, into a single tab. No more jumping between different tools.
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.
For the first release, we pulled together the main debugging information, such as API parameters, raw HTML, and app logs, into a single tab. No more jumping between different tools.
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
The big win here was staying in sync with the PM and devs the whole way, not just tossing designs over the wall at handoff. The tool turned out way better since the folks actually building it helped shape it from day one.
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
The big win here was staying in sync with the PM and devs the whole way, not just tossing designs over the wall at handoff. The tool turned out way better since the folks actually building it helped shape it from day one.
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
The big win here was staying in sync with the PM and devs the whole way, not just tossing designs over the wall at handoff. The tool turned out way better since the folks actually building it helped shape it from day one.
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
The big win here was staying in sync with the PM and devs the whole way, not just tossing designs over the wall at handoff. The tool turned out way better since the folks actually building it helped shape it from day one.
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.