unicorntears.dev
a designer’s adventure down the web dev rabbit hole

Designing for the web: a checklist

Last modified March 26, 2019
#design #process
.* :☆ﾟ

In my experience the design to development hand off can be a challenging and tedious process, perhaps even more so from a developer point of view because of the way a design is handed off.

I would say more than 50% of the websites I have built based on another person’s design are incomplete, and more often than not has issues with responsiveness and accessibility.

I’ve tried to make more designers aware of the basic fundamentals, I even wrote a mini manual at work. At the end of the day though, if you aren’t aware, you just aren’t aware. When changes are made to the design in the development phase, most of the time it’s simply because something that was designed statically just didn’t work digitally.

Many designers I’ve come across still think with print in mind when designing for web, and much of the “in-between” is left to the developer to interpret or make assumptions on. This is as you’d expect, a bad idea and often leads to time wasting and email chasing.

No matter how good the communication is between designers and developers, it is still incredibly hard to convey the realities and constraints of the web without delving into the code part of it as well, and many designers just aren’t interested in that part.

To be frank, anything that can be designed can be developed (or compromised on) in some way or another. It’s rather often the really little things that raise the most important questions in the hand off process, and take the most time to work out and refine.

If you’re a designer, I don’t think you should feel alarmed if you don’t know a single thing about code. The truth is, you really don’t need to know how a website is made at all for you to be able to design a website.

I think being aware of the basics and not thinking in terms of print better informs design decisions made digitally however, and I hope the following helps even a little in broadening your perspective and thinking about things you may not have thought of before.

The checklist

Use as much real content as possible

Lorem ipsum is fine if you really have nothing else, but if you rely on lorem ipsum for setting all your text, you may find the final outcome looks and feels a lot different to how your original design did.

I encourage everyone involved in the design process to ensure the final website design contains as much, if not ALL the final content as humanly possible. Of course things can change over the production period, and inevitably content will be updated. However it is always better to design with real-ish content, because it really helps with the actualisation and visualisation of a layout and it’s flow down the screen.

When content is resized or collapsed, elements can get in the way or columns may get squished. In my own experience, I have made websites where the content just didn’t feel right on the final site, simply because the final content wasn’t taken into account when the original site was designed.

Using lorem ipsum can result in content that looks like it was just tacked on to the end of the site, which is not an ideal scenario you want to find yourself in when you have gone to the trouble of designing and developing a custom website in the first place.

Think inside boxes

I’ll bet if you’re a designer, you’ve been told to “think outside the box”. I propose the opposite when designing for the website.

Literally think of each element as a rectangle, layered together with other rectangles.

It may surprise you to know, each element on a website is basically contained within a rectangle. In fact, HTML and CSS often refer to the term ‘box-model’ which essentially describes each element on the page as a rectangular “box”.

When you think of each element as a rectangle instead of a freeform shape, I find it’s easier to visualise how an element can be layered, stacked, and collapsed on a website, similar to how a complex series of layers in Photoshop is ordered.

Control the content

I find many designers only think with one artboard size in mind, giving no thought to how the browser can be resized up or down. Unlike a print document, content can easily change flow and width in the browser.

In fact, I think one of the first questions I ask every time I start a new build is

“is this content full width or contained”?

As an example, this is something I see a lot of:

A website design where the content width isn’t obvious

In many web designs I’ve come across, it’s often unclear what width the content actually should be, and what points it should break and collapse.

Having an image extend to the edge of the page also provides a very different feel to one where an image is contained with margins/padding.

A website design with contained content

As a general guideline, I usually contain websites within 1200px - 1400px wide depending on the overall design.

Keep in mind, blocks of text generally start getting hard to read if it’s wider than 1000px, especially if the text is set in small or serif type.

Some designs and content work well with full-width containers. Some don’t. It really depends on the content and elements you want to highlight.

Full width websites work well if you have beautiful large hero images or blocks of content with expressive and meaningful headings. Blogs on the other hand require more fine tuned type control, and if you’re designing a copy-heavy site, white space and contained text set with a max-width is everything.

If you’re designing ‘mobile first’, worrying about paragraph width is probably not at the top of your agenda, however it’s also prudent to think about text flow, especially on larger desktop screen sizes.

Columns are also a handy way to break up large chunks of text- being inspired from print is often a good thing too!

To break rules, you must first learn them

As a print-based designer, it’s tempting to go wild and do whatever you want on the web.

I personally don’t think this is a good way to design websites.

