Products v. Services
In my first quick report from South by Southwest, I very briefly made some reactionary remarks on this talk. Mostly, my complaints were about the mixed message that some of Fried’s talking points sent, how he somewhat freely alternated between, on the one hand, a design methodology for teams focused on building a product and, on the other hand, a process for teams providing consultative design services to clients. For the former, I had no issue with what he described, but for the latter, I found it an unrealistic proposal.
That distinction between a product team and a services team makes all the difference, in my view. In many instances, process is key to overcoming the obstacles of an intransigent corporate culture when a design studio is faced with helping a large client create a Web product with enterprise-wide ramifications.
All Politics
Take feature specifications, for instance, those exhaustive and admittedly abstract documents that define what will be built for a site. Fried suggests that teams might forgo those altogether, dismissing them as “political.” He’s absolutely right to label them so, but that doesn’t necessarily render them inherently obstructionist. For any designer working in an enterprise environment, politics is a huge portion of the challenge for which clients engage us. The ability to navigate between multiple operating constituencies, and to achieve buy-in across groups often accustomed to working at odds with one another, is a crucial part of seeing a successful design realized. Given two equally capable design studios, I can guarantee that the one that has the greater capacity to balance a client’s internal politics will win the day in any design effort.
To be fair, I would doubt that Fried would advocate this approach for every instance — in a very brief discussion with him about the issue, he said clearly that different approaches apply for different circumstances. As another tool in the belt of Web developers, it’s a viable alternative to the comparatively monolithic approach of user-centered design. The line between gospel and dogma is as thin and impermanent as chalk, and it’s reasonable to say that the trappings of user-centered design methodology — extensive research, personae, user scenarios, branding exercises, mood boards, etc. — have attained some dogmatic qualities over the course of the past several years.
Designers Start Designing
In fact, I must admit that I was being a curmudgeon when I was listening to Fried’s talk, stubbornly resisting my first, jarring exposure to a new methodology. I do that from time to time, especially when I have as much invested in a way of doing things as I have in user-centered design. It helped me open up a bit when the ideas that Fried discussed were echoed by several other speakers I heard at the conference — it was, you could say, definitely one of the show’s stronger memes.
What really converted me, though, was the realization that there was at least one thing about this approach that I like a lot. That is, this is a method that returns designers to that core notion of visceral creativity. For many of us — for me — what got me really excited about working in this medium was that I could have an idea and execute it immediately, that I could translate my ideas into code and experience it in very little time, without first clearing a series of procedural obstacles. As designers, what we should really be busying ourselves with at the earliest possible juncture is designing. The shorter the time span between conceiving the initial idea for a solution and the execution of that solution, the less risk of smothering creativity.
Of course, there’s a caveat to this: to get to a position where a designer can begin almost immediate work on the final design — and to be successful at it — it helps to have deep experience doing things the long way. It takes someone who has been through the process of political deliverables, who has watched the pain of user testing, and who has accumulated a history of design successes and failures to be able to make instinctive decisions in short order — someone like Fried, not coincidentally. In a sense, iterative design is strongly predicated on user-centered design. You need to walk before you can run.
+