Handbook of Collaborative Design

On some of my latest projects the phrase "collaboration" has been thrown around a lot, as part of being Agile with a capital A. But generally, my initial reaction is that hardly ever does anyone mean it, or mean the same thing each time. For anything that strikes me like this, I'll often pop up and not just say it's dumb, but explain (for as long as anyone will listen) why that is.

And then it occurred to me that although I knew what I meant, I couldn't define "Collaborative Design" off the top of my head in any useful way. Normally I am not just opinionated about design and process, but have a solid reason for my opinion. So I considered this, kept quiet, and in the spirit of collaboration, later I sat down all by myself, and started to ponder what I think collaboration means.

And very rapidly I got almost nowhere. Even reviewing specific lists like Kelly Johnson's rules for Skunk Works project management wasn't that helpful; they are all too focused on their vertical market.

I came up with a few tactics, both derived from these and from my own observation, but I don't like simple step by step processes, at least unless there's an understanding of /why/ that simple process exists. It's not just my opinion; in industrial human factors a lot of accidents occur from mismatches between mental model and actual system behavior. So I need to find the underpinnings to make it work. But weeks pass while I have other things to do and no idea how to solve this problem yet.

Today, I was working on some stuff in the office (a slideshow, some "what do we do" language) and kept inviting people over to help evaluate, confirm and even create the content. Ten minutes later, Eric wandered by to ask where the best place for a help icon would be – an open-plan office is great for this stuff. And it all reminded me suddenly of this, because we were working /together/ on the problem. Even when asked about the help icon, I had to get scads of information from the designers working on the product full time, confirmed some of my other understandings, and then gave him options, and opinions on why each solution was good and bad.

And it occurred to me that this is exactly what I was doing earlier, and last week, and on all of the best collaborative products I have worked on. In fact, thinking about the method alone reminded me of projects I hadn't thought about in years.

A bit more typing and revising leads me to these principles and operational guidelines for collaborative engagement.

• Collaboration best employs the skills and knowledge of each individual. If a gap is identified, find the right person for that slot. This can be ad hoc (like Eric asking me to help solve a problem for a few minutes) or the way the whole project is set up, with a permanent team of these people all working together.
• Each collaborator contributes as they know best. That often means you trust someone's opinion, because that's their skill area. And it also means you keep quiet (or at least don't push too hard) when talking outside of your area. I know a little bit about database design, but try to limit my comments about data architecture, because I am not a DBA. And I hope they don't express an opinion on the color or alignment of everything I draw.
• There must be a product concept to start with. As I say it, you need a Problem Statement, Target Audience, Design Morphology, set Design Objectives and so on. Then stick them on a wall, stick them in the front of the documents, and constantly make sure that you stick with them. This carries through the whole process, so once the concept of design is done, stay with those templates and grids and the basic navigational architecture.
• Everyone is designing solutions. Technical contributors design data stores, software and so on. This is as legitimate a type of design as interactive or graphic design, so make sure everyone's contribution is as valued.
• Be a conscious designer. Every collaborator should offer (or be able to offer) an explanation for their decision, with upsides and downsides to each option. Inexplicable, unilateral proclamations to not engender trust with the team. And trust is the only way to make everyone believe in a decision and keep working collaboratively.
• Have a good team leader. Even for ad hoc collaboration, someone should clearly be the lead designer. For larger, and more permanent teams, a dedicated team lead is best. He should be only that, and maybe do other coordination and planning but never be a designer to avoid bringing his own opinions to the table. His key roles are to facilitate the process (make sure each of these other hints happen, make sure everyone actually works together and work through issues) and to make executive decisions. If a decision cannot be made, but either would work, he has to take responsibility for one, and that should be the end of the discussion.
• Discussions should be limited. Cutting discussions off is good. Sometimes it's that last 1% and any decision will yield a good result. If too far apart, it's often no good to keep going. While disagreement fosters creativity, argument just makes everyone entrenched. When collaboartion stops, it's time to stop the discussion, and take it up later. What these time limits are vary by the project, so I don't have any.
• The number of people having any connection with the project must be restricted in an almost vicious manner. Use a small number of good people.*
• There must be a minimum number of reports required, but important work must be recorded thoroughly.* Remember to record all the discussions about design objectives in the same manner as drawings; they are a design deliverable. Archive all this stuff, but try to let the team do its job, and report to management only when needed. Regular demos and proof of value spreadsheets interrupt the process for the whole team.
• When it gets to drawings, there must be a simple, understandable and universally-employed method of drawing, revising, versioning and distributing the files to everyone on the team. This same system should be used for prototypes, final code, and bugs. Yes, this last never seems to happen, but team members get left behind every time there is a system shift, and that is a bad thing.

I also think it's important, with overused phrases like this one, to define what it is not, and to address the edges and fixes.

• Don't jump in after a design is locked, present a totally different design (or some change that will require a totally different design) and then claim that's collaboration. If there's a legitimate issue, and this change is needed, first you need to get agreement from everyone that the whole design is up for grabs. Remember, this includes making sure the timelines (and dollars) can handle going off and redesigning everything again.
• Generally, revisions are not a good place for collaboration. A second release is, sure, and so are specific aspects of a fairly locked product; I'm not saying it only works for some "pure" clean sheet of paper design. Collaboration works well to devise new solutions to a problem.
  If a design is solidly on paper, and changes start piling from other teams and individuals there will be problems. I don't just mean teamwork problems, and hurt feelings but problems...
• ... One-problem-at-a-time is a solid way to organize tasks, to approach bugfixes and so on. But it's a terrible thing for design (of any sort). Remember, everything has to be holistically approached. And not just because it's the right thing to do, or to make sure everything is pretty. No, once that design starts proceeding, things get tied together in arbitrarily complex ways, and simple changes become hard to keep track of. Components will fail, or throw errors, links will get lost, etc. Now, a good designer will get over these, but not without raising yet more issues, or making other changes... which presumably need to be addressed with the team again. And you rapidly get to a spiral of exponentially-increasing changes.
  Use design objectives, grids and templates as a ruler here. If you find yourself on the third or fourth "we'll just violate that this one time" it's time to stop entirely and re-address things. Can you discard this changed item? Can you identify another component causing all these issues, that can be discarded or redesigned? Maybe the whole product assumption is wrong. This has happened – lately, to me – and usually the results of a total redesign or reset of the design objectives are better than before.
• Don't make emotional decisions. Even if you are trying to design a product that is specifically supposed to appeal to the user on an emotional level (and really, most of them are), don't let gut feelings, anecdote and opinion rule. And as a general rule, don't vote. Someone should be in charge of that practice area, and if there's a disagreement, the team leader makes the call. Other methods invite emotional decision-making, which is rarely correct.

I am aware some people think I am hard to work with, because I am very opinionated and push for it. But I'm not really; what I push for is the design decision I have arrived at based on my knowledge in my practice area. When I run out of that knowledge, I look up more, beg for research or go to get the person who knows.

Some of the best projects I have worked on have resulted from being locked in a room for 16 hours a day, with all the right people brought in so we can work together. That sort of process is where I learned to push for the value of interactive design, and also to get out of my chair and ask the developers, analysts and marketing guys right now when you need to know something or get them to make a decision.

So, don't make a note for later, or promise to make a collaborative team next time. Get up or send that IM this afternoon, trust them to do their job and also to give you the right answer.

* These are pretty much straight rips from other sources. Everything else I wrote.