Let’s face it; an unhappy developer makes for an unhappy office. Or at least, that can be the case in our office where we have one designer (myself) and five developers. At any rate, we as designers should honor the coveted relationship between designer and developer. We are brothers in arms and together we can create awesome software, websites, apps, and whatever else. There are many ways we can nurture this relationship and establish the most productive working environment. At the end of the day, we all just want to make cool stuff. By limiting the friction between designers and developers we can really focus on making the best possible product for our users. In this post I will use a few examples from my work to show practically how these things can be done.
Clean up your PSDs, it’s the right thing to do
This one probably goes without saying, but somehow it still happens. Fast approaching deadlines, mismanaged projects, newly added features, etc. always seem to get in the way of doing this. It’s like cleaning your room when you were a kid, you don’t really want to do it, so everything else seems to get in the way. But come on guys, we’ve grown up. Right?
This is a quick and simple thing to do and it makes the life of your developer much easier. For your own reference too, it is important to clean up your PSDs. When you look back on your mockups after a few weeks, if you still have folders named “Rectangle 1 copy 5,” you will likely be confused and frustrated. I do a lot of my organizing and re-naming while I work, but no matter how much you do during, there is always a little more you can do after. Sometimes naming conventions aren’t so obvious until you’ve finished.
Slice up your own artwork
Some developers prefer to do this on their own, but you may find that if you do it well and understand what they need, this could be a hugely beneficial addition to your process. It was for us anyway. I started using the app Slicy with out last project and now I can’t imagine working without it. It saves loads of time, lessens your developers’ work, and ensures your designs will be executed more exactly.
How it works is you rename your layers or layer groups the same as the images you want to export, save your PSD, and drop the saved PSD into Slicy. Slicy extracts all the image files from your PSD and your done. You can see the naming conventions in the Photoshop layers image above (right). It works well with resizing images to or from @2x. And for those graphics which need special slicing, not the whole graphic itself, Slicy has provided a way to do this as well. Since I got Slicy, I haven’t once touched the slice tool in Photoshop. It does, unfortunately lack the ability to resize for the different Android DPIs, but there are other tools for that. I’ll save that discussion for another post.
Communicate design decisions
We as designers sometimes like to think our designs speak for themselves, but this isn’t really the case. For developers to execute your designs properly they need instructions and guidance. Depending on the nature of your workflow, this could be a well-documented PSD, ongoing conversations on HipChat, face-to-face Q&A, or a presentation of the overall design. For us, it is some combination of all of these. It is naive to think you can explain everything once and expect it to turn out exactly how you imagined. It is important to be accessible to your developers and it is encouraged to communicate with them not only after you’ve made decisions, but also during. This way, you will not be building something that is technologically impossible.
Design to the best of your abilities, not to the limitations of your developers
I am fortunate to have worked with this group of guys for a while now. We all started at different levels with different strengths and experiences. I made the mistake in the beginning of designing only what I thought was possible by the least-experienced member of our team. This ended up reflecting poorly on him as a developer, me as a designer, and more importantly, our app.
I’ve learned since to always design to the best of my abilities no matter what the developers are capable of. At first, you developers might actually be frustrated with you and chalk up your elaborate and risk-taking design as typical designer arrogance, but I’ve found after that initial irritation, they are actually quite happy with the result. People like to be challenged. Some people react to challenge differently, but everyone who has overcome a challenge feels a stronger person for it. It is this long-lasting satisfaction of a job well done that you as a designer want to see in your developers.
With our product, this surfaced with the implementation of something we called the Wellness Meter. It was a design with drops meant to reflect balance and harmony, but also visually display a statistic. The drop would sit in a track and relative to the percentage of activities performed in that category; the drop would fill up its track. The developers ended up rocking it, and now we have something we are very proud of.
Don’t forget the finer details, that’s your job too
I’m still guilty of this one, and it is something I always am striving to improve on. An example of this is to consider how many numerals will potentially fill a particular space. Your design may look good for double-digit numbers, but what happens if the number is in the tens of thousands? Another might be, consider how many lines of text will potentially fill a space. Does the composition fall apart with more or less text? Should you add ellipses or fade away the additional text?
And of course don’t neglect the interaction and animations. The job isn’t done when the UI is complete. Storyboards, like you see in comic strips, and good notation can help show what should happen to particular elements in the design. With mobile, there are a lot of commonly accepted and even pre-defined interactions, so you should be aware of those as a designer. Your developer can thank you for it later!
I hope you found this post helpful. If you have any questions don’t hesitate to ask and feel free to comment. If you want to learn more about the app used in the examples you can read more here.