What 8 Years at Apple and Testbirds Taught Me About Error-Proof Websites

People assume the two halves of my background are separate: eight years at Apple on the support side, and UX and QA work on the other. They are the same job. One taught me where interfaces break. The other taught me how to check whether they did.

Learning a product from the failure side

I spent August 2017 to April 2025 as an AppleCare Senior Advisor, working iOS, iPadOS, and watchOS at T2 and T3, macOS at T1, ProApps at T2, and Apple Pay at T1. Later I took a Business Chat rotation and handled Consumer Law T3 escalations.

Support is the closest thing to a design review you can get. When someone calls with a problem, they are not describing a feature. They are describing where the product disagreed with the way they think. A button in the wrong place, a confirmation nobody noticed, an error message that says something failed without saying what to do next. Eight years of that is a very long list of ways an interface can quietly betray a person.

Three patterns showed up over and over.

First, if a step can be skipped, someone will skip it. If it must be done, make it a hard gate with a reason, not a suggestion in gray text.

Second, an error message is the most important copy on the page. "Something went wrong" is not a message, it is an apology. A real message says what happened, what was saved, and what to do now.

Third, nobody reads a long form twice. They read the label, hit submit, and trust the next screen. So the next screen has to show them the truth.

The KPIs that made it stick

The role was measured, closely. I held 96 percent against KPIs across that run and received the Apple Excellence Award in 2018. High-volume support with strict quality measures does one specific thing for you: it removes the option of relying on your own memory. You check, or the numbers tell you in public. That habit is why I test forms the way I do now, and why the first thing I did when I started taking client work was build repeatable tests instead of clicking around.

Testbirds: getting systematic about it

Since January 2019 I have worked freelanced with Testbirds, doing UX design and error-engineering projects for Nike, Amazon, Home Depot, and for Apple projects that were handled as closed black projects. On the build side that meant HTML, CSS, JavaScript and the Adobe Creative Suite, and in testing it meant writing repeatable scripts with Cypress and Puppeteer and using them to walk real interfaces the way real people do.

The shift from "check it" to "script it" is where error-proofing stops being personality and becomes process. A script that fills a booking form with a 30-minute session, a leap-day date, a name with an apostrophe and a phone number with country code will break in places a human tester never thinks to try. Ten of those scripts catch more real defects in a minute than an afternoon of clicking.

Two things I learned there that I apply on every site I build:

• Test the empty state and the double-submit. Most failures I have caused live in one of those two.
• Test the recovering user, not the happy one. Someone who typed a wrong email and came back is a different person from your first-run user, and your form has to handle both.

What all of it means for a client website

The sites I build now are not complicated because they are trying to be impressive. They are built defensively in specific, boring places that pay off for the client.

• Forms validate on the way out and say exactly what to fix, and they never silently drop a submission.
• A booking can only land in an available slot, with a buffer between appointments, so two people cannot grab the same 30 minutes.
• Confirmations are real, and they say what happens next and when.
• Every upload is stored privately, and every client can only see their own files.
• If the site goes offline because of the hosting company, a fail-safe backup copy of the site stays up so the business is still reachable.

None of that is design for a portfolio screenshot. It is design for the person who shows up on a bad connection, in a hurry, on a phone, and needs one thing to work the first time.

The through-line

Support taught me to design from the failure case backward. QA taught me to prove it. Web design is where both pay off, because a business website has no support desk. If the form breaks at 9 PM on a Saturday, there is no senior advisor on the line to walk the customer through it. There is only the page, doing what it was built to do.

That is the standard I build to now, and the reason I still test the ugly paths before I hand a site over.