Common ground

The biggest problem in software today is that programmers and designers simply don’t work well together. They certainly want to, but each craft sees the problem from their own point of view and, with the best intentions, each tries imposing their methods on the other group. But even agile developer’s sharpest tools aren’t going to work well for designers, and likewise, even the designer’s sharpest tools aren’t going to help programmers.

The solution will be to find some common ground where each craft is open to the best contributions of the other, without either side being forced to sacrifice their inherent strengths.

I believe that the solution, like most big things, will be relatively simple in concept, yet getting there from here won’t be easy.

Today, most of the pathologies of both designers and programmers can be traced to their mutual lack of experience working together. Most programmers will tell you their biggest problem is coping with rapidly changing requirements. Most designers will tell you their biggest problem is unresponsive programmers.

In the modern, agile world, programmers defend themselves against changing requirements by showing customers the program as often as possible, and by being able to make rapid changes to suit the customers expressed needs.

Interaction designers defend themselves against uncooperative programmers by doing ever more detailed design and documenting it with greater accuracy, detail, and precision.

But modern, agile programmers can work so flexibly that they don’t need all of that detailed and precisely written design. If designers could just blend into the development team, they could communicate their design directly without the overhead of documentation. They could provide a kind of just-in-time design service to the programmers.

On the other hand, interaction designers can master the driving principles of even the most complex domain so that programmers don’t need to make all of those changes. With a comparatively brief and inexpensive field study, designers can vanquish the changing requirements problem almost completely.

Ironically, the common ground for agile developers and interaction designers is one where the major problem faced by each craft separately is largely solved by the simple presence of the other craft, working collaboratively at a peer level.

That’s really good news for cost-conscious business people (now that’s redundant). Having designers and developers collaborate is very economical. Most of the cost of interaction design is incurred in the documentation and communication of that design. Similarly, most of the cost of software development is incurred in traversing blind alleys trying to elicit useful guidance from the stakeholders. Effective collaboration simultaneously discards the need for the two most expensive parts of product development, while driving quality—and user desirability—through the roof.

5 Comments

Shim Marom
Hi Alan, read your article with great interest. I'm not clear about your opening statement where you say that "The biggest problem in software today is that programmers and designers simply don’t work well together". I am interested to know where you got this conclusion from and whether or not it is based on an industry acceptable study or report. Irrespective of the above, and assuming your statement is correct, my view would be that if these two groups were to disagree/dislike/mis-communicate with each other, the reason for that would be more in the personalities involved where each discipline does not accept the 'right' of the other to produce artifacts relevant to their own discipline. Programmers need to accept the professional suitability of designers to provide them with design specifications. The Designers need to accept the work that the programmers are doing with their design, as they turn it into programming objects. At the end of the day it is about accepting what OUR roles and responsibilities are, versus OTHERS' roles and responsibilities. Cheers, Shim Marom www.quantmleap.com
Thomas Benoit
Great article. I've sent it to the PM on the project I work for :-) I would just add that "all of those changes" may also come from the marketing/direction, which has not plan all the strategy in advance... Whatsoever, I agree that it is a big plus if the designer masters the product domain, which is a challenge if the domain is new. Still, experience plays a definite roll. Thanks for this post
Jack Davies
I have been a long time developer and very much into Agile since Kent Beck and Ron Jeffries were on the scene. I got my introduction into Xtreme Programming by working on a large scale project with Ron Jeffries as a consultant back in 2000 and have been using it ever since. My main problem is that most developers are far too dogmatic about agile methodologies and don't realize that the manifesto was written at a time when Interaction Design wasn't where it is today. Despite agile methodologies being able to handle Customer's changing requirements, dealing with changing requirements (even with agile) is still costly and can be wasteful of resources. Also, in most programming resources, there is little if any information on properly "researching" customer requirements. Typically most agile projects build what the customer says with the push back mostly around technical difficulty. In recent experiences, interaction design has very much solved a lot of problems. Interaction designers are trained to uncover the "right" requirements based on customer's goals and not what the customers say they need. Furthermore, the up front design, prototyping, and iteration is really like building the product once on paper before it is ever built in code. So the learning/testing is a lot less expensive. My biggest challenge now, is convincing others that, in my opinion, design should be an up front process and not part of a development sprint. Again, dogma seems to be the barrier here. Maybe the original manifesto signers can make a Manifesto 2.0 version?
David Fore
Couldn't agree with you more, Alan. Though I'm still unsure what that middle ground is, exactly. Are you suggesting that interaction designers should forego design specifications owing to their expense and the fact that specifications subvert the Agile Paradigm? Or are you suggesting that Agilistas should accept that at some point in the process they and interaction designers are solving the same problem... IxDs through specification and Agilitas through code? (Probably not so much a "point" in the process, though, more like the IxD/Agile Zone... kind of like the Twilight Zone, but without the creepy music.) Knowing you, you're undoubtedly making a far more subtle point here. Please do tell.
Susan Chopra
Very interesting and thought-provoking article! As an interaction designer working in an agile environment, I have some experiences I'd like to share. First, I do agree that developers really struggle with requirements (and hence designs) that are rapidly changing. I don't agree, though, that the biggest problem designers face is unresponsive developers. In my experience, my biggest challenge - as commented above by Jack Davies - is finding the time to do the upfront discovery work and then also integrating continued discovery work into the process. I completely agree with your thoughts on the benefits of more collaboration between design and development. Like development, I participate in daily stand-ups, sprint planning, sprint demos and also story acceptance meetings, so I am seen as a peer more than a service provider. Designs are originally shared as low-fi wireframes (done in Balsamiq). The design details are worked out by collaborating with development as the design is being implemented. By doing this, we get much closer to the designs we are driving for, and development feels more a part of the design process - not just as though designs are being "thrown over the wall" to them. Thanks again.

Post a comment

We’re trying to advance the conversation, and we trust that you will, too. We’d rather not moderate, but we will remove any comments that are blatantly inflammatory or inappropriate. Let it fly, but keep it clean. Thanks.

Post this comment