Not sure what accessibility changes will have the most benefit to your existing software? Are you in the build process and need to make sure accessibility has been appropriately considered? Use this checklist as a starting point.
Some web designers write their own code; some don’t. Even if you’re in the former category, chances are you have worked with a developer who has been hired to bring one of your web designs to life (if you haven’t, you will soon). Sometimes clients have a developer already in mind and are just looking for a designer; sometimes a developer will approach you; the list of possibilities goes on and on.
With that in mind, us designers have to be cognizant of how we work and how best to make life for the developer easy. If you make their life easy, the project will run that much more smoothly and the client will be that much more happy. So how do we do that?
Hit the jump to find out!
Communication
As with any project, good communication is the key to a solid client-designer relationship. Talk to the developer; learn as much as you can about the project and your requirements. Are they building it on a CMS, or just straight up CSS/HTML? How many unique page designs do they need from you? Do you know the goals and objectives of the site? What are the specifics for each page?
The more information shared at the beginning of a project, the smoother it will run.
Basic Understanding of Development
Your life as a web designer will be infinitely easier if you have at least a basic understanding of HTML/CSS and web standards. In fact, if you don’t know basic web standards (common screen resolutions, etc), you shouldn’t be designing for the web. But if you have a basic understanding of development, you will make design choices that make sense for the web. For instance, you should know about web typography, the 960 Grid system, how CSS backgrounds work and so forth. This way, you can ease the load on your developer by letting them recreate as much of the design as they can using CSS/CSS3, as opposed to using images all over the place. Plus, this will make for a faster site.
Fonts
Thanks to an ever-growing array of web font resources, we don’t have to use the tried-and-tested “safe font list” any more. With that being said, when designing for the web it’s much easier to use open source fonts whenever available and include the link to download these files when you submit the PSD to the developer. If you insist on using a font that is not open source or licensed for the web (like Gotham), then rasterize that text layer in Photoshop before sending it along. Keep in mind that rasterized fonts are not editable, so keep a backup design with unrasterized fonts and generally only use these types of fonts for design elements or headlines that will rarely/never change.
Organize
I have a bad habit of not immediately naming my layers in Photoshop as I’m designing. This leads to a lot of “Layer 27” and “Layer 16 Copy 3” layer names, which are indecipherable to both you and the developer. However, I always make it a habit to go back through my final design, before submission to the developer, and name my layers semantically. For example, “Background” and “Slider Image” etc.
After this is done, I group all my semantically named layers into semantically named folders. By this I mean I take all the layers that make up the navigation system, say, and put them in a folder titled “Navigation”. Everything that makes up the banner goes in a “Banner” folder. It might take you some extra time, but your developer will love you for it.
File Submission
Every developer I’ve worked with has a slightly different preference when it comes to how they like their design files submitted. It’s always a PSD (Photoshop Document), but some like each page separated into separate PSDs (I normally make a folder for each unique page design and keep all pages in one PSD). Some developers also like a JPEG included; some don’t. Again, talk to your developer and figure out how they like their files submitted.
UX Ideas
Finally, be sure to go through the final file with the developer so he/she knows what exactly what you have envisioned. For example, do you want the company logo to have a slight CSS3 drop shadow when a user rolls over it? Do you want the hover values of your anchor tags to be a specific color? Do you have specific slider transitions in mind? All these items and ideas cannot usually be accurately conveyed through a static document like a PSD or JPEG; it is best to sit down with the developer, or use an app like BounceApp (just upload a screenshot of your design to your server) to highlight UX features you envision.
Working with a developer can be a great experience if you do everything in your power to make it one. If you follow these steps, your developer will be happy to work with you, and possibly refer you to others, thanks to your solid communication and organizational skills. Do you have anything to add? Developers, do you have any pet peeves when it comes to working with designers?