Damn this SXSW ballroom A Wi-Fi! It’s holding me back, and making this post join the action in progress…

British guys from Flikr and BBC. Dave Shea from CSS Zen Garden. He’s from Vancouver. Who doesn’t like Vancouver? No one.

We’re focusing on the relationships between designers and developers, getting them to love each other and work together well. The designer husbands and their developer wives.

They’re talking about collaboration models that oppose this "waterfall" method we keep hearing about. Also small teams (like 20 people) and how they work well together. bmngj

Basic collaboration seems like the client comes up with an idea, you put that in a magic design box and they get it back.

Usually, it doesn’t go this way. There’s a ton of back and forth. Collaborating with someone on the design, and then working with developers. And there’s a lot of push and pull. A lot of clients who are calling and asking for technical translations from the developers…

Woman who’s worked at Flickr as the lead designer "since birth" — four years.

Paper & Whiteboard

She likes this method because she can work collaboratively with people: wipe stuff off, write stuff on, change, etc.

She’s also been able to watch the Flickr team grow from three people to 40 people in the development team.

It’s also ballooned out into a number of different support areas to be able to handle the org. There are over 2.3 billion pictures in the catalog, posted by more than twenty million people. She still can’t believe it.

She’s talking about releasing early and often. Another guy on the panel also talked about this as opposed to the waterfall or "painting" method — they’re talking about sculpting between developers and designers. This is the way people work best in teams now, to sculpt apps live, working together to create better stuff in shorter times.

I think that everyone responds well when presented with an interface. Being able to talk around an interface is very useful. Since designers are good at this kind of thing, it gives designers influence that developers don’t have. Although there are so many rapid dev apps that have to handle a ton of Data that developers are gaining more in this type of iterative designing.

Initial designs in a Doppler UI, many people will be used to the iconography of many more friends than trips. But they didn’t try these things out because there’s no bounce in the iterative process between design and coding.

Because Dave works directly with clients, we both understand that decisions need to be made in everyone’s best interests. And this works well.

As a developer, the most frustrating thing that happens is when he’s handed a design and told, "build that." He likes early collaboration, so that he can understand what happens in the system.

From a design perspective, what’s annoying is when developers say, "Just skin this for me."

They agree that wire framing and early whiteboarding is good. Also being in the same physical place is a big help.

In a past conference, Jason said, I can’t design something that I can’t understand.

George — that has everything to do with how the design is put together — collaborating at an early stage it comes together well. It’s the top-down stuff that hurts the process all the way down the line.

Dave copes with this from the outside by being a designer and pointing to past examples. Developers don’t necessarily have that luxury.

Prototyping with live data also works well because it gets both sides of the brain working. Another panelist says that prototyping allows developers to get involved and see what works.

One favorite of the dev team is a Russian guy at Flickr, he can do weird stuff like running unique schemes that provides new outlooks on the data, and that helps open up the design.

In large companies, the skill sets determine a lot of how the process works with prototyping. That person might be a designer, a developer, or a customer care person is looking over their shoulder.

This seems perfect as a process with Flickr because of the API, it offers a lot more flexibility and faster prototyping.

You mentioned Job rocks – do people need to be multi-talented generalists?

Those projects always go better, because people understand what’s possible technically within a medium.

It’s also important to have specialists, what you share is general and deep understanding of the product, and the voice of that product.

Writing that voice also helps understand the programming and design within the product’s range.

Another panelist agrees, writers are important to understanding the process.

Knowing a little about server-side programming, Dave can head stuff off as a designer and in client expectations. This is a problem with people from the print side. It’s not a fixed canvas.

If you’re an independent, generalize. And if you’re looking for a freelancer, look for a generalist.

The best developers are client-side dev. And this is a difficult spot of dev, because there are so many platforms that the interface needs to be drawn for.

Java is also gaining popularity, which is interesting. Obviously, it’s nice to work with generalists, but specialists are very good as well.

Now that interface tools have gotten more streamlined, dev members of the panel say that’s a great way to see how their work is being drawn in the interface, do some basic prototyping, and have something to show people how the system is working visually.

Someone once said that process is for stupid people — to guard against repeated mistakes.

Dave doesn’t know if he’d call the people stupid. In estimate docs, he clearly outlines the process in the doc, but then explains that the process is accounting for when things go bad, but it’s not the way he usually works.

After working at the BBC, there were so many things you couldn’t trust to be there, not so much in process but in resource allocation. For a long time he wanted process to work, and realized how many bad project managers there were. So he ran away. Picking the people he likes for work worth doing.

Humans in general don’t respond well to anarchy — the waterfall process may not be great, it is boring, but it’s also useful. It helps you mark achievements, keep people on track.

The trouble comes when you add in a bunch of inputs that don’t move the product along faster. Any feature dev they do now at Flckr opens the chance for more mistakes with all the translation models. On the flip side, it’s fantastic that they can reach all these people.

How can I as a developer make myself easier to work with?

Well I think the main difference between sites and web apps is the fact that we’re working with an organic information system. It’s important for Web designers to understand this going into it. What does it look like with zero data? Developers have insights into what situations happen in data constraints that move all the time.

Show you’re working. We’re all kind of have philosophical ideas about the work they do. Getting the insight into the design helps developers when they’re getting into the programming. Understanding the model, the "whys."

At Clearleft, they’re building HTML prototypes, with hidden notes in the page, to explain to developers what they need, and a button to show or hide those notes.

How can we communicate better?

This is a place where technology may save us. Using templating technology, he makes templates that are so bad, designers want to dig in and understand it. Having some kind of templated system where developers can make changes helps developers.

Dave says talking about abstract ideas is tough for developers. You have to start the conversations with prototyping.

Related posts:

1. SXSW Live: Right Way To Wireframe
2. MySpace Apps – how we doin’ so far?
3. SXSW Live: Design Eye for Southby
4. SXSW Live: Life After the iPhone