The first time I realized my presets were working against me, I was three hours into a 200-image e-commerce job for a Chicago ad agency. I’d built what I thought was a bulletproof export action: sharpen, resize to 2000px on the long edge, convert to sRGB, save as JPEG at quality 10. Clean. Logical. The problem was the client’s web platform wanted 1600px, their email team wanted 800px, and their print vendor wanted TIFFs at 300 DPI. My single “universal” preset was making every handoff a manual correction session. I was automating the wrong thing at scale.

That afternoon cost me about four hours of rework. I tracked it in my spreadsheet, as I do with everything.

The Difference Between a Preset and a System

Most people treat Photoshop presets as shortcuts. Hit record, do the thing, stop recording, done. That’s fine for one-off tasks, but it’s not a system. A system anticipates variation. A preset that doesn’t account for the three or four contexts it’ll actually be used in will fail you quietly, usually when you’re under deadline pressure.

What’s happening under the hood is important here. Photoshop actions execute procedurally: they replay each recorded step in sequence, in the exact pixel dimensions and color mode of whatever file is active when you run them. That means an action built on a 3000px RAW-converted PSD will behave differently when you throw a 6000px medium format file at it, or a 72 DPI web asset someone sent over as a PNG. Document-relative settings, like canvas extensions or transform percentages, compound the problem because Photoshop calculates those off the current document state, not the state at record time.

This is why so many “simple” actions break unexpectedly. They were recorded in a controlled condition that no longer exists.

Building Presets Around Output Destinations, Not Input Files

The reframe that fixed my workflow was simple: stop building presets around what files come in, and start building them around where files need to go.

I now maintain a preset library organized by output destination. For a typical e-commerce client I’ll have four action sets: web-hero (1600x1600px, sRGB, JPEG quality 9, progressive encoding), web-thumbnail (800px long edge, sRGB, JPEG quality 7, optimized), print-ready (native resolution preserved, CMYK or sRGB depending on vendor, TIFF with LZW compression), and internal-review (1200px long edge, watermark applied, JPEG quality 6 to keep file sizes under 1MB for Slack and email). Each one is a self-contained sequence. No decisions required at runtime.

The watermark action alone saves me roughly 15 minutes per job. Across a year of client work, I’ve clocked over 2,400 hours saved total from automated actions. That number sounds absurd until you realize I’ve been running some version of this system for 15 years.

Where Custom Parameters Actually Matter

Here’s where most workflow tutorials lose me: they show you how to record an action but skip the judgment calls that make it reusable. A few specifics worth getting right.

For sharpening, don’t record a fixed Smart Sharpen radius. Instead, use a sharpening layer with the radius set to a percentage-based conditional. A 0.5px radius looks right on a 2000px file and invisible on a 6000px file. I use Unsharp Mask at Amount 85, Radius 1.0, Threshold 3 as a baseline for web output, and bump to Radius 1.5 for print. These numbers came from actual output testing, not defaults.

For resizing inside an action, use Image Size with Resample set to “Preserve Details 2.0” for upscaling and “Bicubic Sharper” for reduction. The distinction matters visibly on product photography where edge definition is a client deliverable. If you’re reducing by more than 50%, consider a two-pass approach: reduce to an intermediate size first, then to your final target. It takes an extra three seconds per file and produces noticeably cleaner edges.

For color mode conversions in actions destined for print vendors, record the Edit > Convert to Profile step rather than Image > Mode > CMYK. Convert to Profile lets you embed the specific ICC profile your vendor requires (usually Coated FOGRA39 in Europe, SWOP v2 in the US) rather than Photoshop’s default CMYK working space, which may not match.

The Batch That Changed How I Think About Preset Architecture

A couple of years ago I took on a job processing 500 product shots for an e-commerce client who had just migrated to a new platform with updated spec requirements. They needed deliverables in three formats simultaneously: web, thumbnail, and a new AR-ready format at 4096x4096px square with a white background and embedded metadata. The job landed on a Friday afternoon.

I spent Saturday morning rebuilding my action library around the new specs. I wrote a batch droplet in Photoshop that called three separate action sets in sequence, ran each file through all three output pipelines, and sorted the results into labeled subfolders automatically using a “Save As” step with dynamic naming. By Sunday afternoon, all 500 files were processed, sorted, and upload-ready. The actual computer processing time was under three hours. My hands-on time was maybe 90 minutes across the whole weekend.

The point isn’t that I was clever. The point is that the architecture I’d built to handle my normal four-output system scaled to a five-output edge case with about two hours of modification. That’s what good preset architecture buys you: not just speed today, but adaptability tomorrow.

Naming and Version Control for Presets You’ll Actually Maintain

One thing nobody talks about: preset naming will save or destroy you six months from now. I use a convention of CLIENT_OUTPUTTYPE_VERSION, so something like GENERIC_WEBHERO_v3 or ACMECO_PRINT_v2. I keep retired versions in an “Archive” action set rather than deleting them, because clients have a way of reverting to old specs.

I also export my action sets as .ATN files after every significant update and store them on a dedicated drive. Then I back that drive up. Yes, I have backups of my backups. That system has paid for itself twice over in recovered work.

The single most important thing I can tell you about custom presets is this: record them against your most common real file, test them against your most extreme edge case, and name them so clearly that you could hand them to a junior retoucher without a single word of explanation.