Design that does
something.

Labor is the #1 cost center in the trades, and owners are stuck being the bank

FieldPay's own research with pool, HVAC, roofing, and pest-control owners was blunt about it: labor was their single biggest pain point, hiring cycles were running $1,600+ per replacement, and techs would leave for whoever paid fastest. Owners wanted to reward good work, cover a same-day emergency call, or incentivize a slow route, but doing it meant waiting for the next payroll run. The gap between "the job's done" and "you got paid" was where trust broke down.

A tight scope, held to on purpose

The engagement was three months, phased, with a defined deliverable at the end of each: workflows, then wireframes, then handoff-ready visual design for two apps, Admin and Talent. Marketing and brand work was explicitly out of scope, so the design effort stayed pointed at the product two founders and I reviewed together two to three times a week. Keeping that boundary is what let a three-month engagement produce two fully specified apps instead of one half-finished one.

Turning a product spec into flows two very different users could follow

The starting point was a founder-written product spec: campaigns (job-specific or general cash incentives), a mixed roster of W-2 and 1099 workers, proof-of-work requirements, and a payout lifecycle that had to stay auditable. My job was to map that into concrete paths, campaign creation, talent roster management, and campaign monitoring on the Admin side; opportunity discovery, claim, proof submission, and cash-out on the Talent side, before a single screen got drawn.

Admin App — Campaign Creation Flow

Business owner configures a cash incentive from a community template or from scratch: rate type, a W-2 and a 1099 rate, proof-of-work requirements, and an optional GPS check-in, then assigns it to talent from the roster.

One product, two rulebooks

The Admin app is used at a desk, in a slow moment, by someone who wants density and audit trails. The Talent app is used in a truck or on a roof, one-handed, often in direct sun, by someone who wants three taps and a clear answer. Wireframing both side by side meant writing a separate set of design rules for each before drawing a single screen, so speed for one side never came at the cost of clarity for the other.

Talent App — Opportunity Feed & Claim

A worker browses open incentives on a map or list, rate, location, and time-to-expire visible up front, and claims or counterbids in one or two taps.

From wireframe to a handoff package engineering could build from

The final phase moved both apps from structure to finished UI, adopting an existing component library rather than building type and spacing decisions from zero, so the engineering team got a Figma handoff package with interaction notes instead of static pictures. The moment the design had to earn its keep was payout: proof of work submitted, fees shown, cash landing the same day. If that screen didn't read as instant and trustworthy, nothing else in the app mattered.

Dual-App Workflow, Fully Annotated

The full payout journey mocked up across both apps, interaction notes, state changes, and edge cases called out directly in Figma alongside component references, spacing, and copy, so engineering could build from it without a separate spec.

Four steps. None of them hard. All of them time-consuming.

Applying for a job online follows a predictable sequence. Find a posting worth applying to. Open your resume, read the job description, identify key requirements, rewrite bullet points, adjust terminology, optimize for ATS keywords, then export. Open the application, upload the file, fill in your name and contact details, paste your LinkedIn URL, paste your portfolio URL, answer the EEO questions. Log it: company, title, date, status. Repeat.

None of those steps are hard. But each application took 15–20 minutes. At job search volume, that overhead adds up to weeks of mechanical work, time that should go toward the parts that actually require judgment.

From blank resume to tailored application package, in 10 seconds.

The most time-consuming step was also the most systematic: customizing the resume. I built a pipeline using Google Apps Script and the OpenAI API that takes a job description, identifies the top matching skills and keywords, and rewrites the resume to lead with the most relevant experience.

Each run produces five things:

Initially I triggered the pipeline by pasting the job description into a Google Form. I replaced that with a local Flask app: paste a URL, the job details are fetched automatically, the pipeline fires. No copy-paste. That change surfaced something worth keeping, because every resume already included a personalized portfolio URL, the fit statement and welcome message OpenAI generated became ready-made cover letter material. Content that started as a tracking feature turned into part of the application itself.

15–20 minutes per application. Now 10 seconds.

One screen. Everything you need to paste.

