school update: four weeks into the second semester
The first four weeks of this semester have been a blur of work, travel, red-eye flights, multi-minute fits of coughing in the middle of the night, two bottles of Dayquil(tm), three bottles of cough syrup, morning studio classes followed by afternoons and evenings working. If there were an drug that made people feel the way I have lately, there would be no reason to make it illegal.
We hit the ground running in my studios with projects on showing the evolution of form using only images and relating information about a sightseeing trip using a limited selection of typefaces for the names of the places, lines, and two colors. Cardboard shoes this is not, this is getting into what makes design go. These aren’t “Easy A Art Classes” as a friend of mine calls them, these are “work your ass off and still get it wrong” classes.
You can argue that there is no “right” and “wrong” in the creative space, but in design, there are clearly “rights” and “wrongs”. You’ve used well-designed objects and never noticed they exist and been frustrated with poorly designed objects that you’ve wanted to destroy with a hammer.
So how do you tell “right” from “wrong”? One way Carnegie Mellon’s Design program really does its students a favor is by forcing us to depend on each other for continual feedback during the design process. If I think I’m drawing blue squares and you tell me they look a little too purple and round to be squares, that isn’t saying that blue squares are wrong but that I’m doing a poor job of communicating “blue” and “square”. We go so far as to work on each other’s drawings with tracing paper and explain how to fix each other’s projects.
In my comp sci classes, this level of helping one another would probably have been referred to as “cheating” and we’d have been disciplined. In a design studio, if you walk by someone’s table and see that their perspective is off or that their blue cube looks a bit too green and triangular, you tell them then instead of waiting until they hang the work during a crit or turn it in for grading. Helping each other during the process and being honest with feedback and criticism really improves everyone’s work and their final results. That’s an important lesson — even an Important Life Lesson — that I’d never been exposed to in a classroom.
In the corporate world, even in the semi-egalitarian world of software engineering, this does not happen nearly enough. I’ve close enough working relationships with many of my peers that we can say, “that’s not going to work” or ask for help without worrying about looking ignorant or even incompetent. If I’m in a meeting with someone from product marketing, I can’t say anything remotely like that, even if I put it as politely as possible. Why? Because it’s seen as questioning their competence, and that’s not something one is supposed to do in the workplace. If, as engineers, we can question each other’s work, at what point is not unreasonable for us to question the work of others in our organization?
I’m not suggesting we say, “you suck and your ideas suck” to random people from other departments, but I am suggesting that we start questioning the facts presented by people in other organizations and challenging them to demonstrate the chain of logic that led them to their conclusions. If “%50 of customers think this is an important feature to add”, what do the other %50 think? Are they opposed to the feature? Do they want a different feature? Will it make them like the product any more or any less? How did you determine that %50 of the customers want the feature and whether or not they will want it if it slows down the product? (You did mention to them that this would slow down the product, didn’t you?)
If you’re going to show me a bar graph, be prepared to show me the process that went into generating that bar graph. If I’m going to tell you the new feature you want is going to take N weeks to implement, I need to be able to tell you how I came up with “N”, or at least be willing to honestly admit I picked it at random or padded it with enough time to figure out exactly what it is you’re really asking me to do.
I often get asked exactly what I’m learning, and I often have trouble describing it in simple words. For now, I think I would say that it is the development of “process” as an explicit skill that can be documented and discussed as a component of product development alongside explicit skills like “project management” or “software engineering”.
(And yes, this entry might well have the single most misleading title in this entire journal. )