What are some good seminar topics that can be used to improve designer&developer communication?

Question

I'm development team leader in a internet service company that provides service that's very similar to dropbox. In our company we have mainly two divisions: the tech division and the designers division, both have their own reporting hierarchy. Designers focus on designing UI and prioritizing features, while developers focus on implement designers' ideas (more like being driven as our big boss has said).

Then here comes our issue: the DEV team and DES team communicate very bad. DEV complain DES for these reasons:

• Too frequent changing of requirements
• Too complicated interaction (our DEV team has actually learned many HCI principles)
• Documents for design are incomplete, usually you just get 'design principles' and it's up to DEV to complete design details. When you find design defects, you ask DES team to resolve them, then DES team quickly change the principles and you gonna spend another several weeks because the change is so fundamental.

While DES complain DEV for these reasons:

• Code architecture is not good enough to adapt to changing requirements (Obviously DES knows something about software development)
• Product design is about principles, not details. DEV fails to realize this.
• Communication should be quick and should be mainly oral. Trying to make most feature discussion in document for reference is too overloaded and doesn't make sense in a Internet company (cuz 'the world outside changes fast').

As you can see, DEV and DES have different ideas on product design, and encourages very different practice. We have this difference because of the way we work. So our solution is that we should plan some seminars to make each part more aware of the way the other part work. Then my question is, what are some good topics for such seminars?

Guessing some people may not think seminars can solve this problem, please also suggest your solution.

Answer 1

Seminars are likely to be a good idea since in the real communication people of different divisions would be more kind to each other, than when they report through the managers.

You may use some of the following themes for these seminars; also note that it would be great if seminars are started by a team leader with remarks about the end-user experience and goals of the organization as a whole:

1. Why even a small change takes a lot of time? Review the following blog post by Eric Lippert: How many Microsoft employees does it take to change a lightbulb?, your DES team shall clearly understand why it's not always easy to change the way things are working;
2. Why it is important to pay attention to the details? The DEV team is likely to be inclined to implement things a little bit technically, i.e., a click on any button produces a sound, whereas only the OK button should produce a sound -- the DEV team might argue that it is hard to implement a sound only for the OK button. Of course, my example might be ridiculous, but such cases are happening.
3. Why continuous feedback and objective discussions are important. For example, if you don't have it yet, it would be beneficial to introduce a continuous integration system that would compile the latest DEV build so that the DES team might review it as early as possible. In some cases, the DEV might spend 3 weeks building a thing that the DES would not like. This can be avoided if the DEV frequently demonstrates the DES what they are doing.

Furthermore, there might be indeed a problem with the hierarchy of organization. Instead of functional divisions, you may try to introduce project divisions, so that there are NO distinct teams of DEV and DES, but rather designers TOGETHER with developers participate in project teams of building specific features. The responsibilities of each other, as well as the workflow, are better be clearly stated in a short formal document that everybody accept. The benefit of a project team is likely to come especially with rapid prototyping, e.g. a designer shows developer a picture, the latter makes a quick prototype (not actually working, just pretending to be the actual thing), then both discuss which issues do they face.

Answer 2

I would:

• communicate repeatedly and constantly that everyone to focus on the work that's produced for the customer and the solutions that work for the customers.

• Make sure the user voice is the one 'heard' the most.

• Seek agreement where you can. Trying and see how many points you can get joint "yes's" on. Then move on to points of disagreement.

• Get folks together socially and ban work topics. Try a day of outside work activities like skiing or a retreat or something. People that can have fun hanging out together can do a lot better job when it comes to working together.

• Encourage people to think "outside the box". Since people can't just 'switch jobs' at the drop of a hat, try having a 2-3 meeting where, for that meeting, people "switch roles" and represent and advocate for each others area, instead of their own and make convincing argument for that other area. Wearing the different hats can be most educational.

• Listen. Many folks get frustrated because they feel passionately about their subject area and they just want to be heard. Don't assume that you know what they want or what their viewpoint is. Even if their viewpoint is counterproductive and wrong, be gentle in closing them done and just listen first. Remember to ask everyone their opinions and wait for 30 seconds of awkward silence to be sure that shy people really get the chance to speak. We know the outspoken folks will chime in first so let others speak too.

Answer 3

From the dev side, the thing I would really like to see in a seminar for designers is a demo of how much stuff one of those "minor" changes means we have to change. I wouild want the designers to understand that what looks like a simple change on the surface of the UI often is cvery complicated below the surface.

In fact, it might be a good idea to have the devs devlop a curriculm for the designers' seminar and the designers develop one for the devs' seminar and the managers develop one on communication and project management for everybody.