Generating the resume solved the customization step. But applying still meant tab-switching, job description in one tab, the application in another, the portfolio URL typed from memory. Small friction, repeated hundreds of times.

I created a Python app running locally that fetches job posting information for review. Clicking "Apply" kicks off the custom resume automation.

The tailored resume can now be downloaded, custom links are ready to be pasted into an application, and a custom intro can be used for a Cover Letter, so applying is a matter of pasting, not thinking.

Everything needed to complete an application is in one place: the job description, resume link, custom portfolio URL, fit statement, and cover letter copy, already written, already waiting. A lookup field pulls up any prior application by company name. One click logs it complete.

Stop hunting. Let jobs come to you.

The application steps were faster. Finding jobs was still entirely manual: browsing job boards, scanning listings, deciding what was worth pursuing.

A scheduled script runs JobSpy against LinkedIn, Indeed, Glassdoor, and others, filtered to the roles and locations I'm targeting. It deduplicates against applications already sent before writing anything, so I never see a posting I've already acted on. New listings land in a Job Feed with status chips: New, Applied, Already Applied, Not Interested.

Clicking a job card fires the description to the Quick Apply panel, which auto-fetches the JD, no URL required. The Command Center loads in the background. The employer's application page opens in the right column when the resume is ready. One click marks it complete and updates the status chip. The entire workflow, from browsing a listing to submitting, in a single view.

No more hunting around on separate job boards. Running the JobSpy Python app locally scrapes multiple job boards and delivers curated job postings that I can browse and apply for.

The design I wanted would have taken weeks to build by hand

I had a clear vision: scroll-triggered animations, staggered effects on gallery items, a custom lightbox with keyboard navigation, and a responsive layout that worked precisely across all breakpoints. I've built sites in HTML, CSS, and JavaScript before. But reaching that level of precision the traditional way requires a significant time investment, and I wanted to spend that time on design decisions, not debugging CSS.

AI changes what's worth doing yourself

The design work, layout decisions, visual hierarchy, imagery, copy, was mine to own. The implementation work was systematic: write this component, wire this interaction, fix this breakpoint. That's where AI could compress the timeline without compressing the craft. The question wasn't "can AI design for me?" It was "what's the right division of labor between a designer and an AI execution partner?"

Designed in Figma. Built with Claude. Iterated constantly.

I designed the full experience in Figma, created imagery in Photoshop, and wrote the core copy myself. Claude handled implementation, and I iterated probably a thousand times, just like any design project. The difference was the pace. Adjusting a timing curve, testing an alternative layout, fixing a mobile edge case, what would have taken hours of manual debugging moved in minutes. The animation system alone, scroll-triggered fade and scale effects, staggered gallery animations, a custom lightbox, would have been days of JavaScript work. With AI, I described the behavior, reviewed the implementation, and refined the details.

Managing logistics was pulling focus from coaching

