Cooper’s latest newsletter is up, with a solid essay from Steve Calde discussing what he’s learned about communicating concepts to clients. It’s a worthwhile read, hilighting the importance of building effective and realistic narratives, building consensus before moving forward, and scheduling appropriately for communicating the design concept.
It would appear that Steve is contributing to a conversation I’ve noticed of late: interaction designers spending time sorting out what’s required to effectively communicate a concept. Kevin Cheng’s writing and presentations on using comics for this element of the design process have been hugely influential on my thinking in the past few months; both Brandon and I have experimented with concept comics recently, with passable results. Steve’s contribution to the conversation is an attempt to lay out a holistic plan for moving from a creative “vision” of the product to an easy-to-grok artifact that spells out “the overall concept, navigation structure, and main elements of the application, product, or service, and the relationships among those elements.”
It’s a lofty goal, and Steve comes close. The question that goes unanswered is one I keep bumping my head against: how do you tie a concept document that describes use cases/flows to an interface abstraction? The essay spends a good portion explaining “framework” documents, which are effectively low-fidelity wireframes, but doesn’t address at all how those would be tied to communications of use cases or the overall narrative. Talking about abstractions as part of concept communication seems to ignore a truism: regardless of fidelity, people respond to interface abstractions, usually with a need for more detail.
I get anxious presenting anything that looks like the interface before we’re approaching a concrete definition of concept. Nailing the concept (with or without comics) takes priority, and the move into design should follow. The nature of the design activity is determined by what’s appropriate to flesh out the concept. It could mean either a) gathering the project team together in one room to whiteboard out the “anchor” functionality of the site, or b) taking a stab at prototyping that functionality. I’d view either of these as an effective start to designing the product, with the agreed-to concept fresh in everybody’s minds.
I believe that muddying the waters of concept definition with abstracted design poses the risk of extending “soft” concepting into “hard” design activities. The value of this intermingling might be a more concrete understanding of the overall product “vision,” but I’ve yet to hear anyone clearly articulate how best to actually accomplish this synergy. The downside is pretty apparent: you could get caught in an iteration cycle before design has even begun.
That’s not a pretty outcome, and the risk seems to outweigh the reward. If you’ve got best practices for concept communication, leave them in the comments below. I’m eager to continue this conversation.
Entries(RSS)