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.
jonathanboutelle.com 
Hey Jon,
GRRRR!!!! I dont agree with you dude.
The problem is with the PROCESS, and NOT with the designer’s ability to understand technology.
I would say that Development blokes dont really understand User’s Mental Model and that they are stuck with Implementation Model.
Problem : “Design often occurs not before but in parallel with development”
Design must START a loooong long way before development begins.
As far as speaking a common language is concerned, a formalised UCD model with
personas and scenarios ( erst while use cases) can be used to bridge the communication gap, rite?
What say?
Cheers!
Muthu 🙂
http://muthuonline.com
En garde!
In an ideal world, much more design would occur before a line of code was written, that’s for sure. However it is unrealistic to expect a design to be _finished_ before work begins, for the following reasons.
1) The time pressures that global capitalism exerts upon the design process simply don’t allow for this.
2)A lot of design issues only become apparent once the code starts running (hence the run-away popularity of usability testing, which seems to consume the lions share of the typical UX budget _despite_ the fact that it typically comes too late in the design cycle to do much good).
3) Design IS effected by what is technically feasible. Functionality that is desirable (but not essential) to the primary persona WILL be cut if the alternative is missing the christmas season, for example. What is hard vs. what is impossible often becomes apparent only once the code hits the road (at least if you’re doing something new).
From a political / organizational perspective, getting literate (not fluent, mind you, just literate) in technology design visualizations has tremendous advantages. The typical complaint of designers in high-tech is that they are not respected by the engineers. Understanding and giving feedback on the design visualizations that the engineers produce is an _excellent_ way of earning that respect. If it seems petty, just think of it as a “jedi mind trick” for handling the poor naiive technologists that you interact with at work. ;->
Personas and scenarios don’t completely bridge the gap I’m referring to: a well-written persona or scenario will NOT earn points with your engineering peers, even if it does communicate your viewpoint. The basic human dynamic that my post is trying to summarize is this : until you read other people’s documents, they are unlikely to read yours.
Regards and best wishes,
Jon
I happen to totally agree with the original write-up. I subject my business counterparts to my ER/OO diagrams all the time… as a matter of fact, they can’t avoid them…because it’s the main thing I hand them, along with a simple write-up describing what they are looking at. (I’m a big fan of the *short and to the point* design doc)
At first I think these people tripped out on what I was giving them. They were used to 50 page documents. Now they only get a diagram and a 2-page write-up…and a scheduled meeting where we sit down and throw darts at it. I can say this technique has been working like a charm! 🙂 I feel I’ve really bridged the communication gap around here.
For bigger project efforts, like the one I’m starting on now, up-front design is certainly a longer process. But I like to get started quickly because I also agree that design-as-you-go is very effective. We’re building the first SOA around here, and being that this is new stuff you cannot predict the right design up-front.
Hey Jon,
I agree that it costs a lotta time, money & effort while making major changes during the fag end of the project life cycle.
While its cumbersome for everyone to go thru & dicusss a 50 page spec document, i use a plain HTML prototype during the early stages of the project, like this one for example :
http://muthuonline.com/india/prototypes/soch_proto/soch_home.htm
And i found that its a lot easier for everyone to discuss the site structure using a prototype.
And hey, its become a basic pre requiste for designers to understand tech considerations before commencing design.
Do let me know how you go abt designing UML sequence diagrams.
Cheers!
Prototypes are _always_ the best way to communicate design if you can actually pull them off!
UML sequence diagrams: the tool everybody uses for this kind of stuff is Visio. The basic idea is simple: the y dimension represents time, the x dimension represents discrete modules of code (for example, the web server, the database, the image cache, the foobar engine, whatever). You draw a vertical line or a box to represent each module (since it persists over time).
Order these modules in the x direction in approximitely the order they talk to each other. Then you draw lines that show them talking to each other. So, for example
html form ->web server->-> database
(shows the request going from the client deep into the bowels of the server)
and
(html page<-web server<-database)
shows the response (a millisecond later) coming back to the client.
That example is trivial, but when you start to mark the diagrams up with information about what is being asked for and what is being returned (via little notes that are part of the UML standard), designers start to ask pointed questions about what information will be in the response, and why can’t _foo also be added, since if they could display _foo would make the users life a lot easier.
Too soon to say it’s been a roaring success, but it certainly hasn’t been a failure. The key to all these types of communication is using _visual_ renderings of design (something that, fortunately, has been trendy in the software world for some time anyway!).
if I showed designers an xml schema their eyes would glaze over, but when I show them a sequence diagram their eyes light up instead!
If only those designers made a pencil sketches based on the requirements and discussed with the engineers before either of them start the work, the whole issue would’nt come up probably. [And later on the designer sticks to his original ideas to a large extent, with out making big changes to design.]
I’ve been at the recieving end when I’ve suggested design changes later in the dev cycle. Now things are a lot easier with this approach.
Also, the designer SHOULD know the constraints/capabilities of current developement model even before he starts thinking about design.
[In olden days in art, it was called of constraints of the medium.] Looks like everybody has forgotten Pencils & paper.