You did not specify you application of the word strategy... but I use
four basic frameworks for design strategies. They are as follows...
a) filling the order.
This is almost a non-strategy, but it really has to be mentioned as
the lower common denominator. The scenario is: the client or product
manager comes to design (designer or design team) with a firm idea of
what they would like to end up with. Design complies by executing
pretty much as described. I tend to be very uncomfortable with this
as it renders design as craft and the designer a tactician.
b) problem - solution
While this may seem pretty basic and fundamental to designers... it
is not obvious to those in product, marketing or even engineering/
tech, where projects often originate. When I am struggling with
projects coming to me or my team in the form of framework a)... I try
and switch the conversation to defining the problem. The trick here
is to not call out what may be faulty assumptions that have lead to
the 'vision' or 'solution' provided to the designer, but to go back
to square one and think very fundamentally. Most bad design, where I
have been privy to the process, is a result of solving the wrong
problem, not poorly solving the problem given.
c) goal/objective/policy/tactics structure.
This can actually be layer on top of the problem solution scenario.
This structure helps to further define complex problems. They usually
tend to be a combination of problems and constraints. The validity of
constraints is always an issue for designers... but that is best left
for another conversation (Chris Conley and others).
d) design solution
No conversation regarding strategy would be complete without
discussing the concepts presented by Boland, Collopy in "Managing as
Designing". The initial chapter calls out the sort of process
designers get sucked into when business drives projects... they call
it 'decision' based, versus one that is 'design' based. As an example
the author relates one of Frank Geary's team's projects. They begin
by satisfying the criteria, constraints and goals... then, setting
that aside they embark on the 'how great can we make it' part of the
process. I have had very good success using this approach when the
standards of the client (or their expectations) are not high enough.
I've used a good. better, best labeling to show three solutions. The
client then has the opportunity to gage the ROI of any additional
resources required for the better or best solutions.
I really don't think it matters if you are designing interactions,
products, places or anything else... understanding these approaches
can help to elevate the work, the conversation and the results. Hope
this is in the neighborhood or your ask, and that is it helpful.
Mark
On Jan 4, 2009, at 1:43 PM, Dan Saffer wrote:
I'm starting a revision of my book Designing for Interaction.
<http://www.designingforinteraction.com>
In the second edition, I'd like to include a chapter on Strategy,
that is: how to decide WHAT should be designed and WHY.
So when I ask, what should interaction designers know about
strategy? You respond...
________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... [email protected]
Unsubscribe ................ http://www.ixda.org/unsubscribe
List Guidelines ............ http://www.ixda.org/guidelines
List Help .................. http://www.ixda.org/help
________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... [email protected]
Unsubscribe ................ http://www.ixda.org/unsubscribe
List Guidelines ............ http://www.ixda.org/guidelines
List Help .................. http://www.ixda.org/help
