Designers, Know Your Medium
I find it odd that architects know about load bearing values in materials, sculptors know about fracture values in stone, painters know the properties of canvas types. Yet digital designers know surprisingly little about the browser (or related technology), which will display the design they have so carefully crafted.
At System 4t we have therefore created a workshop for designers working with browser solutions. We aim to give a solid understanding of transitioning from a static single state to a dynamic imperfect world.
This is not about the ability to understand code and to program. It is about a fundamental understanding of the environment in which the design will be displayed and general concepts such as responsiveness.
One role of the frontend developer is to translate a static design file into a dynamic implementation. Many issues arise in this translation and many could be avoided if the designer had a better understanding of technology.
The designer lives in a static world with static dimensions and static content. In order to make the design more appealing the static dimensions and content are assumed perfect. This makes for great sales pitch material.

The lorem ipsum is made to fit the box and the product image is magically the same dimensions as the example device used in the demonstration.
The real world is not static nor perfect. It is a complex web of infinite screen resolutions attached to multitude of devices, which are spuriously connected by a hundred different network standards.
The one perfect state, which is designed, rarely considers all use cases. At the same time, this perfect state assumes that the client has perfect content. That has never been the case nor will it ever be.
Absolute positioning in a relative world
Even with modern tools, most design programs still have a concept of independent layers, which are absolutely positioned. Contrast this with a normal browser implementation where everything interacts and is relatively positioned.
If you move a box in a design program all other shapes stay put. If you do the same in a browser, all other shapes will be affected.
The behavior in the browser is by design and we intentionally implement things in such a way that dimensions are relative to each other. The one perfect state, which was designed, cannot possibly take into account the endless permutations possible in the real world.
Margins and paddings inevitably end up looking odd. The go to solution is to introduce a break point — a value for a resolution at which we drastically change and/or adapt the layout. If we are lucky, this was anticipated in advance. However, this is far from always the case.
In the former case, we still have the fluid dimensions between two break points to consider. This necessitates decisions on how fonts scale, how the fidelity of information changes and how graphics might need to be created at a different resolution.
In the latter case, we have absolute chaos as the team rushes to patch together a solution, which the client will find acceptable. Not excellent or even good, just acceptable because we are running out of time and money to create something which would be enjoyable.
A solid understanding of how elements interact in the browser would be invaluable to the designer and bring real value to the project and the client.
Content is data and data is dirty.
Sometimes data is wrong, sometimes the data format is wrong and sometimes data is outright missing.
The static design anticipates that data is always right and always conforms to the specifications given by the client.
Many larger clients have content spread over multiple systems and little to no overview of the integrity of their data. Even clients who go out of their way to enforce consistency will eventually have problems of one kind or the other.

Data should always assumed to be dirty. We shall disregard the case of incorrect data here and handle two distinct cases
- Data is missing
- Data is underflowing or overflowing
In the first case, we often have an element, which will not be displayed if there is no data to display within it. It depends on the type of data. An empty notification is useless to display but a warehouse item, which is out of stock, should still be available to reserve for later.
Data underflow refers to the case where we have less data than expected. Less content obviously has a profound impact on the design. Do we shrink the containing box? Do we alter margin and padding? Do we have more/less buttons? How does it affect nearby elements?
Data overflow is the reverse effect where we have more data than anticipated. We must either change the container or cut the content. Do we add a scrollbar? An overlay? Expand the container and let it influence surrounding elements?
These are not easy decisions and for every single data field it must be taken into account when designing a layout. If the design documentation comes with these kind of answers, a tremendous amount of time can be saved communicating between teams.
Content itself also changes when translated. We are likely designing in the native language of the client yet their main market might be somewhere else.
For instance, our design file is in English but we have a client in Germany. English translated into German takes up to 30% more space. If you translate into an Asian language, you might end up with just a couple of characters.
Also keep in mind that some languages changes reading direction — from right to left but also top to bottom.
Besides translation, there is localization, which refers to the local formats used for currency, date and time. Here we can logically deduce the maximum amount of data but we should still have in mind that it could be missing or incomplete.
Images and videos are two other kinds of content but they do not disrupt the layout to the same degree as text. They cannot be under or overflowing as they are confined to a single aspect ratio. They may change depending on device resolution but once displayed will not unpremeditated affect the size of its containing element.
Instead, we can scale and crop an image. These operations are better known among designers and their impact is less disturbing. Remember though that like missing data, an image may also be missing.
Educate Yourself
Understanding technology will make you a better designer and the collaboration with development easier.
It matters that the entire team know the medium, for which we are creating a product. It has a direct impact on development efforts and a general enlightenment among all stakeholders will produce a better result.
Tools are emerging which help the designer visualize a more dynamic design. We can also work with actual production data, and eventually design programs will move completely to the browser, creating a common platform for creative teams and frontend development.
However, a tool is only as good as the person using it. The conceptual understanding of layout in a browser should be mandatory if one wishes to design for the web.
I have made it a habit to ask designers about their educational background and specifically if any technology has been present. In the best case unfortunately only briefly.
We would be happy to help you expand your skill set and we’re always interested in how we as developers can improve to work with you.
