{"id":28085,"date":"2016-09-27T23:01:45","date_gmt":"2016-09-27T15:01:45","guid":{"rendered":"https:\/\/www.hongkiat.com\/blog\/?p=28085"},"modified":"2017-11-23T18:08:21","modified_gmt":"2017-11-23T10:08:21","slug":"web-dev-concepts-for-designers","status":"publish","type":"post","link":"https:\/\/www.hongkiat.com\/blog\/web-dev-concepts-for-designers\/","title":{"rendered":"Web Development Concepts All Web Designers Should Understand"},"content":{"rendered":"

There\u2019s a lot to be said about the divide<\/a> found between designers and developers<\/strong>. Granted there are many designer\/developer hybrids who can understand both sides of the coin<\/strong>, but they\u2019re few and far between.<\/p>\n

Creative projects thrive on proper communication<\/strong>. However this can be difficult when designers and developers aren\u2019t sure about how to talk to one-another<\/strong>. I don\u2019t think designers need to know how to write proper JavaScript, nor should developers master typography selection. But there are some fundamental topics<\/strong> that I think go both ways.<\/p>\n

The following topics are my own personal take on vital web development ideas that all designers should understand<\/strong>. As a designer\/developer myself, I know how confusing it can be studying both areas. But it\u2019s always worth the effort to learn because a clear understanding improves communication and makes a designer much more valuable to a creative team.<\/p>\n

\n\t\t\t\t\tRead Also:<\/strong>\u00a0\n\t\t\t\t\t10 Programming Habits Developers Should Adopt<\/a>\n\t\t\t\t<\/p>\n

Frontend Code Behavior<\/h2>\n

Web designers are often thought to have frontend skills along with their design talents. This is a hotly debated topic<\/a>, mostly because there\u2019s no correct answer<\/strong>.<\/p>\n

Designers should do what they are comfortable with<\/strong>. If that means only doing visual design work, then so be it. However a brief understanding of frontend technologies can make the same designer more intuitive<\/strong> when creating assets for developers.<\/p>\n

I believe every designer should at least understand the three fundamental languages of frontend development<\/strong> (HTML, CSS, and JS) along with how they\u2019re used. For example, most dropdown menus rely on JavaScript but there are CSS-only alternatives<\/a> as well.<\/p>\n

When a designer is crafting a dropdown menu, they can think about the complexity of implementing it via code<\/strong>. A designer who understands which elements require JavaScript can be better prepared to understand what they\u2019re asking developers to build.<\/p>\n

This is possible without learning to write a single line of code<\/strong>.<\/p>\n

CSS is made to style the website<\/strong>. It\u2019s mostly static aside from CSS animation, and CSS creates the majority of visuals<\/strong> on a page. Most dynamic features<\/strong> are created with JavaScript.<\/p>\n

If you can understand this divide it will breathe a conscious effort into the design work. It will also force UX motion designers to consider how much work goes into animating an interface<\/a>.<\/p>\n

Responsive Techniques<\/h2>\n

Every web designer should at least know the term responsive design<\/strong>. This allows websites to adapt to different screen sizes<\/strong>, to each of which a different layout belongs. Device dimensions when a new layout is applied are defined by breakpoints<\/strong>, added in (one of) the CSS file(s).<\/p>\n

Breakpoints are specified by a certain pixel width<\/strong> (and\/or sometimes height), either minimum or maximum, at which the layout adapts to fit that screen size. So a responsive layout will look different on a 1080px monitor than on a 320px smartphone.<\/p>\n

To see how breakpoints work on real sites check out the Media Queries<\/a> website.<\/p>\n

\"Media<\/a><\/figure>\n

Your job as the designer is to consider how each breakpoint might influence the mockup<\/strong>. You may be tasked with designing several comps, each fitting into different screen dimensions<\/strong>.<\/p>\n

Once you have understood that a CSS breakpoint defines the conditions when the layout changes, you\u2019ll have a much easier time delivering these assets to the dev team.<\/p>\n

Think Modular With Designs<\/h2>\n

Developers always want to reuse code<\/strong> as much as possible, as this approach makes development less verbose<\/strong> and cuts down file sizes<\/strong> \u2014 in fact it\u2019s an important code optimization technique.<\/p>\n

Recommended Reading:<\/strong> 10 Reasons Why You Need Code Optimization<\/a><\/p>\n

Modular design<\/a><\/strong> describes a method of creating websites out of \u201cmodules\u201d<\/strong> that can be reused over time<\/strong>. Think buttons, form inputs, heading styles, or blockquotes with fancy stylings.<\/p>\n

If you design elements modularly<\/strong>, it becomes easier for developers to code the layout with reusable CSS classes<\/strong>. It\u2019s always a good idea to think about where you can reasonably reuse<\/strong> the same colors, textures, and page elements, however you need to be smart about it not to harm overall aesthetics<\/strong>.<\/p>\n

It\u2019s even better if you annotate<\/strong> which elements you have copied across different mockups, so that developers can mark up these parts of the site with repeat code<\/strong> \u2014 making development quicker and simpler.<\/p>\n

Modular design relates to atomic design<\/a><\/strong>, both approaches are rather geared towards developers. However visualization<\/strong> can help you understand how the code works, so if you\u2019re struggling to visualize modular design<\/strong> check out this post<\/a> to see a few examples.<\/p>\n

Understand Retina Images & SVG<\/h2>\n

Usually it\u2019s the designer\u2019s job to prepare images, capture any necessary photos, and design icons from scratch. This means designers are solely responsible for delivering the visual assets<\/strong> that developers eventually code into the layout. This is why it\u2019s important to understand retina sizes<\/strong> and to pass retina-supported assets<\/strong> to the developers along with the final mockup(s).<\/p>\n

I would highly recommend this Smashing Magazine post<\/a> if you want to learn more about retina design workflows. Retinize It<\/a> is a free collection of Photoshop actions which can automatically create retina versions<\/strong> of your assets.<\/p>\n

\"Retinize<\/a><\/figure>\n

Most designers already know to support @2x images<\/strong>, but the newer iPhone 6+ devices have @3x resolutions<\/strong>. However some projects don\u2019t bother with @3x image sizes, so talk with your project leader before finalizing any assets.<\/p>\n

One last thing to consider is the advancement of SVG<\/strong> on the web. All modern browsers support SVG<\/a> which is a vector-based image format<\/strong>. This means SVG icons will automatically scale without any quality loss<\/strong>, so you don\u2019t need retina assets for SVG graphics.<\/p>\n

\"SVG<\/a><\/figure>\n

Not all creative teams are willing to go with SVGs for web design though. They\u2019re supported by browsers for sure, but in some cases they can also be tricky to implement. This is why communication is vital for a successful designer\/developer relationship.<\/p>\n

Discuss the pros & cons of using vector graphics and decide whatever works best for each project. By just having an understanding of these features you\u2019ll be able to communicate with developers clearly, and even help them code the layout for retina support.<\/p>\n

Understand Accessibility<\/h2>\n

Progressive enhancement<\/strong> and graceful degradation<\/strong> are two different ways of handling the same problem: accessibility. Not all users will be on devices or run browsers that support 100% of a website\u2019s dynamic features.<\/p>\n

These users should still get an experience that works<\/strong>, and this needs to be handled with proper coding. Some screen readers might ignore all JavaScript and CSS code, but the website still needs to function<\/strong>.<\/p>\n

Recommended Reading:<\/strong> Designer\u2019s Guide to the Basics of Web Accessibility Design<\/a><\/p>\n

I recently did a post covering progressive enhancement<\/strong><\/a> in detail, as it\u2019s my preferred method of development. Progressive enhancement starts with very basic features<\/strong>, then works up to more \u201cadvanced\u201d features.<\/p>\n

Graceful degradation<\/a><\/strong> is the opposite approach<\/strong> where all main features are designed first<\/strong>, then the developer decides how to handle these features if the user doesn\u2019t support JavaScript or CSS.<\/p>\n

It\u2019s unlikely that a designer would be asked to do mockups for any of these situations. But it\u2019s important that designers understand these terms and what they mean, because they do affect the development process<\/strong>. This is especially true for projects where accessibility is a big concern<\/a>.<\/p>\n

In Closing<\/h2>\n

There are some topics I skipped because I consider them optional. Version control, error handling, and JavaScript animations<\/strong> are a few more complex topics that designers may want to delve into.<\/p>\n

But truthfully, the points addressed in this post will more than help designers understand the requirements of a development team. By just skimming the surface of web development you\u2019ll gain insight<\/strong> that\u2019ll help you communicate ideas and sympathize with problems that occur during production.<\/p>\n

If you\u2019re looking for more related content have a look at these posts:<\/p>\n