If you came into an office like ours five years ago, an early phase of the development process would have involved creating an exact, pixel-perfect model of the page. You then had a reasonable expectation of seeing the actual web site looking exactly like the mockup. We’ve had people send us messages saying “move the title 3 pixels over”, and five years ago, we honoured them.
This is no longer an acceptable practice. It creates unrealistic expectations for the modern web experience. Now, when you get a mockup, it’s more about showing overarching design principles than exact measurements. There are several reasons for this change.
First, the rise of “responsive” or “adaptive” layouts means that any single mockup can only represent a small segment of devices. That site you had designed in 2010– if you load it on a phone or tablet, it will either scale or require panning… neither of which really match the original intent.
You could argue “let’s map out every possible breakpoint and variant with mockups”. Good luck. Just to cover popular screen sizes, you’re looking at ten or more distinct layouts.
Second, software often prevents truly perfect control. A clear example of this is text rendering. When Apple brought Safari to Windows, their initial release brought along the OSX font rendering libraries. What we all learned immediately is that font rendering was significantly different– bolder, softer looking. More importantly, kerning wasn’t the same. That tagline you combined to EXACTLY fit across the screen in 22-pixel-high Helvetica Bold ends up with one word dangling on a different
browser. Frustrating, isn’t it? We tend to cope now by shying away from using every possible free pixel. Notice how a well-designed top navigation bar will have enough free space to not suddenly collapse if someone changes “About” to “About Us”.
Third, bitmap images are going to bite you harder than ever. While a lot of new content is moving towards Scalable Vector Graphics, most sites will depend on a fair amount of photography, logos only available as a JPG, or third-party icons that only come as bitmaps. This forces situations where the images have to be resized to fit available screen space, particularly on mobile. Unfortunately, this often means surprises happen–a single-pixel line gets lost in the scaling process, or embedded text shrinks to illegible.
Again, you might think you can cheat by saying “I’ll hand-tune every possible size variation”… however, most of the sizing rules will be things like “The size of the screen minus 5% of the screen width on each side.” You’re gonna make hundreds of images, often in bizarre fractional sizes, and eventually find some where you have to compromise.
You may also be surprised by the use of “Retina” or higher-resolution assets. Browsers handle this in a convoluted way, and support is not yet uniform. In some odd cases, you may end up sending low-res fallback images to a premium phone, or wasting bandwidth by sending Retina pictures to a low-end device, which will just have to be scaled down anyway.
However, this isn’t a doom-and-gloom story. By moving away from super-tight control over page appearance, we can actually do a better job of serving user needs and streamlining the development process. Rather than creating one version that looks perfect on a Lumia 635 and another that looks perfect on a Galaxy S3, ad nauseum, we embrace a philosophy of “good on all devices.” It’s a far more productive way to budget development and design time.
Pixel pushing tends to be low-yield… you spend a lot of time and money moving form fields and adjusting line spacing. However, did anyone ever say “I increased my line-spacing and sales went up 29 percent?” Instead, we can focus on the higher-return aspects of design– picking the right overall layout, making the messaging stronger, and adding features on a progressive basis– a whimsical touch for the guy with the latest Chrome or newest iPhone, but completely optional for other users. That’s what’s gonna make you money in the end.