How Web Developers Feel About Print Designers Venturing into ‘Web Stuff’


Save Us From the Print Designers

Imagine you are a design agency who has been making amazing, trendy print and marketing designs for years. You can knock out a well crafted logo, billboard, or brochure with an exquisite awareness of the market you are targeting, and the needs of your client in a matter of weeks. Your clients love your work and they return to you again and again for every pixel perfect brochure and poster.

Then one day they ask you to take charge of their new website design. Why not? You already understand digital branding and social media strategies, so why not take the plunge into this fertile uncharted territory?

Wait. Hold up. Please. I just need a few minutes of your time, for the sake of my sanity and the sanity of web developers everywhere.

Should you take that plunge? YES, of course you should, but not without the very clear awareness that web design is drastically different from anything you have ever done. You just left the world of static pixels, perfectly positioned letters, and layouts that always stay rigidly the same. You are walking into an interactive medium, a multi-device/screen width medium, and a multi-user medium.

You are no longer working in a space where you can assume you have one kind of end user, one size of canvas, or static images that simply hang out on a static screen. You may have to consider how the content of the site will change over time, how easy your design will be to manage and update, and you will have to know a thing or two about web accessibility.

You will also want to know if users actually interact with the the interactive elements of your site, and what to do if that amazing carousel you designed turns out to be a complete dud at actually marketing anything.

Still want to move ahead? Good. The web is a powerful medium and as a digital design firm, you should want to be a part of it. But it is incredibly important that you know what you are getting into. You might also want to know why you are getting that weird look from your developers when you surprise them with the fact that you don’t know what a hover state is. But maybe I can help with that.

So here is a non-exhaustive list of things you should know if you want to design for the web, and also a few things that will keep you from driving your developers crazy.

You are Designing Something that Other Humans will Interact with

This is so basic that it is hard to know where to start. You are no longer designing just to catch someone’s eye, make your audience feel a certain way, or to make a product or company seem more friendly. You are now designing elements that you want users to recognize as interactive, and then proceed to interact with those elements. So buttons need to look like something a user might want to tap on or press. Somehow you have to indicate to your users that this is an interactive element. The same goes for links.

There are plenty of well established design patterns for this. Menu icons, button styles, and even standardized link styles will help in conveying that information to your users, but you also need to give some feedback that an interaction is occurring or that it has been successful. This is where hover states, active states, and focus states come in. You will frustrate your users if you give them buttons and links that don’t respond with they interact with them.

Interactivity is about responding to user input. Learn about the different states that you might add to a button, and don’t go crazy designing these states. Less is more when it comes to button and link effects, especially if you have quite a few of these on your website.

Content and navigation have to play well together

So now that you have realized that something needs to happen when your user presses that menu button, have you thought about content?

Let me guess. The client is providing their own content? That’s great, but I bet you are designing their navigation, and that navigation needs to have some relationship to the content… right?

So you are going to spend some time working with your client’s proposed site map. This is where your digital marketing prowess will come in handy, because you are going to tell them that submenus inside of submenus inside of submenus might not be a great idea, or that top level menu items probably need to be short and sweet and definitely under three words long.

You are going to realize when you start mocking up these menus based off of the site map, that their site map is implying some things that might not work so well. So have an idea of how you want to guide them.

If you think simpler menus are better for their design, then that main navigation might need to be slimmed down, and remember that the menu is generally for the end user not your client. It may look cool to have images, videos, and multiple columns of menu items in your dropdown menus but that may not actually be the best design choice for the site. Think about what your end users are actually going to look at and click on.

Welcome to the Mobile Web

Speaking of which, now is a good time to think about how that giant menu is going to work on mobile devices if you haven’t already. You can start with mobile rather than desktop, some designers really like to start with mobile, but you don’t have to. Just remember that on mobile most of those ‘click’s’ will turn into a ‘touch’ or ‘tap.’ ‘Hover’ isn’t a thing, and ‘swipe’ decidedly is.

Design with touch interactions in mind. All of those mobile menu icons and buttons are big enough for an adult human finger to touch them without touching other links or buttons at the same time, right?

You are also carefully designing with super small screen real estate in mind for all of those tiny iPhone 5 screens that are still out there.

I’m sure that you have already done a little bit of market research and figured out the range of devices that you would like your design to fare well on, and maybe even negotiated a little with your client on the edge of those ranges.

