S N A G A J O B
Shifts
Snag Work2.0: Redesigning a gig
economy platform from the ground up.
Background
Snagajob as a company connected hourly workers to hourly work and operated like a jobs listing site. Unlike most job listings sites that you or I have looked at in the last few years, this one really serves a community that was left behind by the internet. Many of these workers still find their work through friends of friends, newspaper ads and tear-aways in coffee shops.
To tap into the “gig economy” an internal product lab was spun up to test a shift based idea where these individual workers (hired by Snagajob) could pick up single shifts at different businesses.
My role
I came into the project after some preliminary prototypes had been made by the external lab team. The project was brought back in house to focus on scalability & growth. I first looked at overhauling the employer facing side of the product, which had the most room for improvement compared to it’s worker-facing counterpart.
The Real Problems
I started by digging into feedback and usability data. The product was built without initial discovery, and once I joined, I began sorting through feedback and running continuous usability calls.
-
They couldn't make basic changes without calling support (uniform requirements, position descriptions, business information)
The navigation was suffering from "button blindness"—so many action buttons that users couldn't find what they needed
When shifts needed workers urgently, the "Request shift" button would be pushed below the fold, hidden by the very shifts that needed filling
No visibility into worker history or ability to request specific workers they'd worked with before
-
Teams were "white gloving" nearly every interaction. They were manually processing requests that employers should have been able to handle themselves
1-2 day turnaround times for simple changes (like updating uniform color) were preventing businesses from posting shifts
Support tickets revealed the same patterns repeatedly: employers wanting control, workers wanting better communication
-
Built outside core APIs and frontend platforms
Text notifications routed through third-party providers (Twilio) without proper queue management
Design patterns didn't align with company standards
Scalability was questionable
-
On my second week, I witnessed something while sitting in on a research session with workers. Seven people received a new shift alert text messages. But the messages arrived at different times, distributed haphazardly by mobile providers. Workers with names starting with letters later in the alphabet would get their notifications significantly later than others—sometimes too late to accept the shift.
This wasn't just a quirky bug. Workers were losing income opportunities because of alphabetical order. We had to fix it.
Reframing the Problem
My Product Manager and I mapped out all the pain points and opportunities across stakeholders: company objectives, operations team needs, sales team requests, employer feedback, and worker feedback. We organized everything into an opportunity tree to identify where we could make the biggest impact. We split opportunities into two categories:
"Just do its": Stakeholder requests (often from sales or operations)
Problems to solve: Issues validated through user research and data
"Just do its":
"Employers want to see workers after a shift" (sales request)
"Workers wanted to better communicate with employers before a job" (operations assumption)
"Employers wanted to voice who they DID and did NOT like so they HAD to stay if they had signed up for a shift in time" (punitive feature request)
Problems to solve:
Workers had no visibility into which shifts were actually available while creating requests
Employers couldn't update basic business information without support intervention
Navigation structure was preventing discovery of existing features
The request flow contradicted user mental models (date and time separated across screens)
Our prioritization
We focused on problems that would:
Reduce operational burden (enabling scale)
Give employers self-service capabilities
Maintain the simplicity that made v1 appealing
Align the product with company technical standards
The Big Rejection: Why We Killed the Scheduling Feature
Originally, we planned to expand Snag Work into a full employee scheduling tool. The idea made sense on paper: employers could import their permanent workers, schedule all shifts (both permanent staff and Snag Workers), and message employees—all in one place.
I spent weeks sketching and prototyping this expanded vision. The designs looked great. The feature set was compelling.
But when we talked to employers, we couldn't find anyone who needed both products. The employers using Snag Work were small operations with simple needs—they didn't want scheduling complexity. They wanted to request a shift and get a worker. That's it.
This was a critical moment: we could build something nobody asked for to justify the project's scope, or we could strip back to what users actually needed. We chose simplicity.
The lesson: Sometimes the best design decision is recognizing what not to build. This pivot saved months of development time and kept us focused on the core value proposition.
Navigation: Fighting Button Blindness
The original navigation was split between two small buttons at the top and a long list of large link buttons below. When you had upcoming shifts, these buttons pushed everything below the fold—including the primary action button to request a shift.
The exploration: We ran card sorting sessions with five employers and ten workers to understand their mental model of the information architecture. A few minor variations emerged, but the groupings were clear:
Shifts (view, request, manage)
Workers (roster, history)
Business (settings, billing, positions)
Account (personal profile)
The solution:
Desktop: Top navigation with clear categories (where most employers worked)
Mobile: Bottom navigation bar, persistent across screens (where most workers accessed the platform)
Persistent "Request shift" button that never disappeared below the fold (I fought hard for this)
Removed the "dashboard" concept entirely—the large profile photo taking up ⅓ of the screen added no value
What we kept from v1: The green "filled" indicator on upcoming shifts. At a glance, employers could see which shifts still needed workers and whether they needed to panic about tomorrow morning.
Request Flow: When Users Say One Thing But Do Another
Pre-launch research had suggested employers wanted to select workers across multiple dates separately—requesting three people for every Saturday and Sunday. The original flow split date and time across two screens to accommodate this.
But when I observed employers using the system, they consistently expected date and time together. What people said in research and what they actually did were different things.
The redesign:
Consolidated date and time selection onto a single screen
Added real-time worker availability indicators ("12 workers available for this shift") while employers were still creating the request
This transparency helped manage expectations—if Kimmy needed someone for July 4th, she could see only two workers were available before submitting
Simplified form fields to align with the company design system
Reduced cognitive load by following users' actual mental models
Validation: In usability sessions with the new flow, no one got hung up on the changes. They immediately jumped to their next request: sending shifts to specific workers. This told us we'd removed friction from the core interaction.
Roster: Putting Power in Employers' Hands
The worker roster page was underutilized in v1 because of navigation blindness, but it held enormous potential. Employers wanted to:
See worker history and performance
Request specific workers they'd worked with before
Remove workers from their roster
Make full-time job offers to reliable workers
We rebuilt this section to surface all these capabilities. The biggest wins:
Direct shift requests: Employers could now send shifts to specific workers (addressing the top research request)
Worker profiles: Showing shifts worked, ratings, training level, and position history
Job offers: Allowing employers to extend full-time positions to workers they wanted to hire permanently (something workers had been asking for)
Roster management: Simple tools to add/remove workers and update their positions
The broader impact: This feature started creating a flywheel—good workers got more shifts, employers built relationships with reliable workers, and workers had a path from gig work to permanent employment.
Business Settings: Self-Service at Scale
Operations was drowning in requests to change uniform colors, update position descriptions, or modify business information. These changes took 1-2 days to process, and the delay prevented businesses from requesting shifts.
If Kimmy needed workers to wear blue shirts instead of green ones, she shouldn't have to wait on the phone for someone to update the backend.
What we built:
Self-service editing of business information, locations, and uniform requirements
Manager role management (adding additional users)
Billing updates
Position management with guardrails
The careful constraint: While building position management, I was cautious about legal limitations. Snag Work couldn't support certain roles (like delivery drivers) due to liability. We built restrictions into the interface to prevent employers from creating positions the business couldn't legally support.
The scalability unlock: Eventually, we wanted employers to add entirely new businesses themselves—so when Kimmy expanded from ice cream to hot dogs, she could do it without our help.
Navigating Constraints and Curveballs
The W2 Transition: A Mid-Flight Redesign
Midway through the project, the company made a major decision: all workers would shift from 1099 contractors to full W2 employees by the end of the calendar year. This gave workers benefits and protections, but it required both the current product AND our new design to adjust for legal requirements.
The team absorbed another massive lift. Not only did we need to update the live product for compliance, but we had to rework the new designs to reflect the employment relationship change.
What changed:
How shifts were described and assigned
Worker status and classification displays
Billing and payment flows
Legal language throughout the experience
This was a reminder that product design rarely happens in a vacuum. External forces—legal, business, operational—constantly reshape the constraints you're working within.
The Web App Decision: Trading Native for Control
We chose to build Snag Work 2.0 as a web app that felt native on mobile, rather than building true native iOS and Android apps.
What we gave up:
Push notifications (we opted for text messages instead)
GPS integration
Some offline capabilities
App store presence
What we gained:
Hiring engineers who maintained things on the web
Single codebase for faster iteration
No app store approval delays
Consistent experience across devices
The critical insight: We realized controlling message delivery timing was more important than leveraging native push notifications. By routing text messages directly through our system rather than relying on mobile providers, we could send notifications to EVERYONE at the exact same time—eliminating the alphabetical chaos.
Obviously, texting had its own hiccups, but controlling the queue gave us predictability.
Design System Integration: Building for the Future
While overhauling Snag Work, I was simultaneously working on the company design system—a side-of-desk project that played into how everything was built.
The existing system was fairly small but set a good foundation. I mostly adapted existing patterns, but contributed platform-specific components back to the company design library (like the shift card UI and roster management patterns).
This parallel work ensured Snag Work 2.0 wasn't another isolated prototype—it was built with reusable components that could scale across Snagajob products.
What Changed
(and What I Learned)
-
The product launched in Fall 2019, after I left the team. Staying in touch with my former PM and Lead Engineer, I learned the transition went smoothly. The biggest win was exactly what we'd prioritized: employers could control their businesses themselves.
Operations saw immediate relief from the volume of simple requests. Employers discovered features they didn't know existed. The self-service tools unlocked growth that had been bottlenecked by manual processes.
-
The manager tools. Giving employers self-service capabilities fundamentally changed the relationship between the platform and its users. Instead of feeling dependent on support, employers had agency. That shift in control was more valuable than any individual feature.
The weekly research cadence. Those continuous usability sessions gave us the depth of insight needed to make smart decisions. Research wasn't a phase—it was a constant conversation with users that informed every sprint.
-
Ignore the success metrics section. In retrospect, I wish we'd defined clearer success criteria at kickoff. We knew what problems we were solving, but we didn't establish concrete metrics to measure impact. Without baseline data (completion rates, support ticket volume, time-to-request-shift), it was harder to prove the value of specific design decisions post-launch.
The text message problem could have been caught earlier. Watching those seven workers receive notifications at different times was eye-opening, but we could have uncovered this through more systematic monitoring of the existing product before diving into redesign. Sometimes the best research is just paying attention to what's already happening.
Protecting design time in operational chaos. There was no protecting design time—everyone just did what needed doing. The I-9 verifications and Jira cards and support calls were part of the reality. But in hindsight, this "no boundaries" approach gave me deeper empathy for every stakeholder. I understood operations' pain because I lived it. I understood workers' frustrations because I sat with them. That context made me a better designer, even if it made for chaotic weeks.
Key Takeaways
What users say and what users do are often different things.
Direct observation beats stated preferences.
Sometimes the best design is knowing what not to build.
Rejecting the scheduling feature saved months and kept the product focused.
Constraints force creativity.
The web app decision, the W2 transition, the text message chaos each shaped better solutions than we would have found in ideal conditions.
Self-service capabilities scale faster than perfect features.
Giving employers control had more impact than polishing individual workflows.
Weekly research creates compound insights.
Continuous conversation with users provided depth that one-off research sprints never could.