Translate Your Print-Based Design Skills to the Web

Imagine that you’re a designer at a creative shop working on a new Web site. The creative kickoff took place with the developers in the room, but you haven’t had to deal with them since. Instead, you take your direction from the creative director. Then you send your files to the developers and your work is done — or so you think. But the developers come back with questions about sizing, colors and “what happens when…”. And this is only the start. For the next six months, you constantly have to redesign page layouts and rethink the creative process. The project never ends, even after it launches. As a result, everyone is disappointed. The project took much longer and cost considerably more than planned.
Unfortunately, this scenario is quite common, especially when the designer has a strong print background. But if you follow a few simple best practices, working with developers can become a natural part of your workflow.
When you move from static design to Web design, it’s like tennis players trying racquetball. The problem isn’t that they don’t know how to swing the racquet; it’s that they don’t know all the rules and techniques. Because racquetball looks like tennis, they think it must be played similarly. It’s only after they realize the differences that they can then unlearn the strategies and techniques of tennis and play proper racquetball.
As a designer, you already have all that you need to create compelling work, regardless of the medium. However, take a lesson from those tennis players and identify the areas where the game is different. Your developers can help. Start by meeting with them and communicating a list of your concerns; ask the developers to share their thoughts on your initial design ideas. They don’t need to provide creative feedback, but you should ask if your design is possible from a development perspective. The earlier you do this, the better chance you have of avoiding roadblocks that might upset the project timeline.
Here are four more areas to consider before you tackle your next Web project.
Know Your Tools
When you design for print, you can use many different tools, but the end result has to be suitable for the medium. You can design a CD cover with Photoshop or with wood blocks, as long as the final format is something the printer can use.
The Web design process is similar in that you can use just about anything at the beginning. The difference is that you have to move to the single format much earlier than in print. One reason is that the designs of a Web site should be reviewed on a monitor. Another reason is that your primary tool of choice (most people use Photoshop or Illustrator for design mock-ups) will dictate and be dictated by some of the technical tools a developer will use to build the site.
Reach Out to the Developers
As a developer, I can say that we are not always the most social types, nor do we commonly understand the difference between Trade Gothic and Bodoni typefaces. Because of this, it is in your best interest to involve the developer in your creative process early. Yes, this may eat up some of your time upfront, but it can be a tremendous help later. Pointing out and addressing many kinks and design elements early will keep you from having to redesign the whole site to, for example, work with a language that takes up 20% more copy space than English.
Another advantage of earlier communication with developers is that you have the opportunity to teach them the message you’re trying to communicate. Developers who understand your creative decisions can help ensure that the outcome is what you expect. Of course, the developer won’t fully understand everything you throw at him or her, but the communication and feedback is immeasurably helpful in the collaborative process.
Know Your Boundaries… and Hex Colors
I’m constantly amazed at how much work goes into resizing a project’s elements after designs have been signed off and handed to the developer. I’ve even received mock-ups in tabloid extra format (that’s 12″ x 18″) and been told that I had a few days to finish development. Unfortunately, those few days went into resizing the entire site to make sure all of the dimensions were in pixel values.
As a rule of thumb, what you view on your screen at 100% is what the design will look like on a Web site. So many times I’ve opened a designer’s mock-up only to realize that the designer has been viewing it at 16.2% of the actual size (another tabloid extra nightmare).
Colors are a similar problem. I’ve had lengthy discussions with designers about whether RGB values are Web colors. RGB (red, green, blue) are actually monitor colors. True Web colors are defined in hexadecimal (“hex” for short) values.
Fortunately, many of today’s design tools have settings specifically for Web work. Typically, when the color picker is open in Photoshop or Illustrator, the hex values are the set of six characters with the “#” to the left of it. If you don’t see hex numbers in your design tool of choice, ask your developer how to find the hex equivalent of your RGB or CMYK color.
Think of How People Will Interact with Your Work
Approach your designs as if you’re the user, not the omniscient creator. Is your design intuitive? Can site visitors easily navigate it (if this is the intention)? Is your message clear?
Sometimes you’ll need people outside of your project to help you find the answers. But after a while, knowing where your users will expect certain elements to be (for example, a button is usually at the bottom of a form, not the top) becomes as ingrained as your knowledge that in the Western world, people read from left to right. Sure, you can break the rules and set type backwards, but you know when you’re doing that and why.
Start Swinging!
For some designers coming from print, Web design is out of the comfort zone. But this discomfort is only momentary if you can break down the walls that typically separate the technical from the creative. Remember to identify the universally common aspects of design while embracing the differences between the two worlds. Empower your counterpart in development to do the same. The resulting project will be an overall better design.