As a developer, working with a designer can be challenging. It doesn’t mean we can’t interact socially, it’s just that we don’t think at all the same way about a product and how to further it. The designer I currently work with has an artist’s background. His weapon of choice is a paintbrush, and Photoshop comes a close second. I spend most of my time these days squinting at Flex Builder. Together we have to find a common ground to build something for the Web.

Designer/developer workflow is a big problem in many organizations. I recently met someone whose sole job was to ease communication between these 2 parties.  This post describes how one developer worked with a designer using Flash skins, but it’s only applicable to a designer comfortable with Flash. Adobe is soon going to release Flash Catalyst. From what I understand, the idea is to help designers produce MXML. To me that just sounds terrible, because I really don’t want my job to be hacking code around some half-baked generated MXML. I don’t have any miracle solutions, but here is how we ended up working together.

We always start with a user story. For those familiar with agile development, no further explanation is needed. For everyone else, just look around, I won’t delve into it here, but here’s a simple example: The uploads a song to the server and it appears in a list. The designer comes up with an ideal way of doing this. It’s not his job to make it work, so he can dream up whatever he wants. He then tries to convey it to me. This can be done using slides, a whiteboard, a walk around the block, whatever he finds best. The point is that there are no technicalities involved, I only have to understand the intent.

The next step is for me to tell him what is possible and how long it will take, make suggestions, etc. In this way we come up with something that is both technically feasible within a specified time and satisfying from the designer’s point of view. If the time is too long, we can always go back to the drawing board for the user story. What’s nice is that in this way we know it before we start.

Then we agree on what needs to be done when: I tell him what graphical elements I need, and when I need them. Usually this is a batch of images that he will create in Photoshop. Then we get to work, and in a ideal case I get the elements, integrate them, everything works spiffingly and we wrap things up and move on to the next user story. Obviously it often doesn’t work that way and some adjustments are needed.

So why work together like this? We can stretch as far as we want in each other’s direction, but only as much as we feel comfortable. I get to speak my mind about the design, and he can speak his about the technical aspects, but it all stays on the same common conceptual ground: the user story and his intent on how to solve it. The caveat is that this needs very good communication and integration. It wouldn’t work nearly as well if we weren’t both in the same office. This unfortunately means quite a lot less working from home. But it seems to be a good way to come up with a well integrated product. If you have a suggestion on how to improve on this method, the comments are open!

Pin It