It’s easy, I think, to make the moral case for testing on old devices. There’s a more practical case, too.
Recently, I was chatting with one of my clients, who was concerned how slowly their pages were loading for prospective customers in China. We talked about unreliable networks, perceived performance, and setting up a performance budget.
And then we started talking a bit more generally about devices—the ones owned by the team, and how they were used during the design process. They started mentioning some things I hear frequently from clients: that there’s a dedicated device lab, but it’s used exclusively by the QA department; they use their own phones and tablets to review in-progress work, but only occasionally; those devices tend to be fairly new, and they’re always on office wifi.
Trent’s essay on device agnostic design was—and is—a big influence on me, as what he’s talking about is resilience in web design. In recognizing the fact that the medium we’re designing for is, well, unreliable as hell: It’s impossibly tiny screens, and it’s unpredictable browsers, and it’s slow, spotty networks, and it’s a litany of dropped network connections, and, and, and. As Trent’s argument goes, by focusing on the adverse conditions our designs will face in the wild, the better prepared our designs will be. The more reach they’ll have.
To put a slightly more Darwinian spin on it: Your website’s only as strong as the weakest device you’ve tested it on.
In other words, the more I can do to bring real devices into my design process—into early concept work, into internal reviews, into reviews with clients and stakeholders—the better my design will be.