When I use the term information architecture with writing students, it sounds impressive and maybe a little overwhelming. But then I get to the place where I have to define IA. That's when things get problematic.
I'm finding it best to situate IA as a verb. I ask the engineers to think about IA as the act they would perform to express the explicit details and concepts of the systems they are designing. One important aspect of that performance is creating an organization and structure for the information relating to and used by their system -- in particular, it is the act of architecting relationships among system components and elements.
After we have the activity of IA on the table, I move to the product of IA -- to the outcome of the performance. When defined as a noun, IA is the blueprint that contains the description of how information is organized and structured within the system. That blueprint is the physical specification (technical and functional) that identifies a set of possible structures, patterns, and techniques to make information easier to access, understand, and used within the system.
Defining IA as both activity and product allows me to do two things in regard to situating IA within TC practices. First, the definition allows the engineers to see themselves as information architects who perform the activities required to create products that meet the needs of specific users. Second, the definition situates aspects of IA as a series of sub-activities performed at iterative points in and around the analysis and development phases of the engineers' design methodologies. Situating IA this way allows me expose for the engineers the relationship between analysis and design. The product of the design illustrates the engineer's ability to effectively address requirements identified during analysis.
How's that for a closed loop?
No comments:
Post a Comment