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

Sole Designer and Co-Founder
Product Thinking, End-to-End Product Design, Brand and Visual Design

Sole Designer and Co-Founder — Product Thinking, End-to-End Product Design, Brand and Visual Design

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

EXPLORING DIFFERENT PROBLEM SPACES THROUGH USER RESEARCH

EXPLORING DIFFERENT PROBLEM SPACES THROUGH USER RESEARCH

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

Network and console logs provide context on what's going on behind the scenes.

Network and console logs provide context on what's going on behind the scenes.

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