22nd March 2010
This is the second of several excerpts from The Process Toolbox that I presented at the 5th @Media conference. In this post, I want to discuss collaboration. It’s hard to think of this as a “tool”, as it is more akin to common sense and efficiency, but so much of what we do relies on it.
I wholly believe that our processes should be inclusive, and that all members of a team can influence all aspects of the design and build of a product.
One of my most stringent rules as a creative director is that anyone, anywhere in the team can feel free to add value. They all have brains and common sense. Anyone, at any stage can contribute an idea, pose a question, throw a spanner in the works, piss on our collective chips, or get so excited that they piss on themselves.
I’m certainly no fan of the production line approach. Project manager passes request to developer; developer passes framework to designer; designer colours it in etc. Everyone working within a niche skillset on a need-to-know basis. No.
I favour, as many do, an open platform, where all team members are informed and involved from day one. If we are all aware of the project’s goals and aims, we can all contribute. Findings throughout should be made transparent and shared with the whole team; and I would not exclude any client-side politics, budgets or contractual details from that either.
Forgive the role-pigeonholing here for a second. A developer can challenge a designer about a chunk of CSS or use of type. A designer can challenge a developer. Anyone can do this so long as they have a deep understanding of the process being undertaken, pairing that with the backbone of the project and their own experience.
Whilst some will always remain specialists, an individual’s general skillset or knowledge-base increases dramatically through collaborative design. This also assists individuals to achieve their own goals. For instance, even the quietest designer can find themselves doing a pitch or chasing a potential client if they wish. It promotes a Musketeers all-for-one ethic that puts a collaborative, thriving team at the heart of everything.
I believe that the client team has an incredible amount to contribute. It’s easy to dismiss those new to the web who may be commissioning the project as “clueless technophobes” who can’t fill in an online form in their outdated Internet Explorer 6. It’s easy to assume that they’ll request that the logo be made bigger - and will say that we mustn’t use green because it means “environment”. And so on.
Well, this is unfair. The client team almost certainly know a lot more about their organisation than we do - at least to begin with. The important distinction is where the web team has a clear niche. For example, if you build hundreds of council websites, you probably know more about that than the client. You can educate the client to help them understand their organisation with regard to best web practice. The danger is to dismiss the insight they can give you with regard to the organisation itself. The client can educate us about their sector, area, community or their place within it. Our job is to listen, discuss, and interpret this knowledge for a web audience.
It should be a scenario of “learn from us, and we learn from you”. Thus, we should create as many opportunities as possible to collaborate. It’s not just a case of getting sign-off on the navigation, or agreement on design principles. We should, where possible, bring them deeper in to the process. This has benefits, as we can make the client work bloody hard to deliver what we need to know. In turn, we also build our own knowledge.
Always think what the client can do for the project. For example, can they implement an internal shift with regard to content production? I recall a great experience with a vast Communications Network team, where our main contact asked us to lead a best-practice “writing for the web” workshop, which in turn led to a collaborative process of ensuring 100s of individuals stopped writing content as though everything was a press release.
It can be advisable to bring the audience into the project early on. It isn’t always possible, but when it is, do it in a manageable way. The audience is the most important recipient of what we do, and we are ultimately designing for them, whoever they are.
Can the client provide market research or existing findings about their audience, upon which we can do Secondary Research? I’ve seen everything from classic Quantitive Research such as a few usage stats and Excel sheets of impenetrable data, through to brilliant Qualitative Research such as video interviews or case studies. Can the client facilitate research and information-gathering going forward that lessens our workload? Can they provide access to a testing audience or focus groups? If so then great, but we must also ensure this is representative of the broader audience.
And what can us web professionals do? Can we devise a process that engages with the audience from the beginning? Can we identify individuals or groups that can act as constants in our discovery work? How can we ensure the audience can have their say prior to launch, and what can we build that makes them feel part of the process? Think about how Happy Cog and Mark Boulton embrace the “Design By Community” approach in some projects, where the whole process is laid bare, stage by stage, before the entire user base.
We can never consult every existing or potential user directly. Still, we can take steps to ensure both ourselves and the client team engage with a cross-section of the audience. We can, in some senses, collaborate with them throughout the build. I’ll look at a few examples in the following posts, beginning with some initial audience enlightenment.
*Note:* Slides designed by Gregory Wood.
This article was originally posted on Erskine Labs, September 2009.