I know I wrote before, you don’t have to know a single thing about code to design for the web. The fact remains you can design a pretty good website without touching or knowing code at all.

A big caveat with this approach however is simply the fact that you are putting a lot of design responsibility on the developer you’re working with, whom likely has to go off assumptions to fill in a lot of the design gaps that comes with making a responsive, accessible website.

You’ll find many traditional design principles extend to the web, since websites are in part an extension of print design. There are many offshoots to digital design that requires more in-depth knowledge of the digital medium though, and so I think knowing at least the basics of how a website is structured goes a long way to informing design decisions in the actual design process.

Some things to note about digital design is that designing for the medium means designing for many screen sizes and possibly even many languages and cultures.

Learn what makes a good website, then proceed to challenge the norm.

Don’t limit yourself- anything you design is most likely possible- and if you are working with a good developer, they will be open to your ideas and tell you what’s feasible within the deadline/s and what’s not.

Respect the grid

If you’ve tinkered round with Bootstrap or other CSS framework, a 12 column grid is standard. Why?

12 is a nice, divisible number that allows for elements to collapse easily.

Grids are a tradition from print-based design.

Within the realm of digital design, I like to think of column grids as more like ratios of a page. I still design within a 12 column grid, whether it’s a full-width or contained design, and it is no doubt helpful in aligning elements such as columns of text or highlight boxes.

I don’t think a grid necessarily needs to be followed strictly on the web though; as long as type is aligned and there is a reason/intention to the overall page design, columns are really more like guidelines as to where content should fit and reflow.

Things like baseline grids, row gaps, gutters etc. might make some sense for whatever content you are designing with, but for the most part I personally don’t see the point in creating pixel-perfect mockups when things inevitably change when they are coded anyway.

License your webfonts

Many designers do not realise you have to purchase a separate web font license to use a custom font on the web. This means if you are using a purdy font like Gotham in a digital design, you’re essentially asking your client to subscribe to a yearly subscription to continue using it on their website which as you may know, isn’t cheap.

Google fonts and Font Squirrel provide fonts for free, and if you have a Creative Cloud subscription you’ll have access to thousands of fonts to use on the web too.

If you can buy a web font outright and your client agrees that’s great too! Just make sure it’s all purchased and ready to go before the website goes into production, otherwise the process may drag out longer while you wait for approval.

Consider limiting your fonts and font styles

As a general guideline, loading any more than 5-6 fonts/font styles can slow down a website. This is due to the size of each individual font the browser has to download, as well as the separate requests that have to be made to retrieve these fonts from the server.

Each font weight on the page has to be loaded in as a separate font file (that is, until variable fonts are more widely supported) so that means if you have light, medium, semi bold, and bold font weights in your design, you may want to consider cutting out a few styles to reduce the overall page size.

Resize and export images for web

I have received folders of hi-res photoshop files, each over 1GB in size to put on a website. Don’t be that designer.

Photoshop may seem easy to you but many developers don’t know their way around Photoshop well enough to export images optimally. If you are exporting images it means you are also in control the ratio and crop.

Jpegs are usually the best option for web, saved out at 72dpi (not 300+ dpi).

If you have any vectors, they should be exported as SVGs, with a minimal margin around each element. Logos should always be SVGs if possible.

Why SVG?

SVG is a vector format and easy to manipulate on the web. Not only that but they are quite small in size meaning a faster website.

In general, transparent pngs are harder to get away with on the web because they are hard to compress down to a small file size. If you are using transparent pngs over a solid background, you may be able to get away with saving images out as PNG-8 in Photoshop. This results in a fuzzy border not unlike transparent gifs, and they can also save a huge amount of kB.

A website I worked on a few months ago contained a bunch of deep etched product photos over a textured background. I got around this by saving them out as PNG-8 images and limiting the colour range. The edges aren’t as perfect as a regular png, but you honestly wouldn’t be able to tell the difference if you didn’t know.

Handy tip if you need to batch resize images quickly on Mac OSX:

  1. Select all the images you want to resize in Finder using Cmd / Shift
  2. Right click in Finder then click on ‘Open in Preview’
  3. Once the images are opened in Preview, go to Tools > Adjust Size
  4. Set your image resize options. A max width of 1200-1400 pixels at 72ppi is usually sufficient for web. Click OK when you’re done.
  5. Once the images have been resized use Cmd + a to select all the images in Preview
  6. Navigate to File > Export.
  7. Adjust the JPG quality slider to around 75%
  8. Save images to a new folder and you’re done.

