Startup Incubator — Spring 2023
Shipping the First Product I Worked On — Building a Developer Tool from 0 → 1 with a PM and Engineers
TIMELINE
4 Week Sprint
ROLE
TEAM
Bridget Bell (PM)
James Li (Developer)
Benran Zhang (Developer)
TOOLS
Figma
Notion
CONTEXT
Co-Founder First, Designer Second
Learning product design in a startup incubator environment
Before we did anything in Figma, we spent our first month simply as founders and thinking about problem spaces.
I developed a sense for product thinking and strategy before I created a single wireframe.
A few guiding questions
Is this a space we can take a unique stab at with our backgrounds and expertise?
Who are our competitors and how are they approaching the problem?
FIG. 1
4 Computer Science students find Founder-Market Fit in Dev Tools
All of our ideas had a common thread — solving problems for engineers and other technical people.
We had a deep understanding of how engineers think and interact with things.
We had a network of other technical folks to test and validate our idea.
PROBLEM (DEVELOPERS)
Tracking down the cause of software bugs is tedious.
It's difficult to connect how the problem manifests in the product with its root cause.
Russ
Senior Software Engineer
“It takes me forever to debug customer issues because I never know what actually happened, leaving both of us frustrated."
Jonathan
Startup Founder & Developer
“A user informed us that our website wasn't loading. But how did they get to that point? I couldn't do anything without more context."
KEY INSIGHT
User and team bug reporting is key to discovering issues, but developers need more context clues.
FIG. 2
Why would a company want to use Firefly?
Staying in touch with user issues
An active, evolving product taking in user feedback improves trust, loyalty, and ultimately retention.
Keeping up with fast product cycles
Many companies are using Agile or similar iterative processes. Getting feedback quickly is valuable in driving future sprints.
PROBLEM (END-USERS)
Existing feedback systems feel heavy and effortful
After doing an audit of existing feedback systems on websites, I found that they:
Often redirect attention away from the original problem (onto a separate webpage, hide parts of the website, etc.)
Have long processes that look complex and tedious to complete
Provide lots of empty boxes to fill, but users don't always have that much to say (Blank page problem)
It shouldn't be the user's job to do the heavy lifting.
Users are often non-technical
They probably don't know what info will be helpful for developers.
Reporting issues is already a big ask
We don't want to bog down users with extensive reporting processes.
SOLUTION HIGHLIGHT
Firefly is a rapid feedback and developer tool that connects user and team member bug reports with technical context clues for better debugging
Leave a comment anywhere on the website screen
This allows users and team members to give rapid feedback without leaving the page they were on.
Firefly bundles the comment with technical metadata in a dashboard
With technical information all-in-one place, developers can quickly start to piece together clues.
THE PROCESS
Leaning on my technical background to be a collaborator to my Developers
Learning about debugging workflows and jamming on features and layouts
As soon as we committed to our idea, I worked with my developers to flesh out a user flow and create rough wireframes.
I needed to understand the data we wanted to provide for developers and the best way to display it to our target audience — other engineers.
FIG. 3
Jamming with my teammates on what key technical context clues we wanted to display
Structuring an optimal design - development timeline
My developers and I lined up our timelines so that we would always have something ready to work on.
While I was working on UI designs, they could structure the backend and work on the functionality side of our product.
Shipped — with time to spare
Most LavaLab teams spend the last few days on "grind mode" trying to build out their MVP before Demo Day.
With our timeline, we had finished up our product 2 days before, so we focused on our product demo and pitch.
FIG. 4
A peek at our design-development timeline
Creating component libraries and touching up front-end interfaces
In order to keep a consistent visual language throughout the process, I continually updated a UI component library with iterations of our main elements.
Once the UI was almost fully implemented, I went in and annotated visual discrepancies to get them fixed.
Product-ception
I knew we were on the right track when I wished I could use Firefly to annotate these little visual changes!
FIG. 5
UI component library
FIG. 6
a screenshot i sent to my devs to fix visual problems on our deployed site
Maintaining website load times — keeping a lightweight feedback UI
Our product was going to be added onto existing sites as an SDK package. To avoid negatively affecting the load times or rendering of websites, we had to minimize the size of the package (especially through fewer font styles and smaller images).
Removed brand logo from default comment pins to reduce package size
Created outline for website window to gently show a change in state
FIG. 7
TESTING our tool deployed onto a fake site
Structuring an optimal design - development timeline
My developers and I lined up our timelines so that we would always have something ready to work on.
While I was working on UI designs, they could structure the backend and work on the functionality side of our product.
Shipped — with time to spare
Most LavaLab teams spend the last few days on "grind mode" trying to build out their MVP before Demo Day.
With our timeline, we had finished up our product 2 days before, so we focused on our product demo and pitch.
FIG. 4
A peek at our design-development timeline
Creating component libraries and touching up front-end interfaces
In order to keep a consistent visual language throughout the process, I continually updated a UI component library with iterations of our main elements.
Once the UI was almost fully implemented, I went in and annotated visual discrepancies to get them fixed.
Product-ception
I knew we were on the right track when I wished I could use Firefly to annotate these little visual changes!
FIG. 5
UI component library
FIG. 6
a screenshot i sent to my devs to fix visual problems on our deployed site
Maintaining website load times — keeping a lightweight feedback UI
Our product was going to be added onto existing sites as an SDK package. To avoid negatively affecting the load times or rendering of websites, we had to minimize the size of the package (especially through fewer font styles and smaller images).
Removed brand logo from default comment pins to reduce package size
Created outline for website window to gently show a change in state
FIG. 7
TESTING our tool deployed onto a fake site
RESULT
Shipped my first ever product — and won judge's choice along the way
FIG. 8
OUR TEAM with the judges post-demo day!
A few key points and takeaways from this project
Explore product spaces
Product design doesn’t happen in a void — explore what already exists and what stance it takes!
Design with implementation in mind
Continue leaning on my technical background to be a good cross-functional collaborator
Some things are just out of scope
Real-world projects with constraints means a much less linear design and development process
How would we have measured success?
More feedback with new product releases
An increase in feedback submission, especially around new releases when bugs are common
Faster debugging processes
Developers report faster debugging processes, with technical metadata provided playing a key role
What's next?
We all decided to move on and work on different things, but soon after our demo, we saw new releases from other tools around commenting and feedback, such as Vercel Comments!
THE FULL DESIGN PROCESS
There's a lot more to see behind the scenes
Please reach out to me if you'd like to learn more!
I typically walk people through more detailed research and design explorations in an interview environment or coffee chat.
Exploring User Feedback Methods
Forms, Widgets, Comments, etc.
Creating a Developer Interface
Exploring around familiar design patterns