physical design

continuing with my previous post...

A number of years ago, Saul Carliner developed a three-part design model for technical communication that identifies physical, cognitive, affective activities performed while creating an information product. I've found the model useful when working with pre-professional engineers because it allows us (in the context of the technical writing class) to locate engineering design and development activities within a range of practices and activities defined as technical communication or information design. Most useful in these efforts is exposing the students to the physical design activities of the model.

Physical design occurs in the space between design and development; the preparation and creation of physical elements of an information product. In the context of an engineering project, physical design includes the core writing and editing activities performed by the engineer. The information that shapes physical design activities derives from the design documents created as a result of cognitive design activities. This type of product development (development based on pre-defined design criteria) allows the engineer to develop a product that meets specific needs and purposes.

The value of this model is that it allows the engineers to locate "meaning" within the design documents they create. To interpret the meaning between and among the structures of these documents, the engineers must understand these relationships in such a way as to present them for specific purposes (for example, the technical requirements of a product). In this regard, the engineers perform physical design activities to create the external forms through which users of their documents extract and construct meaning.

deconstructing ia

continuing with my earlier post...

Similar to Information Architecture (IA), Information Design (ID) carries multiple definitions and applications. In web contexts, ID ranges from developing maps and signage to simple web pages. As a practice, ID has been described as an interdisciplinary approach that combines skills in graphic design, writing and editing, illustration, and human factors. On a more ephemeral level, ID has been described as a position or stance one takes. Beth Mazur has likened this stance to a political or moral stance that we take the design or an information product to improve the quality of the communication. More specific to what I want pre-professional engineers to understand about IA; ID has been described as the act of designing and deploying content in such as a way to achieve the performance objectives for specific end users – objectives captured during IA analysis.

For the purpose of instruction in WRT 407, it has been useful to define ID as one aspect of design that occurs within the performance of IA analysis. Design activities performed within analysis are the point at which the engineer can focus on the context and purpose of the information products they are created during their engineering activities. If the product of IA is the blueprint or specification that guides development and deployment, ID is the act of shaping the specification. ID uses the results of IA analysis to inform the engineer's overall product design.

Within this framework of analysis and design activities, IA can be seen as any number of processes the engineer follows to understand available forms and structures; to design the physical aspects of the information product, and to develop the product to meet end-user requirements. The forms and structures available to the engineer are shaped and served by any number and type of discourses, styles, genres, and dialects. These are the standard designs – the genres and conventions that engineers are aware of and work with. Designing the physical aspects of the information product occurs when the engineer transforms one (or more) of the available standard designs into a new product that meets specific pre-defined requirements.

defining ia --- again

continuing with my previous post...

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?

ia is about structure

continuing with my previous post...

We've come to understand Information Architecture (IA) as the practice of structuring information (often according to context) for a particular purpose. Tom Johnson and Donna Marsh circled around this definition last week. From their discussion, it seems that defining IA is problematic because it is most commonly applied to web development. However, from Donna and Tom's experiences (and those of others) it's quite obvious that IA also applies to disciplines such as TC, software programming, and user experience design (Peter Morville has said as much about a decade ago).

To complicate things a bit more, an alternate popular definition of IA exists within the field of information system design, where IA refers to the analysis and design of blocks or chunks of information (and their inter-dependencies) within a system. Beth Mazur has used this definition in her efforts to draw distinctions between IA and information design.

The practitioner perspectives that Tom and Donna provide and the academic definitions that Morrville and Mazur provide are built on features of information interaction, content analysis, classification, information hierarchies, information navigation, and information structuring for particular purposes. It seems to me that if I can invoke TC practices that include these features, I can illustrate to my students a range of practices that will help them understand the complexity of their design activities. For this purpose, I need to begin by locating design activities, as an aspect of IA, within TC practices and embedded engineering writing instruction.

tech comm, design, and information architecture

In the next series of posts, I want to try to revisit the relationship of design to technical communication practices. I explored the topic in a graduate seminar last year, but I'm bumping up against it again as WRT 407 comes to a close and the engineers begin to see the product of their design, development, and writing activities.

I want to begin with the question that I was asked during that seminar: "Why is it important for technical communicators (or anyone performing the role of technical commicator, such as an engineer) to understand that they are doing design?” The question is an important one because it demands that we reconsider traditional treatments of the disciplines and fields that serve (and are served by) Technical Communication (TC).

For a long time, I have viewed TC as a co-opted discipline; taking pieces and parts from any number of closely and remotely related fields, practices, and disciplines. My perspective placed TC in the middle of the design/development universe. Yet when asked to qualify the importance of viewing the technical communicator’s activity as something other than “technical communication,” my heliocentric perspective broke down.

Such a break down is possible because all perspectives of TC across the scholarship and literature are based on uneasy and inconsistent definitions of the discipline and the practice. These definitions always include (arguably, must include) descriptions of design, development, and production activities that are performed by technical communicators. This move to include any and all activities associated with creating an information product is what complicates an answer to a simple question about disciplinary perspective. Blame it on the reflexive nature of Composition as the mother discipline. Blame it on technology-mediated practices. Whatever the cause, technical communicators are unable to foreground their discipline within a clearly demarcated practice of design/development activities. TC is not at the center of the design/development universe; it has gradually become the generic glue that connects hundreds of fields, practices, and disciplines.

This is the position from which I will further consider the relationship of Information Architecture to TC over the next few posts.