(To be said in the same tone as the classic Wendy’s television ad tagline, “Where’s the beef?”)
It is inevitable for UI designers to be confronted with the question, “where’s the spec?”, usually posed by the product manager (PM) or engineer/QA leads. I’ve faced this at every in-house software design scenario to date, including Oracle, BEA, and Adobe. But this posting is not a gripe about specs per se. Specs are vital documents that provide detailed textual & visual instructions to enable the accurate implementation of a design solution (and for QA test cases). Specs are critical recipes for engineers to know exactly what to build and how it should behave in accordance with the proposed design solution. Specs make explicit the solution that often lives in the mind of the designer (or plethora of emails and sketches on file servers).
But what irks me is that inevitable question and what it signifies, when you think about it deeply–that engineers are seemingly and perpetually in a state of code production, cranking out the latest build, finalizing for ship (or “golden master”). Hence, their desperate need for the “UI spec” that outlines every iota of detail to the Nth degree of tedium and exhaustiveness…So that the engineers can build it, ship it, and start on the next release. Sigh!
[This is totally resultant of the problem Alan Cooper smartly explains in About Face, whereby design and engineering are happening simultaneously or worse, design is behind coding. Ideally, design should and must operate ahead of coding…way the hell ahead!]
This question (and that constant need for a “UI spec”) implies that the product development process is fundamentally flawed: its focus on the recipe document as opposed to the optimal design solution to be specified in the first place. As a presidential candidate remarked earlier this year, “I’m in the solutions business”; likewise, so am I. My focus (and the job responsibility for which I’m paid lots of money) is to create and deliver the optimal design solution for a targeted user audience. This task requires multi-disciplinary cooperation, rounds of creative exploration and technical investigation, iterative prototypes (or mock-ups), user feedback, and then an unambiguous review and sign-off process with key stakeholders.
There needs to be a fundamental shift in product development players’ mindset away from constantly demanding (and expecting) a complete spec (which in itself suggests a “throw it over the wall” mentality, just give me what you got, whatever it is and we’ll build it) towards shaping a collaborative blueprint. A blueprint implies a conversational document that will be amended as constraints are addressed or technical novelties discovered (or user feedback validated). It’s an evolving document. It implies shared commitment and purpose, taking in inputs from engineering and marketing but owned and defined by the designer. Qualities that I think are far more valuable than the best written (but potentially incorrect) UI spec thrown over the wall to the eager yet uninformed engineering team, desperate to keep to their coding schedule.