Most of our projects at Mule involve working with other developers, whether it’s the client’s internal team or another contractor. Either way, because our design process goes all the way through front-end code, we do everything we can to make sure the transition from design to implementation goes smoothly and that the implementation team has everything they need.
Over the years, we’ve found that it takes three essential elements to have a successful relationship with an external development team. Obviously, your code needs to be of high quality. But respect and trust are just as important. If you establish those up front, everything else will flow easily.
An implementation team has their own processes and have probably done a fair bit of coding as a group, so much that they have complete confidence in their code. In addition, they’ve probably seen their share of questionable code coming from designers.
Remember, these developers have to build an entire website from the code you hand them, probably integrating it into the template files of a CMS. If they haven’t worked with you before, you may need to convince them you’re capable of giving them code they can work with, and that you understand the constraints they’re facing.
Don’t take it personally if they sound skeptical when you start working with them. Understand that they have their own deadlines, and may be dealing with organizational politics. Talk directly with the appropriate people on the team. Explain your process and make sure they understand that you share a common goal: building the new site successfully.
Find out if they have specific internal processes that could affect your work. Do they use code sprints to build? Do they have internal HTML/CSS coders? If so, are those coders aware that you will be delivering code and not just Photoshop files?
We have a technical requirements meeting during the discovery phase of the project, usually within a week or two of starting. Sometimes we even have that meeting before the client signs the contract, because their technical staff needs to know that they can trust us and that they won’t get stuck with problematic code.
Make sure the implementation team has an opportunity to review both the IA and visual design of the site for feasibility. Work out what level of feedback and how often the tech folks will be included. There’s a good chance they’re working on other projects while you and your team are designing and prefer to not be pulled into meetings and technical reviews, so be clear that what you need is just a high-level check for any potential issues.
It’s important that everyone understands that these check-ins are not for them to figure out how to build a feature, only if they can. The point is to make sure they are not surprised at the end of the project by something they can’t do.
When you’re having those technical review meetings, pay attention. You understand the design system you’re creating, but they know the system and language(s) they have to build it in, and more importantly, how the site will be maintained going forward. If they tell you that your clever solution is going to be too difficult to build or maintain, pay attention. It might be the case that they just need it explained differently or it might be that they’re right, and the clever solution is wrong for this project.
This should go without saying, but years of watching designers and technical people interact make it necessary to repeat: Be respectful of the implementation team. Don’t talk down to them. Don’t assume that their input is not valuable. The quickest way to win the respect and trust of a technical person is to treat them with respect and trust. It’s really very simple. (And of course that respect is expected to go both directions.)
In addition to people skills, there a couple of seemingly small steps you can take that will make a huge difference in how well this process goes.
To the implementation team, the code is the most important documentation. Give them valid code that makes sense and is easy to read. It’s amazing to me how often we hear people say “Hey, this code looks great!” when all we’re doing is what we consider the right thing. It takes so little to keep the code clean and organized, but it seems like there are a lot of people out there who don’t even try. Here are a few simple things you can do:
Indent your HTML properly. Modern code editors have settings that should take care of this, so there’s no reason not to. A block element nested in another block element should be indented. Also make sure that everyone on your side is indenting the same way. Tabs versus spaces is only a problem if one person is using tabs and the other is using spaces.
Organize your CSS logically. Again, this is “Beginning WebDev” stuff, but again, implementation teams seem to expect the worst from design shops. There are hundreds of articles out there about organizing your CSS, and the specific method is much less important than just doing it consistently, period.
Validate your code. Validation should not be the end goal of your code. There are some good reasons for knowingly using invalid HTML. But running your pages through a validator will allow you to be sure that you know what’s not valid so that you can explain it.
One of the teams used Git (via GitHub) and one of the teams used Subversion. Both are great, and for the kind of code we’re creating, there’s not that much functional difference. Internally we use Subversion (hosted on Beanstalk and using the Versions desktop client).
When you deliver your final code and documentation, be clear that you are still available to discuss issues that come up during implementation.
The code handoff is the final act of a long process and the point at which the project moves from your control to someone else’s. It can be a make-or-break moment for the project, so don’t make it the last thing you do. The final step in the project is the successful launch of the website you designed, and it’s in your interest to make sure that happens.
Mule creates delightful interfaces, strong identities, and clear voices for useful systems and nice people.
Also, We are funnier than all other designers.