Designers often get a bad rap for their code. Many engineering teams are wary of letting designers touch production code. But it's essential for designers to code their own design work. As designers, we're experts at making software simple and easy for customers to use, and we can do the same with the code we hand off to clients and engineers.
We write quite a bit of code here at ZURB. Designers build their own designs. When we design a nifty layout or a crafty interaction we also commit to making it work. We work together, collaborating internally on the same codebase using Github, as well as handing off code to clients. That means our code has to be clean. And when you write clean code, you keep your colleagues sane.
Coding Rangers
We're working feverishly to launch a new and improved Forrst. This will feature a whole new mobile-first design with a new front end based on Foundation 4. Forrst is a huge undertaking to code up all those little pieces. Most of the groundwork was already there when I was brought on to help with the final pieces. The prospect of getting thrown into unfamiliar code can be daunting for most designers. But not here. The code was structured so well that it was fairly easy to get up to speed.
We work off a single Github repo, where all the component styles are logically split up into separate, neatly organized files. This has eliminated the friction that normally occurs when multiple members work on the same codebase.
User-Centered Coding
Like all great design work, we need to think of the user first. What would an engineer working with this code will look for? She could be looking for a particular HTML element to hook up with some sweet javascript, or a client's designer might look through your CSS for a class name to style. Approach coding as you would any design work to solve your user's problem. This is a little bit meta, since your code is already solving a problem, but read on for some practical advice on designing beautiful code that will bring all the engineers to the yard.
Use the Force, Luke
Principles of design, you will use, and beautiful code, will you write. Our coding is better than our Yoda-speak, we promise.
Hierarchy
Code should be logically structured and easy to peruse through consistent indentation of your markup. The logic you use to structure your CSS can vary based on your project. For example, if you're working on an app that has a lot of navigation items and toolbars, you could keep them together so they're easier to find and quicker to style. A simple marketing site can be structured similarly to the visual layout — header, navigation, content, and footer.
Modularity
Have an element you use often? Make everyone's life easier and take it out of your main layout. Put it in its own file, then include it into any page, using your backend language of choice. This is handy for footers, headers, navigation, you name it. Give your repeatable element a distinct — and consistent, we'll get to that next — class name, so it will have the same style no matter where you place it.
Chunking
Everything is better chunky, especially CSS. This is similar to modular HTML elements, but with styles, and for a different purpose. Separate your CSS files into individual files based on the elements you're styling. For example, put button styles in buttons.css, and navigation in nav.css, and so on. This was particularly useful for Forrst. It's a big app with a lot of nifty little elements. And to make it easy for people new to the project to hop on board, those little elements were separated out into neatly organized files, which made it super easy for the noob in the team (me) to quickly jump into editing elements.
Consistency
Use consistent names for elements, and consistent labeling systems. For example, we use all-lowercase-dash-separated variables throughout Foundation. If you have the same functionality in different places throughout your app, make sure you use the same label, and similar code to represent those actions. It will make it easier to repeat those elements.
You should also be consistent with your coding style. For example, don't alternate between multiple and single lines for CSS rules. Pick a style you're comfortable with and stick to it.
Framing
Set expectations correctly by clearly framing your code: first by using clear comments, and second by adding descriptive and detailed commit messages to your code versions. We've all been guilty of the occasional "bugs fixed lulz" commit message. However, as a practice, commit messages should be searchable and descriptive of the changes contained within.
Comments have been a great communication tool for the Forrst team. We use comments to note when an element needs more work or a second pair of eyes.
Go Forth and Code. And Conquer.
Using these techniques with the new Forrst codebase was an immense help in getting up to speed quickly. It helped reenforce the idea that designers should code, and design their code. Using the principles of design to write beautiful code will make your code a joy to read, edit and maintain for your team.