Archive for the ‘design’ Category

Frozen accidents in workspace

Friday, November 17th, 2006

Frozen accidents are chance happenings that have become ad hoc standards because it would take too much effort to switch to another configuration. The term “frozen accidents” is primarily used in discussions of Darwinian evolution. An example: the heart is generally a little to the left of center in a person’s body. There’s no particular reason that evolution didn’t roll the dice differently early on, leading to hearts being a little to the right of center. But once the original configuration was set, it got locked in.

In the abstract space of the working world, frozen accidents are ubiquitous. Even if, in principle, there are fifteen ways to route the paperwork, there’s only one way for which the boss (or the bureaucrats pushing the paper) say, “but THIS is the way it’s done here.” Because a decision was made sometime in the past, it has become an ad hoc standard. Now, the logic behind some decisions made in the past may still be apropos, but we all know situations in which a) the logic employed at the time of the decision is inappropriate in the present context, or b) there wasn’t logic - it was a choice that could have been made by rolling dice or some other chance method.

Sometimes, institutional memory is insufficient to figure out why a decision was made the way it was. Many decisions made in the past can seem like they were accidental choices.

In any event, the decisions have been frozen. I like to call them “frozen accidents” because the idea behind the term is so powerful.

Here’s what it looks like:

  1. A choice is made between various perceived, available configurations in a very specific context.
  2. Later, the context has changed, but the choice that was made remains active, a “frozen accident.”
  3. At this later time, other configurations can be perceived, but they’re no longer “available.”

The idea of “frozen accidents” is helpful in understanding why good ideas sometimes don’t get off the ground. It is part of the reason organizational change isn’t easier.

Here are some examples of frozen accidents in the abstract “space” of work, in the specific context of the university where I work. Some of these are specific to my workplace, others are more general:

  • Saturday and Sunday are the weekend days. Need these always be the same? The same for everybody? Do weeks have to be seven days long?
  • There are two regular semesters and a summer semester per 12 month period. Other universities have quarters, for example. But it’s rare for a university to switch from one system to the other, although some do.
  • Faculty and students interact through “courses” taught within “disciplines.” There are other models besides “courses” for learning. Most people learn much more outside of courses than they do in them. Internships, problem-based learning, etc…
  • Student transcripts record pretty much only what “letter grade” a student “earned” in each course. We do it because that’s how it’s been done, it’s simple (although oversimplifying what happened in the student’s learning), and it’s an ad hoc standard that employers understand.
  • Courses all begin at the beginning of a semester and end at the end of a semester. Why should all courses/topics have the same duration of treatment? When courses all end at the same time, all the final projects and exams fall at the same time, inefficient at best and a recipe for burnout at worst.

For anyone who perceives the tensions between the way things are and the way they “should” or “could” be, frozen accidents are both interesting and frustrating. They represent the “inertia” of the system, and we know that organizations with too much inertia invariably decline.

Whither the orchestra?

Wednesday, November 8th, 2006

In a previous post, I wrote about a few of the most significant challenges facing me as a music professor and conductor at a small science and engineering university located in a remote area. But I don’t think the issues are specific to my location. Instead, looking at the folding of major orchestras in this country and many other factors such as educational trends and funding models, I believe this is a widespread, multifaceted cultural phenomenon. Now, given these challenges, what can/should be done?

In product design, it’s common to talk about a product’s life cycle. There are plenty of empirical and model-based theories about life cycles, most of which talk about growth, maturity, and decline phases. What would happen if we were to talk about the orchestra as a product, a designed system that has a relatively well-defined functionality? Into which phase of the product life cycle would you put the orchestra?

Going further…. If you were the product manager of this particular product, the orchestra, how would you evaluate the market situation, and what would you suggest?

Virtual Ed

Wednesday, November 1st, 2006

I was poking around Technorati, searching at entries with education and design as tags, and I found this interesting blog describing “Web 2.0″ tools that could be useful to students and faculty at various level institutions. I looked at a few of the collaborative tools…somewhat promising.

But then I found a link to a course being offered this semester by Harvard Law School in conjunction with Harvard University Extension. As far as I can tell, this is a class about argumentation, particularly in relatively new venues such as blogs, wikis, and the like. That’s interesting enough in its own right. But then…much of the class is being taught within SecondLife, even the office hours of one of the faculty members are situated in the virtual world. Could “distance education” be about to experience a paradigm shift?

In search of navigation

Wednesday, October 18th, 2006

Although there are only a handful of posts I’ve put up on thinkfetti so far, I have been trying to implement some navigation ideas I have. After several hours searching (and trying out alternatives), I’ve decided I will have to try again later.

TagClouds are interesting and visually appealing (and can be used for intrasite navigation), but I would like to be able to display them contextually; after clicking on one tag (”design”, for example), I would like the cloud to display its results for all the other tags present besides “design.” In other words, combining the flat orginizational structure of the tag cloud with the power of hierarchical searching. One article I’ve found describes a theory of tag clusters, which may be closer to the mark. And here is another thoughtful take on how tag clouds may evolve. The same author also refers to faceted classification systems, which may well describe the underlying structure I’m looking for.

Hierarchical categories by themselves don’t solve the problem, because with them, a target document is found by digging down through the hierarchy in the one way it is set up. For example, consider “education/design/music/Beethoven_improvisation”. The “Beethoven_improvisation” page could be found by opening “education”, then selecting “design” from the available options, then selecting “music” from the new list of sub-items, and then selecting “Beethoven_improvisation”. But you wouldn’t arrive at the page by selecting “music” then “design” then “education”, because the hierarchy wasn’t set up that way. And if “education”, “design”, and “music” were regular tags, you couldn’t use them to refine a search; clicking on any one of the tags would just open up a list of all posts with at least that one tag attached.

This touches on an important point about searching: a good search tool will help you find something you want, even when you don’t know in advance how it has been categorized or labeled. This is why physically browsing at a bookstore can be so rewarding, when constructing database queries may not be…

Design managers, teaching “soft skills”, and ambiguity

Tuesday, October 17th, 2006

From Mark Oakley’s Managing Product Design, John Wiley & Sons, New York, 1984:

“The role of the design manager is clearly a crucial one in promoting successful results. In many respects the qualities required in order to be effective in this job are substantially different from those traditionally exhibited by managers. The main emphasis must be on the design manager’s ability to deal with change and ambiguity.” (p. 56)

In teaching humanities in a science and engineering university, I have noticed that some engineering faculty find it odd that we humanities faculty members want to limit our class sizes. Teaching “soft skills” such as effective communication and tolerance of ambiguity, or skills that are elusive in both teaching and evaluation, such as critical thinking, requires (in my experience) much more time to be spent in evaluating and responding to student work. In teaching physics courses, I found evaluation of student performance to be more straightforward in most cases. There, I could maximize efficiency in grading and evaluating without sacrificing accuracy and helpfulness of response. Occasionally, I would incorporate error trends in assignment answers into my teaching; this feedback loop could help improve student performance, even in large classes. But where the “right” answer is not so well defined, and the process is being emphasized, there is simply more work to be done in evaluating student effort.

Ethics is not simply a trainable ability to select a “right” answer. Design is not simply choosing what is inevitable, profitable, or aesthetically appealing. Critical thinking is not simply a matter of following an algorithm. And because these activities are non-trivial, evaluating students as they develop their skills in them is time-consuming, and classes taught by a single professor probably cannot be scaled up in size without losing effectiveness.

Ambiguity provides opportunity (and risk), but to tolerate or embrace ambiguity requires time.


Bad Behavior has blocked 50 access attempts in the last 7 days.