The ten-minute test

You can tell within ten minutes of using a product whether it was built by someone who cared. Not whether it’s well-designed, not whether it has good branding, not whether the engineering is clean. Whether someone cared.

It shows up in the small decisions. The ones that don’t appear in any spec.

Here’s the test. Open the product and do three things it was built for. Then do one thing it wasn’t quite built for - mistype something, use it on a device that’s slightly too small, let a slow connection interrupt a request, enter an edge-case value into a form. See what happens.

In a product built by someone who cared, the edge cases have been thought about. Not necessarily solved elegantly - sometimes a graceful message is enough - but thought about. The error state exists. It’s in the same visual language as the rest of the product. It tells you something useful rather than nothing, or worse, a raw system error.

In a product built to spec and shipped, the edge cases are missing. The form accepts inputs it shouldn’t and crashes silently. The loading state is a spinner with no timeout behaviour. The empty state - the page you see when there’s no data yet - is a blank white rectangle because nobody designed it. These things weren’t in the original requirements, so they weren’t done.

The product works on the happy path. The happy path is not the whole product.

This matters more than it used to, for a specific reason: users have been trained by very polished apps. The defaults are higher. Apple, Stripe, Linear, Vercel - these are the products people use every day. They’re built to a standard that handles edge cases well, feels instant, communicates state clearly, and degrades gracefully when something goes wrong. The bar has been set by the best products in the world, and every product gets judged against it.

“Good enough” now means “handles most of what users will actually do.” That’s a high bar for an indie product or a startup MVP. It’s achievable, but it requires caring about the parts that aren’t in the user story.

The practical version: the things I look for in the ten minutes.

Error states. Does the product tell you something useful when something goes wrong? “An error occurred” is not useful. “Couldn’t load your schedule - try again, or check your connection” is useful. The difference in effort is about twenty minutes. The difference in user trust is large.

Empty states. What does the product look like before there’s any data in it? New accounts, cleared filters, searches that return nothing - these states exist for most users at some point. If they haven’t been designed, the product looks broken when they occur.

Loading behaviour. Does the product communicate that it’s doing something? A skeleton screen or a well-placed spinner says “I’m working on it.” Silence says “it might have crashed.” Users who can’t tell the difference between loading and broken will assume broken.

Input tolerance. Forms that accept garbage data and either silently fail or crash are exhausting to use. Basic validation - reasonable character limits, format checks on emails and phone numbers, clear guidance when input is wrong - communicates that someone thought about the person on the other end of the interface.

Mobile behaviour. Still, in 2026, products that haven’t been properly tested on a real phone. Touch targets too small to hit accurately. Content that overflows its container. Inputs that launch the wrong keyboard type. These are the moments users decide whether they’ll come back.

None of this is glamorous work. It doesn’t photograph well. It doesn’t make it into the case study. It doesn’t feel like design in the way that a beautiful hero section or a well-chosen typeface does.

But it’s the work that determines whether the product is actually finished, rather than just shipped.

There’s a version of done that means “the features are built and the tests pass.” And there’s a version of done that means “I’d be comfortable if someone I respect used this for the first time right now.” The gap between those two versions is almost entirely composed of edge cases, error states, and the small decisions nobody asked for.

When I take on a project, the second version is the one I’m working toward. The ten-minute test is how I know when I’m there.

← The prototype that tells you everything What photographers actually make →