Organise your layers

Whether you’re using Photoshop, Sketch, or Figma, naming and ordering your layers is important so that everyone involved in the design and development process can better understand the overall design.

It shouldn’t take more than a few minutes for you to organise your work, and is worth doing as you go because it will save everyone time in the long run, especially yourself if you have to come back and look at it months later.

Write comments for yourself, and for others

Another important thing I think more designers should do is comment their work. Comment everywhere, and explain everything you can in a separate layer. More information means less questions coming your way when the development process comes around, especially if it is a big job.

Also include notes about non obvious design elements and states. Things like hover states, link interactions, button transitions, animations, and transitions can all be prototyped or at the very least, described in the design phase. It’s helpful to list out interactions and describe them as you design because the more detail there is, the easier it’ll be to interpret your design.

One of the most well documented designs I’ve received was for this site. The design included a pdf of comments describing the design in detail, and it was super helpful for building the foundation and things like different states and assigning colours. The development process took a bit longer because there were more elements and layouts to style, but I think the overall result is more robust and cohesive design that has worked well with minimal bugs, over two years later.

Try to design reusable components

You may have heard of design systems and component based design. They hold a lot of weight in the developer world because the ability to reuse components is part of a core philosophy of how many developers think and organise their work. Designing assets and layouts that are reusable means it’s often easier to update and build upon existing templates in the future.

So, instead of thinking about the first iteration of the website, think of the bigger picture.

  1. Where do you see the site in two years from now?
  2. How do you think it can change and be built upon?
  3. What common themes and elements in the design can be reused and re-themed?

Think about mobile users

Mobile users now account for around 60-70% of a website’s total traffic. This statistic would be even more important for sites where news and media consumption is a main part of its content.

This is probably an unpopular opinion with developers, but I personally don’t think a mobile design is always warranted, especially if it’s a small site. If you are designing for a big content-heavy site with mega menus etc. I do think it is worth designing a separate mobile-specific design so you can think more deeply about the navigation and where the content areas will go.

Having a mobile design is always welcome in any case, because it allows developers to better strategise how to lay out the foundation of a website. A mobile design will also help inform devs of how a menu should be structured on mobile and desktop, and help gauge the time needed to work on the responsive side.

Keep in mind also there are no hover states on mobile like there is on desktop.

Think about accessibility

Making a website accessible means thinking about how your site caters to people using screen readers or those who are visually impaired.

A lot of the accessibility technicalities will be handled by the developer/s. The main things to think about from a design point of view is visual hierarchy and colour contrast. It’s always good practice to ensure headings make visual sense in all the sections, and that you aren’t using colours that are hard to read.

I’ve been asked several times by designers to remove focus outlines. This is in built browser behaviour and is a part of what makes the web accessible to everyone. It may not look nice but it is there for a reason.

Web fonts can also render very differently on the web as opposed to a program like Photoshop. This means a light font may look unreadable because it is anti aliased differently in the browser.

Know that you can also include focus styles in your design!

I’ve yet to see a designer design focus styles but it would be a welcome thing to see because it means that another extra thing has been thought of, making the overall design that much more cohesive.

Disabling form labels and relying on input field placeholders also isn’t great for accessibility either, but it is still something I see many designers do. And to add to this, popups, modals, and small fonts are also in general harder to make accessible.

As a general note, I would encourage any designer designing for the web to read about the basics of accessibility because it will only make your design that much more meaningful and accessible.

One website I like is the a11y Project because they have many examples of accessible patterns.

Finalise the design before development

Tacking on more design changes during the development process can unnecessarily drag out the process and take a lot more time to code than it looks. The website’s layout and entire foundation are often strategised at the very start of the development phase to optimise the website’s structure as well as enhance the developer workflow and efficiency. If things were to change further down the track it could potentially derail the entire website and mean a lot of unnecessary refactoring of code.

Convert all colours to hex values

If you for some reason you used CMYK or PMS colours in your original design, make sure they are converted to hex values or rgba by the time you hand it over to development, since these values are what will be used on the website.

Include tabulated data as a .CSV

If the website needs any tabulated data for things such as nutritional info or sizing info, send it as a spreadsheet as this is easier to import onto a website. Don’t even think about sending tabulated data in Word!

This may not be part of a designer’s job, but it is definitely handy to pass on to the developer if you already have if you have access to the site’s social media profiles and logins.

And that’s all I got for now…but I will update this list as I recall or stumble upon other issues in the future.