Hopefully, you have also talked to your developers about what they think is reasonable to support. Your clients will want to support everything imaginable. You will discover a growing expense that directly correlates with the age of the devices and browsers that you try and support. Supporting older devices and browsers are much more development intensive.

Sooner or later, you will have a client who owns a very decrepit Samsung tablet from back when no one knew Samsung even made a tablet, and they are going to want to know if their new fancy website is going to look good in landscape mode on that 8+ year old tablet that their kids are still using. The answer will be ‘no’ but you will need to find a diplomatic way to deal with the situation and similar ones that arise.

Did I mention landscape mode earlier? You will need designers and developers that have a good grasp of responsive website design and development because you do not want to try and design for every possible range of device width and device orientation out there. That is to say that it is much better to have a website that reorganizes itself properly for different screen widths rather than worrying about hundreds or even thousands of different possible canvas sizes and orientations.

Three designs should cover most of your needs: i.e. a small mobile layout for small devices in portrait mode, a medium layout for tablet devices, and a large layout for desktop. There are plenty of well established breakpoints out there for responsive web design and development. Use those if possible, and try not to veer into making too many unique ones of your own. Every new design variation equals more development time, which will add up to a much larger expense. If your client is footing the bill for all of that development time you will need to keep that in mind and err on the side of frugality where possible.

Web layouts are dynamic

I mentioned it above, but it is worth mentioning again, you cannot control or design for every possible device size and orientation. There are just too many of them, and guess what? Each of those devices has multiple browsers that run on them that might also impact how your design renders. So you need to develop an understanding of how HTML and styling can respond to different device sizes and orientations.

For example: text wraps. That’s why putting five words in a menu button is a bad idea. it’s going to wrap on mobile, and suddenly one mobile button is going to be much bigger than all the others. The same way you have limited usable design space on a business card, you have limited space in a menu item, and this is especially important when considering if your clients might want to add more menu items in the future.

Text wrapping is one of those very necessary parts of the web that endlessly baffles print designers and clients who are accustomed to the pixel perfect arrangement of a well crafted brochure. Text has to wrap. Do not try to perfectly design where a line of text breaks across every screen width.

Millions of dollars, possibly more, is wasted every year by print designers and not-so-web-savvy clients trying to get their developers to write custom code and styling to keep lines of text from breaking in inconvenient places. This will come up often. So remember, you are not designing a poster or a billboard.

Text is going to wrap based upon the space that it has to work with, and a skilled developer’s job is to make sure that the layout responds correctly.

Did you notice how all that extra text didn’t leak out of the button, it didn’t disappear or get cut off, and it didn’t end up jumping on top of anything else? Did you notice how that callout box managed to contain all of your extra text and expand as the paragraph got taller and narrower on different screens? Your developer did that. Your welcome.

Background images — it is a remarkably similar problem to text wrapping. When aspect ratios change, which they will for different screen width, how the background image covers the area will change. That means a focal area or area of interest in an image might shift or even get cut off.

Honestly, I’ve had to explain it to more than a few print designers. Why does this image position differently in a panoramic space — lets say 300px height and 1600px width, than it does in a mobile space that is 200px by 400px… Because it does.

Developers have a little bit of leeway in tweaking this but frequently we end up with clients that want the focus point on one image in a standardized layout to be on the left, but on another page it will be on the right, and can we shift that when we get to small screens? Can we customize it across all 50+ pages of our website for each layout (mobile/tablet/desktop)? This can get hairy and time consuming very quickly. So pick good images for the space that they are designed for and maintain some consistency across similarly designed pages.

Also, you should consider just having different images for mobile that are already optimized for the space they are in. It is often substantially easier to just give the developer the correctly sized and cropped image for that small screen than trying to get them to spend hours tweaking how a large image responds to a smaller canvas.

Website content changes

If I had a nickel for every time I worked with a designer who designed a page layout without considering how it would look if the content was entirely changed, I would have quite a few nickels.

So what happens to that carefully designed callout box if it suddenly had a three line heading instead of a three word heading? What would happen if your client put an image there, or a bulleted list? Sometimes your custom layout may need some content restrictions, and you may need to work with your developer to figure out the best way to make that happen. You will also need to communicate these issues with your client who I promise will imagine that they can add whatever they like to whatever space that you have designed for them.

Digital Content and Services should be adaptable to a wide range of users

This is the hard part but also the best part of working on the web.

Your website shouldn’t be a brick!

