The implementation of pixel-by-pixel design for mobile applications: what is it, why is it so expensive and can you do without it?
An attractive design is paramount to ensuring your application will be popular. Regular users are often unable to evaluate code quality, advanced functionalities or the complexity of the algorithms that bind everything together. However, their appreciation for clean, sharp design is significant — to a point. Let’s talk about that point. Where is it exactly? And on a related note, why is pixel-by-pixel design for mobile apps so expensive, and why it is it not always necessary?
Below are two identical screenshots of the standard iPhone interface using iOS7. At least, they look identical, right?
Fig. 1. Are these two screens really identical?
You don’t see the difference? No worries — most people can’t.
The two pictures aren’t duplicates — and truth be told, the effort needed to implement these two interfaces differs greatly. The left screen’s pixel-by-pixel implementation requires 2 – 4 hours of work, while the right screen’s pixel-by-pixel implementation could require more than 1,000 man hours. No joke!
“Pixel perfection” lacks an official technical definition, but it can be summarized as “implementing an application code design that gives almost every single pixel some degree of consideration.” The contrast of every border is sharp, the space between each content module is exceptionally proportional and the weight of every font is perfect. On the web, a “pixel perfectionist” will strive for a ridiculously consistent experience across every device, every browser, every screen resolution.
Pixel-by-pixel implementation means that every element of the initial graphic mockup has been translated with a 100% degree of accuracy into the final product. So when a client provides us with a mockup of his/her ideal application, an understanding of what “pixel-by-pixel design implementation” really means is paramount, since the expression is not as self-explanatory as it sounds.
A countless number of issues can arise when programming the application from a custom design aimed at pixel perfection. As such, using native components is often a much safer path.
As part of our efforts to explain pixel-by-pixel design’s many implications, we’ve divided the relevant mobile app design customization tasks into three groups, listed in order of complexity:
Group I. Natural adjustments: initial app branding
We call this group “natural” because some design suggestions are officially encouraged within Apple’s or Google’s design guidelines. These customizations are part of the brand identity that the makers of iOS or Android hope to see adopted in all the applications running on their respective devices. Such adjustments are usually well-documented and widely-used.
Guidelines include directions for large objects’ alignment, text alignment, basic text formatting (font family, weight, color and size), colors and margins, and padding of objects.
Fig. 2. Natural adjustments: customization of elements in a table
Fig. 3. Natural adjustments: alignment of “buttons” (labels)
Important note: at first glance the two buttons in Fig. 3 appear to be different elements; however, they’re actually two parts of a single solid element that implies settings for both appearance and position. Thus, if a client wants to customize their look (e.g. the text on the label needs to be upside down), then our intervention in the structure of standard iOS components is required, adding an extra level of complexity to the implemented design.
Group II. Complex-though-predictable adjustments
Extra time and effort is required to align smaller objects like right arrows or table icons (see the illustrations below). Though such changes are complex, requirements can be met on a predictable schedule so that initial design and final design coincide perfectly.
Fig. 4. In-depth adjustments: arrow alignment
Fig. 5. In-depth adjustments: customizing icons within a table
Since it’s assumed by default that we use standard iOS components and designs, clients should clearly indicate their desire for pixel-by-pixel implementation during the project’s planning phase.
Group III. Unpredictable adjustments: working with standard iOS components and font rendering
The most difficult, time-consuming and expensive scenario is when we have to deal with font rendering and letter spacing. We call these adjustments “unpredictable” because we must modify an operating system’s standard components.
The majority of these requests can be handled by an experienced developer. The only thing required from the customer is their acknowledgement that such tasks are on a totally different level of complexity, in that they require very specific programming know-how and much more development effort.
A customer must be absolutely certain that these design customizations are a must; otherwise, it could be an expensive and unnecessary hit to their budget. Often such tasks call for custom iOS app designs where all elements (buttons/labels, fonts, line spacing, indent, kerning and gradients) are unique. Developers can alert the client as to which design aspects are the most difficult and expensive to achieve, and suggest ways for modifying the mockup in order to reduce costs.
Let’s take a second look at Fig.6 for subtle differences:
Fig. 6. Unpredictable adjustment: fonts in navigation bars (standard on top, custom on the bottom)
As you can see, the “Settings” button on the custom screen is slightly wider than the standard version. Also, the width of the “back” button on the navigation controller couldn’t be tuned with the standard component, so a custom button had to be used, which increased development time by a few hours.
The second noticeable difference is in the caption kerning (namely, the interval between letters). The kerning couldn’t be tuned in the default label components, so to modify its appearance a developer had to implement his own text output component based on a low-level text rendering function. This type of operation can add 20 – 30 hours of programming time for a single line label, 50 – 80 hours for multiline labels and 200 – 300 hours for multiline formatted labels.
If we take an even closer look at Fig. 1 (named Fig. 7 below), we can see the difference in text rendering:
Fig. 7. Unpredictable adjustment: differences in text rendering
This example is rather obtuse, but the lesson is that pixel-by-pixel design implementation requires a developer to consider every detail. If we promise a client this level of implementation, then visual coincidence is no longer a secondary detail.
The development of a custom font rendering component may take dozens of hours in a simple case, and up to 1,000+ hours for more complex cases.
***
With all of these thoughts in mind, you can now see why design implementation estimates vary wildly, depending on small differences in approach that aren’t even evident to most users.
Most of our “real-life” projects include tasks from categories I and II, and sometimes a task such as “custom button width” from category III; hence our work is, for the most part, deliverable in a reasonable amount of time. However, problems can arise when there are many small design components to be customized, such as button width, arrow level, color shading of standard components, label positioning, gradients, animation duration, active button areas, etc. Taken individually, each of these tasks is simple to implement — but one project may include many such tasks.
At HireRussians, we tend to know whether a customer needs pixel-by-pixel design implementation, or if the design is unintentionally complicated — and we always alert our customers to the obstacles and costs implications of complex implementations.
Some issues can arise when we’re asked to estimate implementation of a “nearly-standard” mobile app design. If the customer doesn’t explicitly state their desire to make standard elements non-standard, we usually prepare the estimate for the easiest case, and count them as standard. That said, a good thing to keep in mind is that it’s not always easy for a developer to notice non-standard design elements in mockups provided by the client, especially when the differences to standard design-elements can be quantified in a handful of pixels. For this reason, our developers won’t include any customization in the initial estimate, unless the customer clearly indicates that customization should be included.
The price/design ratio for the three aforementioned groups is illustrated in the graph below:
Fig. 8. Price/design ratio showing the influence of design elements on price
At a certain point the price grows faster than its ratio to design: in other words, being a pixel perfectionist could cost you an arm and a leg. 
The ideal way to create a pixel-perfect, custom-designed mobile application is to ask your developers to work iteratively: start with an app that matches the original mockup at an acceptable level, and then keep improving the interface on subsequent releases. After all, every honest developer takes prides in doing their best to come as close as possible to the original design without increasing the development costs.
In closing, you might be familiar with the saying, “A painting is never finished”. Well, in our opinion, neither is an application or a website.
Note: though this article’s illustrations are based on iOS interfaces, its conclusions are valid for all mobile platforms since they all use standard components.