By: Scott Baker, Art Director
If you are not a person that builds websites, or you don’t work on a team that includes designers and developers, you might assume that web design is simply the process that involves designing and writing all the html code. This website confirms that broad definition: “A Web designer is someone who prepares content for the Web.” Yes, it’s the code, but web design is truly the sum of many, many parts. Here are some of those parts. I’ll attempt to illustrate how and why these two roles need not be segregated in roles and responsibilities for effective web design.
The Graphic Designer
“What does a graphic designer do?” I don’t think most marketing departments can quite answer this question accurately (beyond knowing that they play in Photoshop all day and are artsy hipsters). If you are a good designer, those things are probably true, but they are not definitive traits. In advertising and marketing, design has always been the organization and execution of creative assets to give a tangible output to ad strategies. Typically these folks work in the creative space using illustration, photography and design theory to execute visual assets for brands. Graphic designers are the people who will create and lay out the visual beauty of a website. They will dictate layout, color, and content by priority.
The Web Developer
Typically, the web developer is the nerdy basement guy who throws code on a screen like it’s a scene from The Matrix. This isn’t a very accurate representation either — but it’s uncomfortably close. A web developer is typically anyone who can build web applications, websites or software. In this article, we are going to focus on the website part of it. Web applications and websites can be similar, but we are talking about websites built strictly for marketing purposes.
When it comes to web developers, you typically have someone who can write a programming language really well, like Ruby or PHP. These are the backend developers. But for this article, I will be focusing on the front end developers who write HTML/CSS and, a lot of the time (if they are good), Javascript.
Now that our players have been defined, let’s dive into why having these two roles work together (on nearly everything during the web design process) is better for your internal team, as well as the client, and can ultimately lead to stronger, longer-term website solutions.
The Difference in Roles and Process
Let’s pretend that in our fictitious big agency, the designers are in Building A and the developers are in Building B. This is pretty common in most larger agencies. They will hire a web developer and that person is required to be strictly a developer. They will also hire a web designer and that person will design mockups that will be passed to the developer, where he/she will be expected to make no changes and develop the designs as is. Sometimes the developer will receive mobile and desktop designs to help guide the responsive web design process. How’s that for collaboration?
The Fundamental Flaw in the Traditional Agency Web Design Process
There is something fundamentally wrong with this siloed process. The first thing is that responsive websites are between one and an infinite number of pixels depending on what type of device your users have. There is simply too much possible variety to accurately mockup a website in design that is supposed to serve a huge number of screens, sizes and devices.
I am not advising that we completely abandon the mockup process, but it should no longer be the start.
So what’s the alternative?
With the latest redesign of the Cement Website, we designed a set of assets, laid them throughout the site and created all additional assets as needed. Style Tiles are a nice way to start creating ideas to get things rolling. So instead of spending hours on making pixel perfect pages that will only look that way on one screen resolution, we should focus on creating modules that we can repeat and reuse depending on what type of content we need. Brad Frost designed a system called Atomic design which breaks down the design of our websites to the most basic elements.
Design Systems + Content First. How we work it all together
A lot of shops will build sites with a step-by-step process that is as follows:
- Sitemap
- Wireframes
- Static Design
- Development
This is a fine process and it works to get a website deployed. The whole process pretty much stops there, though, which does not account for 6 months later when the CEO wants to add a page featuring his new dog, because he thinks people will relate to that. So, you have to somehow hack together a page that will facilitate the new content based on the 10,000 different styles that you have on the site. Terribly inefficient, and yet all too familiar, isn’t it?
How do we solve this issue? Content should lead into design, with development woven throughout. The result? Extremely flexible websites designed around the content you need and built for the content you’ll want later.
First, define the content. The new process will be something like this:
- Sitemap
- Design and Content Inventory
- HTML Wireframes
- Design
For the initial release of a website, we need to define the basis of the entire site by creating a list of pages in a sitemap. This is where the process changes a little bit. Instead of going into a long painful process of creating wireframes, we simplify that process into a hyper-focused, approach by taking an inventory of the content that will be on each page and how it will be displayed.
So, let’s say we have a page that displays products. A sample inventory of the page might look like this.
In the first column, we have the page. Typically we will list all the pages of the site. Then in the second column we have modules. Essentially, the modules are reusable elements that we can use in many applications across the site. So instead of saying “Product Card” we call it Card. That way we can reuse “Cards” for any type of content. In column three we define what the type of content is that goes in each module for that specific page. The modules in the second column can be reused on other pages with other copy in them, but the type of content, such as page titles and brief descriptions, stay constant.
What we have essentially done is create our mobile wireframe. This tells us from TOP to BOTTOM how are content will be displayed on a mobile device.
The result is an entire Excel sheet that outlines our entire website, its content and the types of styles that should be applied to it. Let’s design this thing right? Almost. This is where the “design is development” point really hits home.
At this point our developer should have been taking this excel sheet and applying it to the HTML source in a semantic way. This may seem like the guts that no one would care about, but this is probably as important as how it looks and something you should definitely take note of.
The importance is semantic markup. Google *loves* this stuff and also it helps create predefined elements that can be reused without slowing the site down. Also this is the foundation to the website.
Once this is complete, we can start including design and copy. Since we have already defined the type of content on the site, its order and what pages we have, it’s all about making it look good.
Typically we can design modules and place them into rough layouts. If it is 100% necessary to get stakeholder buy-in, we can design the home page — if that’s important. I typically like doing this because it helps define the tone of the site. As long as you have content and HTML set, it’s easier to understand how these things will live on the site once complete.
Communication
As in any relationship, the most important thing to consider is communication. This style of mobile-first development/design requires constant collaboration with everyone involved from the client all the way to the developer and back. To practically facilitate this, try setting up weekly meetings or status updates to make sure that everyone is on schedule.
This process can become very disjointed if people don’t stay in the loop the entire time. So, it’s important at the beginning of every project that everyone who needs to be involved is involved and that they fully understand the implications of the process. The beginning and middle parts can be a bit boring to deal with, but the end result will help your websites flourish and allow for the site to live on longer and stronger because of the foundation it was built upon.