Articles

All Walls are Just Barriers

Inevitably, a project arrives at this stage: throw it over the wall.

Of course, this proverbial wall is nothing more than an inflection point at which a developer or a designer needs to take the other's work and move forward, often ending in another inflection point where the bits get handed to the opposite party. This happens even on the tightest and most integrated teams and, in my experience, is part of the pattern of making a software product, a rich internet application, or any highly technical digital experience.

However, at every trade show I attend, whether it's the MAX conference or the Microsoft PDC, I keep hearing a refrain that does not seem to go away: designers and developers have problems not just working together, but understanding one another. I've noticed that these complaints tend to come more from those involved in enterprise-level design and development, as opposed to those involved in more greenfield contract services work.

How can enterprise-level interface and application design flow more smoothly? Perhaps through a combination of demystifying design and learning a few lessons from the professional services sector about the value of tightly-integrated design/development teams.

Design and Engineering are Both Sciences

I create an extensible system and vocabulary for representing data onscreen. Is that a developer or a designer talking? Both, actually.

Designers and developers of online experiences and software applications both need to keep the mantras of simplicity, extensibility, and flexibility in their minds. Software is never a fully static thing; it must evolve and flex based on user demands, business needs, and market forces. Just as developers must stay object-oriented and extensible, so must the design systems applied to their work.

Contrary to popular opinion, rarely are clients satisfied by design reasoning like, "It just feels right." Every decision, from font choice to proportion to layout to interaction patterns, should be backed up with either sound research, common best practices, brand values, or solid business drivers. Much like feature and functionality decisions.

Interface design largely is about creating a visual vocabulary for interaction patterns. Buttons should share similar forms, dialog boxes must expand to fill their contents, significant changes in screen state should occur similarly...the creation of such systems is rarely a right-brained activity. Such decisions, no matter how they are aesthetically executed, should be a synthesis of client requirements, brand values, user needs, and competitive benefits. In my experience, this differs little than how many engineers' decisions are made.

Designers and Developers that Create Together, Stay Together

Why isn't it a Standard Best Practice to have designers and developers be in each others' meetings?

All the best projects I've been involved in have required designers and developers to be in the same meetings. Guess what happens? Even in a worst-case scenario, in each meeting one party sinks into boredom until they hear The One Thing, that one bit of information that's either wrong, long-awaited, or otherwise critical. Then, suddenly, a huge iceberg of miscommunication has been avoided. And miscommunication has to be the Number One cause of poor profit, blown schedules, or team morale problems on every project I've ever been on. Frequent cross-disciplinary meetings are the best way to avoid them.

Designers and developers, y'all are on the same team. Spend time to learn about each other's discipline. Keep an open mind, and look for the similarities between your disciplines. And do not skip those shared team meetings. Don't be the proverbial herd of cats that needs wrangling. Be a competition-crushing machine, with all parts working together in unison.

Replace the Wall-Toss with a Calm Handoff

A corollary to these meeting guidelines is the informed, iterative handoff. Sure, sometimes a design or developer team does truly need to own big chunks of the project at once, but as one discipline continues its work, the other should be involved in reviews, discussions, and generally should remain involved in the process. This means that rework of any component can be of a more constrained scope, since the length of time between reviews will be much shorter.

In short, you can still toss from one team to another. But pass it through an open door rather than a solid wall.

Conclusion

Design and development are actually quite similar and are inextricably linked.

• They both strive for extensible interface systems.
• Both must be justified by best practices, brand requirements, and business needs.
• They must communicate effectively together to create great products.
• Each discipline must have open minds and ears for the other.
• Informed handoffs make each group more productive.

So...right. Duh. Of course. Seems quite obvious.

So explain to me why the professional services agencies all get it and large scale enterprises don't? Why aren't your designers and developers working better together?