With a 5v5 setup, 25-minute halves, and substitutions every 5 minutes to keep players fresh in the Texas heat, I arrived at every game with a notepad full of rotation plans that became obsolete the moment attendance was taken. I'd scramble to recalculate who was present, who'd played the most minutes, who needed time in their preferred position, and when the next sub window was coming, while also running a game clock, a rotation timer, and trying to actually coach. It was error-prone and exhausting. Position preferences mattered (some girls loved playing goalie; others specifically didn't want to). Ensuring fairness across the season required more tracking than any manual system could reliably handle.

The logistics were rule-based. They could be automated.

The rotation logic followed consistent rules: equal playing time, respect position preferences, account for absences, sub every 5 minutes. That's a solvable system. The human judgment, reading the game, coaching in the moment, responding to what's happening on the field, that's what I should be doing with my attention.

Select attendance. Get a complete rotation plan.

I built a web app that takes attendance as input and generates a complete substitution schedule. It distributes playing time across positions, respects individual preferences (including goalie restrictions), and accounts for absences automatically. Dual timers, one for the half, one for the 5-minute rotation window, run simultaneously on the same screen. After the final whistle, the app generates a post-game report: minutes played per player, positions covered, number of times out.

Strong functionality. Dated presentation.

CIRadar had sophisticated filtering, saved search, and analytics capabilities that outperformed competitors. But the UI looked older than its feature set. Competing products with fewer capabilities looked more polished. The client wanted a visual refresh, scope constrained to the presentation layer, with no changes to existing layouts or user workflows.

Bootstrap 3 made a clean upgrade impractical

The app's reliance on Bootstrap 3, a rigid 12-column grid with predefined component styles, made a framework upgrade costly. Refactoring to Bootstrap 5 would have required extensive rework with high regression risk. The practical path: targeted CSS overrides, CSS Flexbox applied in isolated components, and selective UI updates that preserved backward compatibility with the existing structure.

Evaluate → brief → design → iterate → hand off

I started with an independent evaluation using a test account, documenting patterns, capturing assumptions, identifying where visual changes would have the highest impact. I compiled findings into a concise project brief that aligned on scope before any design work began. After initial mockups, one round of client feedback corrected a few assumptions about existing functionality. A second iteration resolved remaining refinements. The design-to-development handoff was straightforward, adherence to the existing layout meant the experienced developer could implement with minimal documentation.

Strong pre-release validation. No post-release signal.

Our team used SUS, ACSI, VisAWI, and other benchmarks to validate design quality before handoff. These worked well for pre-release. After features shipped, feedback collection fell back on broad email CSAT surveys, low engagement, no targeting, no ability to isolate feedback by app, workflow, or user type. Leadership couldn't see the connection between design decisions and customer outcomes. UX's strategic impact was real but invisible.

We were already using a tool that could solve this

We used Pendo for behavioral analytics. Its Guides feature, typically used for in-app walkthroughs, could target specific users on specific pages after specific actions. I saw the opportunity: iframe a Qualtrics survey directly into a Pendo Guide. Targeted, in-context feedback, no inbox required, no list management, near-zero overhead to activate and deactivate per quarter.

Embedded CSAT, intelligent targeting, unified dashboards

Working with Engineering, we embedded Qualtrics surveys directly into Pendo Guides, configured to appear only within specific apps, for specific user roles, on relevant page types, after key actions. Each application got its own CSAT Guide, toggled on for a few weeks each quarter, then off. No manual process. I then built Qualtrics dashboards for real-time trends and a PowerBI master dashboard that unified usability testing data, research insights, and CSAT results with feature-level drilldowns.

A successful onboarding that wasn't producing revenue

A newly opened checking or savings account isn't an active customer. A funded account is. Across Q2's financial institution clients, we were seeing the same pattern: users completing account opening and stopping there. Not abandoning, completing. The flow worked. But funding, treated as a separate post-onboarding task, was getting deferred. Sometimes indefinitely. Unfunded accounts meant no deployed capital, no interest revenue, and no live customer relationship for the institution.

The workflow ended at the wrong moment

When users finished opening their account, they were told: your account is open, go fund it when you're ready. Funding lived outside the flow, and "when you're ready" frequently meant never. The account opening experience had a clear finish line. Funding didn't. This pointed to a focused direction: we didn't need to redesign the core workflow. We needed to extend it by two deliberate changes.

Two changes. Both targeted. Neither disruptive.

Change 1, Move funding into the flow. We placed the funding step immediately after account approval, before the confirmation screen. That moment, right after approval, is peak motivation. The account is real. The relationship has just started. Funding placed there lands completely differently than a follow-up email two days later. Nothing about the mechanics changed. The framing did: funding became part of the opening, not a follow-up to it.

Change 2, Add a funding rail users already trusted. Before, users could fund via existing account transfer or ACH bank transfer, both requiring routing numbers or credentials that a brand-new customer often doesn't have at hand. We added debit or credit card as a third option. Instant. No routing numbers. A mental model already internalized through years of e-commerce. One screen. Three funding contexts. Each option's timing made explicit so users could choose with confidence. The deposit field defaulted to $100, above the $25 minimum, a behavioral nudge that anchored users without removing their agency.