Building momentum through design.

StreetFair Design System

StreetFair Design System

Automatically send mailers to the closest homes after a job is scheduled in your scheduling system or StreetFair.

 
 

Project Details

Company
StreetFair

Project Length
Ongoing

Team
Christian H. (Engineering)
Owen C. (Engineering)


My Role

  • x


Opportunity

Capitalize on the leads we capture and allow them to trigger automated marketing mailers (something home service providers already do manually) with existing tools.


Process

Discover

  • Understand the feature and its domain model

  • Initial User Interviews (external)

  • Initial User Interviews (internal)

  • Market Research

Define

  • Confirm Feature Inventory

  • Engineering Review

Develop

  • Usability testing (internal users)

  • Usability testing (external users)

  • Iteration

Deliver

  • Final Usability Testing

  • Work through variations of the flow based on client settings and user permissions.

  • Update Design System

  • Setup Analytics

 

 

Discover

Over the first month, Blake and I, chatted with curious providers about marketing broadly and then dove into their experience, and the ROI, of physical mailing campaigns. It then became clear what tools were the the most used (DOPE Marketing and SendJim) so we set our sites on learning what those tools capabilities were and contrasting them with what providers really hoped to be able to do.

Competitor review of SendJim’s Radius Bomb and EDDM (Every Door Delivery Mail) features. Each offered different ways to send mailers and moderate cost but neither were automatically triggered, filters we’re at the zip code level, and triggers (to initiate a mailer) were limited.

A screenshot of our collaborative requirement doc for StreetBlasts. In this doc we recorded links to user interview transcripts, personal notes and takeaways from those same interviews, and organized and prioritized requirements we saw in the market and heard from users.

 

Define (using v0!)

v0 has been an excellent way to define requirements with actual interface. Given this AI tool’s ease of use and speed, the prototype itself quickly became our product requirement doc. When needed, we would fork version of the prototype as we nurtured the main version along through interview after interview until it became clear what the ultimate vision should be and what the first version, the MVP, should be.

 

The planned MVP version developed in v0. We shared this in user interviews to nail down the exact minimum viable version of this feature and which user cohort it would be most valuable for.

The second iteration of the feature, developed in the same v0 prototype as the MVP so we could validate both versions with users and examine feasibility with engineering.

 

Develop

At this x

 

xx

x

 

Deliver

Withx

 

x

x

Results

This feature released its Beta in Aug. 2025 and the data is still coming in! (This was updated Mid aug 2025

 

Beta Users

6+

Beta Users

6+