In the process of building a website, there are a few stages that take place. If we were to simplify it and look at a standard website, the stages would be:
- The need – Someone requires a website for one reason or another.
- Brainstorming – Deciding on general structure, goals and more.
- The Proposal – The client finds a freelancer or an agency to get the site built.
- Content – Articles, images, etc, anything that can be found on landing pages, sitemaps, etc.
- Design – A person/team works on the design and layout based on the content.
- Development – A person/team develops the functional part of the site based on the design.
Most of the time, you can mix it up here. You can change the order of things that are done, and the team can still produce great results. However, this can be difficult when you have people from different agencies working on the same project, which is the main reason to opt for an all-round agency that can take care of everything.
For this article, we take it from step 5, the Design to step 6, the Development. This is where things can go wrong by slowing down development and messing up what has previously been decided upon in the planning process.
The Things a Designer Should Consider
“Should designers know how to code?” is a common and it’s a very reasonable question. If a designer understands the code behind and ideally they can produce such (to certain extent), then he/she can help out the whole team in their push to complete the project faster.
Here are a few reasons why this is the case:
1 – In the end, it all ends up in the browser.
The important note to take from this is that any design should be doable in HTML/CSS. Many talented front-end developers can implement almost anything as long as the technology allows it. But remember, – it’s not always about “Can you do it?”, it’s about “Can you do it well and make it maintainable”.
2 – Consistency
Being maintainable is the secret to a successful project. You don’t want to spend hours upon hours tweaking existing site elements and adding new ones because the codebase is a mess. Sometimes extremely complex designs with little to none reusable components end up in a mess.
Some web designer tips:
- Design with components in mind. Most tools now provide this functionality (Figma, Adobe XD, Sketch). Force yourself to use them more often until it no longer becomes annoying to do so.
- Align elements well. Similar sections should have the same distance between each other. 80px is a good separation to maintain, for example. Don’t randomly space sections using 80 here, 86 there, 92 on a third and 78 on the other. Keep it neat and tidy.
- Use a grid! All tools provide a grid system. Ideally go for a12 column grid.
- Showcase your design on wide screens (1920px or more). This helps the devs figure out how each section and their backgroundswork.
3 – Weight of the site
We all want a fast website, right? Well, the designer is also part of this. Consider this: A website with 8 huge high-res images, four videos and animated elements. . Good luck with optimizing this on time. While doable, it will take additional development time and techniques to lazy load images and videos, optimize media on upload, support better image file formats, and add smart animation approaches for high performance..
If the developers aren’t very experienced or not worried about speed, your website could end up extremely laggy on low to mid level smartphones and laptops.
How to Help the Developers?
As a designer, one of your goals to keep in mind is to make the development easier and faster while maintaining the look and feel of the site.
You should consider what is easily doable on the web.
- Boxes – It’s all boxes. You can round some corners,yes, you can make ellipses (which are defined in a box) and more. When you go with more complex shapes that interact with the layout however, then things become difficult.
- Animating an accurate position is difficult – Imagine you want to click on an image, then move it to the other side of the text? It sounds “easy” but it’s not. The position the image will move to must remain relative to the site container, which changes based on the viewport and more. And then what happens if the image is larger?
- Animating box dimensions affects layout. This refers to any change to how elements are ordered during an animation. This can be extremely heavy on the browser and will often result in huge lag.
Consider different content!
How would the design look with 2x the text? Or as a portrait image instead of a landscape image? You never know what the editorial team will upload. Should there be constraints like aspect ratio or even the edges of the images? If you can, showcase this in the design.
Provide your designs in tools like Zeplin
Most design tools like Figma or Adobe XD have a way to “share” designs with developers. From there, the front-end team can inspect colors, typography settings, spacings and other visual properties of the layers, which would allow them to stick very closely to the designs.
Provide other assets like fonts or videos
If you have used a specific font on the site, provide it to the developers. If it’s licensed and accessible via specific URLs, make sure to share that too. It’s important for a developer to work with the correct fonts from day one. If there are videos – make sure to share that too! Would the videos be on YouTube, Vimeo or self-hosted?
Don’t go for “pixel perfect”
This notion of keeping the final look of the site perfectly the same as the design is an easy way to make your developers team hate you and can destroy any chance of going live on time. In almost every case the design is NOT going to be perfect. It’s impossible to be 100% certain that before every button you have exactly 18px spacing? And not 19px? Or that every single title is 38px and not 37px? Or maybe that every border is #ddd and that there isn’t one that is black but has 15% opacity?
Developers round up small mistakes like these here and there to maintain consistency across the site. They build in components that follow the same rules. As long as there isn’t obviously intentional change in a specific case, there shouldn’t be a reason why an element can’t be the same across the board.
In the end, the coded website should follow the general look and feel of the design.
Leave comments in the design
If you want a certain element to be interactive like tabs, accordions, sliders and the like, take a few seconds to write down how it should work on desktop, mobile and what is clickable, should one swap.
Think like a user
When you are done, stop for a second and imagine that you are using the site. Read down from top, scroll downwards, click somewhere to see more. Is there anything that might be missing from the workflow? Is there a view of a certain element that changes on user interaction? If that is true and there is no design, then you are leaving your developers to figure it out, which adds stress to the job.. If the deadlines are tight, you can share the general files with your team and let them know that a few “state” views are upcoming (make sure to mention which they are).
It’s daunting to design 15 pages on Desktop and then do a mobile version. It’s even more annoying to do a slightly different tablet version on top of that. Which is why some designers ignore adding it in. However, that means that the developers will have to do it in code. And make decisions because of it. If you see complicated elements, ideally showcase their tablet views even if you don’t do the whole site.
The designer can make the developer’s life a nightmare or a very good experience. The key to achieving the latter is to better understand the technology being used, HTMl/CSS, which interactive elements are doable, etc..
If you have the good fortune to be around developers and you are worried about certain elements, call them up to take a look at everything. They will definitely give you pointers as to what is tricky and as to what is easy.