What do I mean? I mean back when most content was delivered via printed pages in a book or newspaper, you could safely assume that your users were going to navigate with their eyes and fingers right? Content came in a very static form, like a brick. It didn’t change and you could reasonably expect your users to figure out how to work with what you were presenting them. If they couldn’t work with what you were giving them then they just got left out.

Likewise, on the web today, many designers and developers assume that their users will navigate their website with a mouse, well functioning eyesight, perfect lighting conditions, and a never-dimmed backlit screen.

Don’t assume anything is consistent about your users, and more importantly remember that digital content is not brick-like. Digital content is infinitely adaptable and that is why you should be trying to serve the widest range of users that you possibly can. That means supporting users that want to navigate via mouse, keyboard, touch, screen reader, and even voice interfaces.

Digital content can easily be resized, recolored, shifted, relocated, downloaded, repurposed, or even read out-loud by end users devices. This can be challenging to stay aware of and work with, but it is also what makes the web such an incredible medium to be a part of.

You can get started with accessibility by just being aware of a few important things:

Contrast matters — find a good contrast checker and aim for 4.5:1 or higher for all of your standard text content. Larger text (24px and larger) can use a 3:1 contrast ratio, and be be aware of how readable text is when sitting on top of a background image.

Don’t disable zoom — ever.

Avoid autoplaying content.

Leave your focus outlines on — keyboard users use these for navigation. You can improve the design of them if you like, but please don’t get rid of them.

Use HTML and styling instead of text images where ever and whenever possible.

Respect heading order — document structure should be logical and not based on styling preferences.

Test your forms and workflows with a screen reader! Trust me. You have one built into that Mac you are using for your design work. I promise you have one. “Command F5” — try it out.

There is much more to accessibility but that will get you started.

Check out this article on how to get involved in global accessibility awareness day:

A few other things that you can say that will make your developer laugh (or groan) at you

“Did you know that fonts render slightly differently across different browsers?”

Dev: Yes. Its actually a much bigger problem across operating systems.

“Why can’t we just let the responsive HTML to do it’s thing?”

Dev: You know HTML doesn’t magically become responsive on its own? Right?

“How come this giant square image doesn’t look right in this narrow space designed for a panoramic image?”

Dev: We gave you image dimensions, could you possibly use those?

“Why does this image load so slowly? It’s only 10mb.”

Dev: That image file size is 100 times bigger than it needs to be.

“We need images appropriately sized for the web? Can you optimize my 200+ images for me and then re-upload them to our site?”

Dev: Let me google ‘3rd party image optimization’ for you.

“Embedded 3rd party content doesn’t need to be accessible… does it?”

Dev: “It does in fact need to be accessible.”

“I’m working on my meta-keywords.”

Dev: Your SEO techniques are about 10 years out of date.

“Can you turn off that weird blue line around my buttons?”

Dev: That’s the focus state, and it is essential for keyboard navigation.

“What is a hover state? / What’s a style guide? / What’s a wire frame?”

Dev: What kind of design did you say you had experience in?

“Why can’t we customize where the text in this callout breaks across every page — all 50 of them, for all devices.”

Dev: If you went live without these perfectly customized text breaks, would you have a single website visitor ever notice or care? Seriously, if the answer is ‘no’ you might not want to spend developer time on this.

“We need motion on our site, can you add (insert random effect here).”

Dev: Motion, like any design element should be used with purpose and moderation. Please don’t just add motion because you think it will make your site more “modern.” Your site visitors will be impressed with well designed animations and effects that work cohesively with your site design and serve its overall strategy. This is the age of the smart phone, I promise no one is impressed with your perpetually moving ads and gratuitous parallax effects.

“We would like this to autoplay.”

Dev: I promise you do not have users that like autoplaying content! You don’t!

In conclusion

Obviously, there are more things to learn, but this should get you moving in the right direction and hopefully reduce the headache of the developers that end up working with you.

I know the web is a very familiar place for you, but there is a good chance that interactive and accessible design is very new territory. That doesn’t mean you shouldn’t be here. There is always room for better design on the web.

Do you remember what it was like get “access” to the web when you were young, and when the web was much younger? Remember when you used the word “access” to complain when you couldn’t load a page, download a video, or “access” your email? There are still users struggling to get access to many online sites and services out there and they would love to interact with your carefully crafted website. Keep those people in mind and build/design for the widest range of users that you can.



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s