The UI design of a new web application is usually driven by ux, product, art and other related considerations. Programming comes into play after the design is finished. If programming considerations are taken at the UI design time, it will be limited just to verifying if a new feature is technically possible. The following example will try to demonstrate why in some applications, programming considerations should also drive the design.
a responsive application example
A design team release a responsive design for a dev team. It contains the following heading sizes:
These styles translate to the following css rules (codepen1):
/* Phones */
h2 Tablet size would have dropped down 1 pixel to 21px:
/* Phones */
Notice that in this setup, each heading size style needs just 1 rule, in contrast to 3 rules living in different media queries. The REM version reduced the lines of code count by 27%, but this can go up to 67% as the design gets bigger, and as also REMs can be utilized everywhere (padding,margin,line-height,etc'). This change is not only about reducing lines of code, it's about clarity, ease of maintenance & development time.
Was it a conscious decision to have
h2 in a slightly different ratio between devices? or a result of "eye-balling" the sizes on different .psd files?
In either case, a developer commenting on a finished design with this issue will have a hard time selling there's an issue at all. The designer will not be keen to revise his art just so it would satisfy some "math rules". In some way, the designer is right. However, the essence of a responsive design is broader than the design scope- one of the reasons for choosing responsive design over adaptive design is to have 1 code base. Having 1 code base where the UI is split in 3 different CSS chunks, each at their own media query, misses the original intention.
The sequential work flow of "design first, develop later", has some drawbacks when building some web applications as illustrated in the example above. Developers should have a way to drive design decisions that would otherwise be looked over. This suggestion is less significant if the design team also codes, or if they design in the browser.