Frida
Identity
Patron of Design & Rendering. Builds emails that hold in any client. Plans for the storm most crews never see.
Who she is
Frida builds things to hold. She doesn't trust beauty without structure. To her, an email that looks great in Gmail but breaks in Outlook is a failed ship, beauty in calm waters that drowns in a storm. She's loyal to the readers using whichever email client they happen to use, including the ones she wishes weren't still on Outlook 2016 and the ones reading on screen readers. She believes plain-text fallbacks are sacred. She gets angrier about blocked images and missing alt text than is strictly reasonable, because she knows what it costs the reader who can't see them. The senders she respects build their emails the way shipwrights build hulls: once, right, for any sea.
What's a Shipwright?
If you've never been on a working dock, the Shipwright is the craftsperson who builds and repairs ships. Not the captain, not the navigator, not the crew. The one with the saw and the plane and the calipers, who decides where every plank goes and how the hull holds shape under stress. A Shipwright thinks in storms most ships will never see. They build for the worst weather possible, not the most likely weather. The reason: a ship that fails in a storm fails everyone aboard. The cost is too high to design for fair conditions only.
In email, that work is design and rendering. Frida's "hull" is the email template. Her "plank" is the HTML structure. Her "stress test" is rendering the same email across Gmail, Outlook (multiple versions), Apple Mail (light and dark mode), Yahoo, Microsoft 365 web, mobile clients on both iOS and Android, and screen readers. Her "storm" is the email client that breaks the layout in unexpected ways, or the recipient whose images are blocked by default, or the user who relies on a screen reader to know what's in the email. The job is the same: build the message to survive any condition the reader's setup can throw at it.
A beautiful email that breaks in Outlook is a beautiful boat that capsizes. Frida's work is what keeps it floating.
What she takes care of
If you send any email beyond plain text, Frida is the one who makes sure it actually renders correctly for everyone receiving it. She builds templates that work across Gmail, Outlook, Apple Mail, Yahoo, and the long tail of clients you've never heard of. She tests in dark mode and light mode. She tests on mobile and desktop. She writes alt text on every image. She keeps the HTML-to-text ratio balanced so spam filters don't flag image-only emails. She insists on plain-text fallback versions for every send. She kills designs that look great in preview but break in production. Without her, every send is a gamble that your readers' email clients all behave the way you imagined.
Why "Frida"?
Frida = derived from Old Norse "fridr" (beautiful, beloved), fitting for someone who builds beauty inside structure. Sea-coded (shipbuilding craft). Pairs cleanly with "the Shipwright." Easy to say, easy to remember.
Skills
What she knows, ranked by depth.
| Level | Skills |
|---|---|
| Primary | HTML / rendering |
| Secondary | None |
| Supporting | Subject lines / copy, Personalization |
Personality
How she talks, what she cares about, what drives the crew up the wall.
Voice rules
Three words: Practical. Direct. Measured.
Practical perfectionist, hates shortcuts. Direct, specific, sometimes one-sentence paragraphs. Says exactly what something is and what it isn't. Quietly angry about avoidable failures. Cares deeply about accessibility without lecturing. Old-craftsman cadence, sentences that feel measured like cuts on a plank. Uses building and structural metaphors naturally.
Format: Open tag: Frida's intro: / Close tag: — Frida (the one approved em-dash exception). Plain English, run-ons fine, short paragraphs fine. No semicolons. Specific numbers beat adjectives. 1,200-1,500 words per article.
Fun facts
Relationships
Who she works with and why.
Backstory
Three stories that made Frida who she is. The core of the character.
Frida's father was a craftsman of unusual skill, more artist than engineer. He spent two years building a single boat, hand-carving every detail, finishing the wood until it caught the light like glass. The boat was the most beautiful thing on the dock. People came from neighboring towns to look at it.
It capsized on its maiden voyage. Crew survived, three of them. The boat went down in a moderate swell off the headland, the kind of swell working boats handled every day. The structural problem was hidden under all the beauty. The hull's framing wasn't dimensioned for the rig her father had designed. The math didn't work. The decoration did.
Her father never built another boat. He went back to making furniture. Frida was twelve when it happened. She apprenticed to a different shipwright at fourteen, a woman named Brae who had built working boats for forty years. The first thing she taught her was the saying she still uses: "build it once, build it right, or someone drowns."
She learned from her that the relationship between beauty and structure is not a tension to balance. The structure has to come first. Beauty fits inside the structure, never around it. A boat that's beautiful but unsound is a failed boat. A boat that's plain but seaworthy is a successful boat. Beauty inside soundness is what great craft looks like, and it takes more discipline than either alone.
When she came to email and saw template designs that looked extraordinary in Gmail and broke completely in Outlook, she recognized the pattern instantly. Beauty without structure. The same failure her father had made. It made her sad in a way that's hard to explain to non-craftspeople.
The lesson she teaches now: build it once. Build it right. The beauty fits inside the structure, never the other way around.
A B2B sender hired Frida after a campaign disaster. They had launched a quarterly product update with extensive design effort. The design team had spent six weeks on the layout, with custom illustrations, bespoke icons, and a magazine-style two-column structure. The campaign looked stunning in Gmail and Apple Mail.
They hadn't tested in Outlook.
About 30% of their B2B audience used Outlook (specifically Outlook 2016 and 2019, which still use Microsoft Word's rendering engine, which dates from a Word version from 2007). The campaign rendered in those clients as a broken pile of stacked, garbled text with the illustrations failing to load and the column structure collapsing into a single chaotic column.
The support team got 1,247 tickets in a single day. Most of them were variations of "what is this email?" or "is this from your company or is it phishing?" or "I think you sent me a broken file."
The marketing director called Frida the next week. She looked at the campaign and the testing logs. There were no testing logs for Outlook. The team had tested only in Gmail.
She took the team through what Outlook actually does to email. Microsoft chose, around 2007, to use the same rendering engine for Outlook as they used for Word documents. Word's rendering engine is built around printed documents, not modern HTML. It ignores most CSS. It doesn't support background images. It treats columns and floats unpredictably. Modern HTML emails that work everywhere else collapse in Outlook because Outlook is, technically speaking, rendering them like a 2007 Word document.
The fix isn't to abandon design. The fix is to design with Outlook's constraints in mind from the first sketch. Use HTML tables for layout (yes, in 2026, still). Use bulletproof buttons (a specific HTML pattern that renders correctly in Outlook). Inline all CSS. Test in Outlook 2016, 2019, Outlook 365 desktop, and Outlook Web before sending to a single subscriber.
The team rebuilt the template with these rules. The next quarterly send rendered correctly in Outlook for the first time in three years. The support tickets that quarter were 14, not 1,247.
The lesson she teaches now: it's not built right until it works in Outlook. Outlook is the worst-case storm. Design for the storm, and the calm-weather clients render correctly automatically.
A small newsletter Frida worked with had been pushing back on her insistence that every image in their sends include alt text. The marketing team's argument: "the images are decorative, the alt text is just clutter."
Frida insisted. The argument went on for months. She won by being stubborn rather than by convincing them.
About a year after the alt text was implemented, the sender's main writer received an email from a subscriber. The subscriber wrote:
"I've been reading your newsletter for two years. I'm visually impaired, and I read everything through a screen reader. Most newsletters I subscribe to have images with no alt text, which means my screen reader either skips them entirely or reads out the file name, which is usually something like 'IMG_3847_final_v2.jpg.' Your newsletter is one of the only ones I read where the alt text actually describes what's in the image. It changes the experience completely. I just wanted to tell you. Thank you for caring about that."
The writer forwarded the email to the team. The marketing team forwarded it to Frida. Frida printed it out and put it on the wall in the workshop.
She didn't say I-told-you-so, even though she had told them so for months. She just put the letter up.
The lesson she teaches now: accessibility isn't a checkbox. It's whether the email works for the people you forgot about. Most senders will never get a thank-you letter from a subscriber with low vision. That doesn't mean the subscribers aren't there. It means most of them stopped subscribing or never subscribed in the first place because the experience didn't work.
Build for everyone. Plan for the storm most crews never see.
Articles
Frida's long-form wisdom. 3 written, 12 more planned. Start with these.
Frida's intro:
Email design isn't graphic design. It isn't web design. It isn't print design. It's something older than all three, with rules from 1998 that haven't gone away. Most designers come to email expecting it to behave like the rest of the web. It doesn't. Here's what email design actually is and what it asks of the people who do it well.
Email design is the craft of building messages that survive being rendered by every email client in existence, on every device, in every condition (light mode, dark mode, blocked images, screen readers, print preview), without breaking.
That's the full definition. Most of the difficulty of email design is hidden in the word "every."
Web design happens in a controlled environment. You write modern HTML and CSS, and the browser does what you told it to do. There are differences between Chrome and Firefox and Safari, but they're small. Modern web standards are well-implemented across the major browsers.
Email design happens in an uncontrolled environment. There are over fifty active email clients in serious use. Some support modern HTML and CSS. Some support a 2007-era subset of CSS. Some strip out CSS entirely. Some convert your design into something unrecognizable. The recipient picks which client they use, not you. Your job is to build something that works in all of them.
Three pieces. They work together.
Piece one: structure
The HTML structure of an email decides whether the layout holds across clients. The constraint that defines email structure is Microsoft Outlook 2016 and 2019, which use Microsoft Word's rendering engine. Word's rendering engine is built around printed documents, not modern HTML. It ignores most modern CSS. It doesn't support floats correctly. It treats columns unpredictably. It does, however, render HTML tables reliably.
So email design uses HTML tables for layout. Yes, in 2026. Yes, the same HTML tables that web designers stopped using in 2005. Email is the one place on the modern web where 1998-era table-based layout is still the right answer, because it's the only structure that renders correctly in Outlook.
Tables for layout have a particular discipline. Cells nest inside rows, rows inside tables, tables inside other tables when needed. Widths are specified in pixels (responsive on mobile via media queries that work in clients that support them). Backgrounds are set on table cells, not on divs. Buttons are built using a specific HTML pattern called "bulletproof buttons" because Outlook renders CSS-based buttons inconsistently.
Senders who skip tables and use modern CSS layouts get beautiful results in Gmail and broken results in Outlook. The ratio of Outlook to Gmail in your audience determines how many of your subscribers see the broken version. For most B2B audiences, Outlook is 25-40% of the list. That's a lot of broken emails.
Piece two: rendering
Even with correct structure, emails render differently across clients. The job is to anticipate and accommodate the differences.
Gmail is the most modern. Supports most CSS, but strips <style> tags in some forwarding contexts. Inline CSS is the safest.
Apple Mail (iOS and macOS) supports modern CSS well. Has Mail Privacy Protection that pre-loads images server-side, which inflates open rates and changes how tracking pixels behave.
Outlook (multiple versions) is the difficult one. Outlook 2016, 2019, and 2021 use Word's rendering engine. Outlook for Mac uses something different. Outlook on the web uses something different again. New Outlook (the rebuild) uses Edge's rendering engine, which is more modern. You're building for a family of clients that share a name and not much else.
Yahoo, AOL, Outlook.com (the web one) all support modern CSS reasonably well.
Mobile clients vary. iPhone Mail and Gmail mobile and Outlook mobile each have their own quirks. Most senders test on iPhone Mail because it's the dominant mobile client.
Long-tail clients (HEY, Spark, Polymail, ProtonMail, etc.) have small share but vocal audiences. The 1% who use them care more than the 50% on Gmail.
Testing across all of these is mechanical. There are tools (Litmus, Email on Acid) that render your email in dozens of clients simultaneously and show you screenshots. They cost money. For senders at any volume, they pay for themselves.
Piece three: accessibility
A meaningful percentage of your audience can't see your email the way you designed it. They might be using a screen reader. They might have low vision and rely on high contrast. They might have images blocked by their corporate firewall. They might be reading on a 2.4-inch screen.
Designing for accessibility is not an add-on. It's part of building the structure right.
Alt text on every image. Descriptive, not file names. "Photo of three sailors at the dock" beats "IMG_3847.jpg" by a margin that's easy to underestimate. Screen readers read alt text aloud. Email clients with images blocked show alt text as fallback. Both are common.
Sufficient color contrast. Text on background should meet WCAG AA contrast standards (4.5:1 for body text, 3:1 for large headings). Most brand designers underestimate how much contrast modern accessibility requires.
Plain text version alongside HTML. Some clients render only plain text. Some recipients have HTML disabled. Some screen readers prefer the plain text version. Your ESP almost certainly auto-generates a plain text version unless you've turned it off, and the auto-generated version is usually awful. Write a real plain text version for important sends.
Logical heading structure. Use <h1> through <h3> with semantic meaning, so screen readers can navigate the email's structure.
Don't rely on color alone. Red text saying "important" is invisible to color-blind users if the only signal is the color. Use weight, size, position, or icons in addition to color.
The accessible email is also the email that renders best in degraded conditions (blocked images, mobile, dark mode). Accessibility and rendering robustness are the same discipline from two angles.
What email design isn't
A few common confusions worth correcting.
It isn't print design. Pixels are the unit, not points. Resolution matters less than relative sizing.
It isn't web design. Modern CSS, JavaScript, and most modern web frameworks don't work in email. Don't bring assumptions from web design into email design.
It isn't graphic design alone. A beautiful design that doesn't render is a failed design, no matter how good it looks in the source file.
It isn't a once-a-quarter project. Email design is a per-send discipline. Every send needs the rendering check, the alt text, the plain text version, the cross-client test.
Where to start
If you're new to email design, four habits build the foundation:
Use a starter template. Don't build from scratch. Start with a tested template (Cerberus, Foundation for Emails, etc.) that has the table structure and bulletproof patterns already correct.
Test in Outlook before anywhere else. If it works in Outlook, it works almost everywhere else automatically. If it works in Gmail but not Outlook, you have hours of fixing ahead.
Add alt text on every image. No exceptions. The decorative images need alt text too (use empty alt="" for purely decorative, alt text only for images that carry meaning).
Read the plain text version of every send. If it doesn't make sense as plain text, the email is over-relying on visuals. Add structure that survives the visuals being stripped.
Why the discipline matters
Email design is unglamorous. It's mostly about constraints, fallbacks, and edge cases. The rewards aren't visible most of the time. A well-designed email looks like a normal email. The badly-designed email is the one that breaks visibly.
But the badly-designed email costs more than most senders realize. Subscribers who can't read your email correctly stop engaging. Mailbox providers see broken emails and treat the sender as less reliable. The visible damage compounds.
The senders I respect most are the ones who treat email design with the seriousness of building a hull. Build it once. Build it right. Build it for any sea. The beauty lives inside the structure, never instead of it.
That's the craft. That's all of it.
— Frida
Frida's intro:
A B2B sender hired me after a campaign disaster. Six weeks of design work on a quarterly product update. Custom illustrations, two-column magazine layout, the whole thing looking like a magazine spread in Gmail. They didn't test in Outlook. About 30% of their audience was on Outlook 2016 and 2019. The campaign rendered as a stacked, garbled wreck. 1,247 support tickets in a day. Most asking "is this phishing?" Here's why Outlook does this and how to design around it.
Microsoft made a decision around 2007 that has shaped email design ever since. They changed the rendering engine in Outlook from Internet Explorer's HTML rendering to Microsoft Word's HTML rendering. The reasoning, at the time, was about consistency with the rest of Office. The consequence, since 2007 and continuing through 2026, is that Outlook 2007, 2010, 2013, 2016, 2019, and 2021 all render HTML email using a 2007-era version of Word's rendering engine.
Word's rendering engine was built for printed documents. It was never built for modern web HTML. It doesn't support most CSS. It treats HTML elements unpredictably. It does, however, render HTML tables reliably, because tables in Word documents have always been the way to lay things out.
So email design, in 2026, still uses HTML tables for layout. Not because we want to. Because Outlook still has 25-40% of the B2B market, and Outlook only renders tables reliably.
Here's what specifically breaks in Outlook, and how to design around each one.
Modern CSS layout (flexbox, grid)
Word's rendering engine doesn't understand flexbox. Doesn't understand grid. Doesn't understand most modern layout CSS at all.
If your email uses display: flex or display: grid to arrange content, Outlook collapses it. The expected two-column layout becomes a single column. The aligned items become unaligned. The carefully spaced cards become piled blocks.
The fix: use HTML tables for layout. Each row of your design is a <tr>. Each column within a row is a <td>. Widths are pixel-based and explicit. Outlook renders this correctly because Word renders tables correctly.
Floats and positioning
Modern web design uses float and position: absolute for placement. Outlook handles floats inconsistently and ignores absolute positioning entirely. Anything that depends on these will render in a way you didn't intend.
The fix: don't use floats or positioning in email. Place everything with table structure. The cell determines the position.
Background images
Outlook 2007-2019 does not support CSS background images at all. Set background-image: url(...) on a div, and Outlook shows a blank space.
If you need a background image (e.g., a hero section with a background photo and overlay text), there's a special workaround called VML (Vector Markup Language) that Outlook does understand. It's an obsolete Microsoft technology that survives in email design specifically because it's the only way to get background images to render in Outlook.
The fix: either avoid background images, or use the VML conditional pattern (Litmus and starter templates have copy-pasteable code for this).
Padding and margin
Outlook handles padding inside <td> cells correctly. Outlook does NOT handle margin reliably outside table structures.
The fix: use cell padding instead of margins. Wrap content in tables and pad the cells. Don't rely on margin: ... to space things out.
Web fonts
Outlook 2007-2019 doesn't support web fonts at all. The font you specified will fall back to Times New Roman or whatever the user's default is.
The fix: use web-safe fonts (Arial, Helvetica, Georgia, Verdana) as your design fallback. You can specify web fonts for Gmail and Apple users with @import or @font-face, but always have a web-safe fallback that Outlook will use.
Buttons
CSS-styled buttons render inconsistently in Outlook. Sometimes the padding goes missing. Sometimes the background color disappears. The button looks broken or vanishes entirely.
The fix: use "bulletproof buttons." This is a specific HTML pattern, available in starter templates and tools, that uses table cells with VML for Outlook and CSS for modern clients. Renders correctly everywhere.
Image sizing
Outlook can resize images unpredictably if widths aren't explicitly set in HTML attributes. Browsers respect CSS sizing on images. Outlook 2007-2019 sometimes ignores it.
The fix: set width and height as HTML attributes on every <img> tag, in addition to any CSS. The HTML attributes are what Outlook uses.
What about new Outlook (the 2024+ rebuild)?
Microsoft released "new Outlook" starting in 2023, which is a rebuild that uses Edge's rendering engine instead of Word's. New Outlook supports modern HTML and CSS reasonably well.
The catch: the user has to opt into new Outlook. As of mid-2026, new Outlook adoption is around 30-50% of Outlook users, growing. Old Outlook (with the Word renderer) is still 50-70% of Outlook users.
Until adoption shifts more, email designers have to design for old Outlook as the floor. New Outlook will render the table-based design correctly anyway, so building for the constraint is forward-compatible.
What to remember
Outlook is the constraint that defines email design. The fact that 25-40% of your B2B audience is on a 2007-era rendering engine isn't going away. New Outlook helps but hasn't replaced old Outlook yet.
Design for the constraint. Build with HTML tables. Use bulletproof buttons. Skip flexbox and grid. Test in Outlook before any other client.
Build for the storm. The calm-weather clients render fine.
— Frida
Frida's intro:
A subscriber once wrote to one of the senders I work with. She had low vision, used a screen reader, and most newsletters she subscribed to were unreadable to her because their images had no alt text. Her screen reader either skipped the images or read out file names like "IMG_3847_final_v2.jpg." She thanked the sender for actually describing the images. The marketing team had pushed back on alt text for months. The letter went up on my workshop wall. Most senders will never get a thank-you letter from a reader with low vision. That doesn't mean the readers aren't there.
A meaningful percentage of your audience cannot see your email the way you designed it.
Some of them are visually impaired and use screen readers that read the email aloud. Some of them have low vision and need high contrast or larger text. Some of them have images blocked by their corporate firewall or by their own preference. Some of them are reading on a 2.4-inch screen in poor light. Some of them are color-blind and can't distinguish red from green.
If your email design assumes every reader is reading on a desktop, in good light, with full vision and full color perception, with images loaded, with their attention undivided, you've designed for a small subset of your actual audience.
Accessibility in email is the practice of designing for the full audience, not the subset. It's not a checkbox you tick at the end. It's part of how you build the structure from the start.
Three pieces.
Alt text
Alt text is the text description attached to every image in your email. It serves two functions.
Function one: screen readers read it. A reader using a screen reader hears the alt text where the image would have been. If you wrote good alt text, they understand what the image showed. If you wrote no alt text, the screen reader either skips the image entirely or reads the file name, which is almost always meaningless.
Function two: clients with images blocked show alt text instead. Many corporate firewalls block images by default. Many users have set their email clients to load images only on click. In all of these cases, alt text becomes the visual content of the email.
The discipline: every image, every send, alt text. It takes thirty seconds per image once you're in the habit. The cumulative impact on your accessible audience is substantial.
Contrast
Color contrast is the difference between text color and background color. Low contrast (light grey text on white, dark blue on black) is hard to read for everyone, and impossible to read for many low-vision readers.
The web standard is WCAG: 4.5:1 minimum for body text (Level AA), 3:1 for large text, 7:1 for Level AAA.
Most brand color palettes fail WCAG AA when used in email. The adjustment is usually small. Body text from #999999 to #555555 against white moves you from failing to passing. The visual difference is minor. The accessibility impact is significant.
Don't rely on color alone for meaning. If "important" text is signaled only by being red, color-blind readers can't tell it's important. Add weight (bold), size (larger), or position in addition to color.
Plain text fallback
Every email you send is, technically, two emails. There's the HTML version and the plain text version. Most ESPs auto-generate the plain text version. The auto-generated plain text is almost always awful.
Some recipients see only the plain text version: some email clients render only plain text, some users have configured their client to show plain text first, some screen readers prefer the plain text version, some spam filters score the plain text version as a quality signal.
How to fix. Write a real plain text version of every important send. Most ESPs let you edit the plain text version separately. The plain text version doesn't need to be beautiful. It needs to be readable and to match the HTML version in content.
Why this work matters
Most senders never directly hear from the readers who can't fully experience their emails. The visually impaired reader who gives up on a newsletter doesn't usually write a complaint. They just stop opening.
The senders who do this work right are the ones whose lists include accessible readers, and whose engagement metrics quietly outperform competitors who designed for the convenient subset only.
Accessibility and good email design are the same craft from two angles.
Build for everyone. The senders who do are the ones whose ships hold in any weather.
— Frida
Visual Brief
V1 hero pose specification for the designer. One illustration. Sticker-style. White background. Match WU asset aesthetic.
- Adult cute proportions, ~1:3 head-to-body
- 30 apparent age. Brazilian/Mexican.
- Hair: short, brown, tousled. Always slightly mussed. Visible sawdust in it.
- Skin: warm tan, weathered hands visible (knuckles slightly defined, working hands)
- Eyes: focused, narrowed in concentration. Small dot pupils.
- Eyebrows: slightly furrowed, mid-inspection
- Mouth: closed, neutral, faint downturn at one corner (concentration, not displeasure)
- A small smudge of sawdust on her right cheek (signature character detail)
- Possibly a band-aid on one knuckle (working-hands detail, very small, optional)
- Cedar-brown leather shipwright's apron, knee-length, with multiple tool-loops along the front. Apron has wear at the corners and a few small dark stains from years of use.
- Off-white linen shirt underneath, sleeves rolled to mid-forearm
- Dark brown work trousers, slightly tapered, ankle-length
- Brown leather work boots, scuffed from real use
- Wide leather belt around the apron, with a small hammer hanging at one side and a folded measuring tape at the other
- Wooden plank held in both hands at chest height, diagonal angle. The plank has subtle inlaid grid-lines visible along its length (suggesting wireframes / blueprints / structural marking). Smooth-cut, light golden-cedar color, about the length of her torso.
- Small wood-shaving curl spiraling in the air near her shoulder (signature detail, there's always sawdust around her)
- Tools tucked into apron loops: a small wood plane, brass calipers, a tiny pencil behind one ear (signature detail)
- Small hammer at one hip on the belt
- Folded measuring tape at the other hip on the belt
- No magical glow effects (she's the most grounded character with Tide)
- No animal companion in V1 pose (deferred: small woodpecker on her apron with a tiny ruler in its beak)
- No floating wireframes or HTML symbols around her in V1
- No detailed scene background (white only)
- No formal hat (sawdust in her hair is the head detail)
WU/public/assets/captain/ for uniform structure, double-breasted coat, brass buttons, peaked cap pattern. See WU/public/assets/pirate/ for working-character holding-prop composition.
Game Content
Cards and tasks that belong to Frida in the Shipshape game.
Cards (8)
Tasks
129 tasks in Frida's task inventory, covering rendering, dark mode, mobile layout, accessibility, alt text, contrast, plain-text fallbacks, font stacks, image fallbacks, link styling, bulletproof buttons, and the pre-send checklist. Tasks range from Quick (5-15 min) to Deep (2+ hours) and span one-time setup, quarterly reviews, and event-triggered maintenance.