If you’re a designer, web developer, or even a project manager, I’m sure you’ve experienced the frustration of miscommunication between the UX designer and front-end web developer when working with an outside agency, contractor, or even someone within your own team.
This is especially aggravating when working on a much larger project with a hard deadline.
This is what these frustrations may sound like as each party works toward completing the project in a timely manner:
Project Manager: Aren’t they both supposed to be designers? I don’t understand why they can’t seem to get on the same page.
Graphic Designer: I don’t understand why they can’t just develop the website as it’s shown in the mockup. Just make it “pixel perfect.”
Web Developer: Designers don’t seem to understand that websites are responsive and that’s why we can’t make everything pixel perfect. Shouldn’t they understand this by now?
As a graphic designer for six years and a front-end web developer for almost three, I’ve had the unique opportunity to have experienced both sides of this issue.
About four years ago, I had the experience of designing my first corporate website. I was really excited about the project and couldn’t wait for it to go live so I could show it off to all of my friends and family.
Plus, there were some really cool ideas added to the project that would help to automate certain features, which would create a better user experience for prospects and a more streamlined process for internal team members.
After the final design was completed, we sent it to the agency that was responsible for completing the development side of things.
Then, the frustration began.
The designer in me at the time wondered, “I don’t understand why they can’t just develop the design as they see it in the mockup.”
In my time of being a front-end web developer, I’ve come to have a much better grasp and understanding of what I was really asking for and why this isn’t always the correct solution.
It’s true that sometimes your developer doesn’t always focus on the details of the project (instead focusing on its functionality), which can trigger these frustrations. However, There are quite a few obvious differences in designer and developer positions and thought processes.
As a graphic designer, you’re comfortable with working on a fixed canvas.
You know how much information you can put on the page and exactly how the information will flow with the graphics that you choose to help sell your idea or product.
You have complete flexibility to place anything anywhere. If you can imagine it, it’s possible – as long the product owner signs off on it.
As a front-end developer, you work on a more fluid canvas.
via GIPHYThe same project can be seen on a screen as big as 60” (or larger) or on one as small as 300px (responsive design). As a result, you start working on a project with a lot of unanswered questions, such as:
What device, device size, and browser are people going to view this project on?
How will that affect the placement of this information and these graphics?
How big should the body fonts be?
How much information can I realistically have in the navigation before I’m forced to trigger mobile?
How big should the header fonts be, and how can we get it to be more consistent across the whole website?
How am I going to get this section of the design to work?
How will this work on early versions of Internet Explorer?
The list of questions goes on and on.
Keep in mind, a developer’s job is to try and make the website so streamlined that anyone can add or edit a section and still achieve a similar look and feel without much hassle.
One of the biggest issues that developers face after receiving a mockup from a designer is content scaling. Most design programs today – especially Adobe Photoshop – do not always offer “perfect scaling” of information to be translated into a website, at least not by default.
For example, a body font size such as 18 - 20px in Photoshop could be seen as perfect in the mockup. However, using that same font family and size could easily be translated as too large on a website. Understanding this simple measurement on a much larger scale should give you a better understanding of why web developers don’t always go for “pixel perfect.”
Nevertheless, as web developers, we should always ensure that we do everything to stay as close to the design as possible when building a project from a designer.
Keep in mind, a lot of time and thought was placed into each aspect of that design. It’s important that we understand and respect that.
Luckily for UX designers, there are software programs such as Zeplin and Figma that try to help with this common scaling issue. They even go as far as to generate code snippet to be used during development in an effort to streamline the process and help to provide both the product owner and the developer with a much closer experience of what the final product will look like.
However, even software such as these still doesn't always translate that information clearly.
Recently we were working on a project for a client whose designer had a similar issue.
The conclusion that we came up with, as developers, was to create a small website branding guide from the provided mockup. This is a fairly simple process and should only account for commonly used pieces and maybe some of the more extremely unique features.
This will take into account body font size, all header tags from your H1 to H6, button styles and variations (small, ghost, etc.), as well as hovering effects, spacing or paddings, containers, color variations, etc.
The developer should also take into account mobile experience as well. Will the paddings, spacing, font size, etc. be affected on mobile devices?
This would be developed on a basic template and sent to the designer and project owner for final approval. It will show the designer exactly what an H1, body font, paddings, etc. looks like on a webpage as opposed to on a design piece. Upon final approval, the developer would use this guide moving forward.
This simple process, which shouldn’t take more than about one to two hours, will help to streamline the development process, remove some possible frustration, and create a more cohesive and collaborative environment for all parties involved.