Are engineers from Mars, and designers from Venus? Communication between the two groups is famously fraught with difficulty: they speak different vocabularies, often have different cultural values, and may not even have a tremendous amount of respect for each other’s chosen profession! However, simply being literate in each other’s design deliverables can go a long way towards bridging the gap between these two groups. Engineers can read interaction design deliverables: it is now up to designers to become literate in technical design deliverables.
It is cliche that engineers have a limited respect for non-technical people who attempt the influence the design of software products. Engineers are often under the impression that the professionals who use job titles like “Interaction designer” and “Information Architect” are basically making it up as they go along, an impression that isn’t helped by 1)the lack of credentials in these fields, and 2)the fact that engineers (including yours truly! ;->) have successfully been bluffing their way through the interaction design process for many years.
System design requires knowledge of technology. You have to know what is possible, what is impossible, and what is really hard and should only be suggested if you can prove that it is really worth doing. Attempting to design software products without understanding technology at a basic level is like being an architect who doesn’t know anything about steel girders. Unfortunately, the field of Technology(TM) is so broad and overwhelming that design professionals often tune it out and restrict themselves to learning about the presentation layer technologies like html and flash. But a smallest bit of knowledge about the persistence layer goes a long way towards improving communication with engineers.
Design often occurs not before but in parallel with development. And the first part of the software to be crafted is typically the data model, typically represented by a relational database design. The biggest stresses to the designer-engineer relationship come when the designer suggests a late change that is not handled by the existing data model, requiring a reverberating echo of (expensive, risky) code changes throughout the different parts of the system.
On my team, a poster of the data model gets printed out on a weekly basis. The poster is hung in a place where both the designers and the engineers can view it. Design deliverables (wire-frames, mock-ups, and task models) are hung in the same place. Every week, as a result, there is a sort of informal gap analysis that goes on, as designers scan the data model for missing data that will be required by their interface, and engineers scan the design deliverables for design details that look like they will impose additional requirements on the back end.
Whoever first notices the skew has the upper hand in the ensuing discussion, with the conversation either starting “Say, I noticed that there’s a missing element in your data model”, or “Say, I noticed that your new screen displays some data that isn’t supported by our design”, depending on whether the designer or the engineer was the first to spot the skew.
This approach has the following benefits:
1)Skew between the data model and the interaction design is flushed out early in the design process.
2)Mutual respect between designers and developers grows over time (this is particularly true for engineers: when designers are able to read a database diagram or an xml schema, it instantly increases the respect afforded them by developers).
Designers don’t need to be technically proficient enough to DO technology design: they only need to be technically literate enough to UNDERSTAND something about technology design. This is approximately equivalent to the difference between being able to read music and being able to write music. Some talent is required to write music, but anyone can learn how to read it.
I’m now experimenting with publishing other engineering design deliverables (mainly UML sequence diagrams) in places where the designers can see them. The designers seem to be able to interpret them without much trouble, and the resulting flow of information is already paying dividends.
Agree? Disagree? As always, feel free to comment.