Tracee - I think I know what you mean by "keeping them (frameworks) from
being a methodology," but the organizational and scholarly uses of those
terms may differ. Is this a problem because IBMers tend to just "do the
method" if you specify an practice framework as a design process?
You might also want to distinguish between methodology (a preferred set of
methods and perspectives under a coherent epistemology) and methods per se
(research and design procedures in your toolkit). In the everyday setting of
organizational sensemaking, these distinctions are likely to be lost as well
as that of "framework." 

It also doesn't help the designer in a large firm to be defending and
clarifying  their abstractions whenever teams want to collaborate on
interactive or information products (if you're at IBM). 

I would reframe the issue in your organization to consider what you're
"designing for," first. As in designing for (ultimately) organizational
change, disruptive innovation, efficient business processes, profitable
products. Each of these will use the framework differently, making it harder
for others (not engaged in the design conversation everyday) to apprehend
the semantics of the framework. Frameworks are best when used behind the
scenes, and methodologies can be selected and adapted for the design domain
you're engaged in. 

You may consider what you're doing as a structuration process for
establishing collections of activity rules and values such as frameworks.
Structuration implies you are creating new practices over time, that will be
adopted, adapted, and reflected upon over time on more than one project.
This can be seen as a socialization process, an inductive organizational
learning approach. Small collaborative teams develop a working set of
adaptive practices that become shared with other projects, laterally, with
organizational support. The working style of the design activity has a lot
to do with managing the translation from your framework to design methods
used in real projects. 

Peter 

Peter H. Jones, Ph.D. 
Ontario College of Art and Design
Visiting Scholar, University of Toronto
Founder, Redesign Research
http://designdialogues.com   



Hi Chuck, 

Yes yes! Thank you for the additional clarifying words ... 'not a 
methodology but a collective framework supportive of contributions to a 
designed outcome...'. Tiiu and Erik offered similar resonance with that. 
In IBM (yes, I'm in IBM) we're embarking on a design practice that will 
hopefully accomplish this supportive, socially-oriented design framework. 
A folly that I worry about is that the framework will be treated as a 
methodology. I think this would be quite easy to do. I'm wondering if 
anyone has lessons learned or insights that can keep this design rigor 
from falling into a methodology kind of practice. 

At IBM (a small team of us in a huge huge company), we're looking breaking 
out some design activities that the various designers can 'rally' their 
creative juices around. Things like creating 'blueprints'. I've heard them 
called things like 'wireframes' and 'UI anatomy' in other contexts. This 
doesn't say what you should end up with but is supposed to be a framework 
and practice where the set of designers derive a 'structure' to work with 
(what elements will be included in that design? how are they rationally 
arranged? what kind of grouping principles will we decide to support in 
the arrangement? what kind of principle will we use to guide this thing to 
the next step?). 


thanks!
Tracee