Things that Matter and How to Find Them

You may not have heard, but the City of Portland caused a little bit of a kerfuffle recently when they set up a design contest to help refresh the PortlandOnline.com website. The contest is very simple - give us some image elements that will make the site pop. However, this comes in the wake of a withdrawn RFP for a full revamp of the site: architecture, branding, data APIs, all of it. The city was told, mainly informally, that no one would do the work proposed in that RFP for the figures being quoted. The design community, fresh from that RFP, took the contest as a request for spec work and went off the deep end. Given that many designers are independents, it’s understandable that they would be offended. But what was interesting was the reaction from larger firms and, of course, industry associations like the AIGA (whose “position on spec work” is linked above).

I was able to attend the first half of an AIGA-organized roundtable discussion about the contest, the notion of spec work, and next steps with the city. I was expecting a lot of anger, and it was definitely there, but something very interesting also happened. The pitchfork sharpening session turned into a barn raising about thirty minutes in. I was incredibly heartened to see the attention paid to the city’s struggle to articulate what they were after. Anyone who’s been in and around RFPs even a little knows that, at least half the time, the authors of the RFP don’t know what they want. The coin toss sounds decent, but it’s not: the other half of the time, authors of RFPs “know what they want” but they’re asking for a solution to a problem that they don’t have - it’s a symptom, or it’s not the actual root of the difficulty they’re experiencing. So to see this group of professionals start in on the real work of developing a dialogue with the city about needs was huge. Of course, design professionals understand the proper process like the back of their hand, but it was fantastic to see them focus on educating the client, right off the bat.

A similar lesson emerged from our own practice recently. A client wanted our help planning a report and assessment of successes and challenges across a wide range of projects and initiatives. It was, essentially, a full review of the operations of everything they were doing. Their process for the project looked like this:

Gather data –> Draft report –> Promulgate Draft for Comments –> Revise, Re-Comment, Repeat –> Present

In the abstract, there’s nothing wrong with this (I guess). It’s not where we would start, and it’s not how we would want to spend our time (revisions cycles are terrible), but if you did it their way you’d get a report. Our pitch back, however, was this:

Build the Dream Team –> Define the stakes –> Gather data –> Set up some syllogisms based on the data –> Buddy up and talk with project team leaders, impacted communities, and others about the syllogisms and other things –> Return and report to the team –> Revise and amend syllogisms to reflect the human reaction to “what we know” and to build a real “what we know” –> Identify key narrative themes –> Find similar stories in art, literature, and popular culture –> Draft the report –> Elicit feedback –> Final draft –> Present

I might be exaggerating our proposed process a bit, but not by much. The point is that, beyond a mere report, this was going to be life or death for some project, job security or joblessness for some people, and in the broader scheme, meaningful or meaningless work for those that remained. This mattered. So treat it like it matters. The AIGA roundtable emphasized the same point: we’re talking about the city’s website. This is not the place for a patch job (particularly if you’re trying to establish yourself as a mobile and web development hub).

And I’ll bet you another thing: ours would go faster. It would not suffer from Committee Lag Over Goals (CLOG) because it’s a small team of key people, responsible for everything important. It would not present inarticulate drafts, made slightly more inarticulate each time via editor creep, because we “wrote the story” before we wrote the draft. And it would not waver from the knowledge that it was fundamentally right. In the end, our “more complicated” processes are trying to root out simple truths - truths that inspire a quiet ping inside us all, that light the bulb above our heads. Always, always teach your client/stakeholders/team how to think about what matters, and the tactical junk falls into place.