Design Principle: 3-Tiered Cost of Trying
Tier 1 - The Team Activity Level
Herbert Simon discusses a principle whereby one must weigh the value of learning something about a design against the cost of learning it. This generally is applied at the level of analysis techniques, or rigorous design methods. For example, you might run a user test whereby 15 groups of 10 people are each given a different possible design. Based on their feedback about the designs, you can learn about which qualities of those designs are more or less desirable.
But this is a very costly exercise, in terms of time and money. You must create 15 disctinct, functional prototypes, organize 150 subjects and to test them, not to mention employ those who will help administer the testing sessions. You must analyze the feedback recieved and derive useful insights. You must pay everyone involved, or otherwise incentivise people to participate in your study.
Information gathering is good, but is such an activity the best course of action? Would it have been easier to do a computer simulation, create less different prototypes, research existing studies on similar problems, or simply do without the information you gathered? In many cases, other options present themselves, and the costs must be weighed.
Tier 2 - The Individual Task Level
This sort of equation is usually performed implicitly by the designer, and is a fundamental force that shapes the way that we perform our design process. We are always going through implicit cost-benefit analyses, and choosing the route that seems to provide the most benefit for the least cost. We do this without even thinking about it. We know that early in the building design process, it is “cheap” and extremely useful to draw sketches, and to get a feel for the sorts of structures and layouts seem most promising. We do this without even thinking about it.
This provides us with a way to shape the way a community of designers performs: change the costs or benefits of different design activities. Oftentimes, in software, we try to prescribe certain process models or workflow models, and tell people explicitly “do X, then do Y after you have completed Z”. But people’s internal cost-benefit analyses weigh heavy on their choices. If we are able, as a community, to provide software designers with activities that are perceived as low cost and highly informative, we are able to influence approaches.
Currently, there exists little in the way of low-cost ways to gain early, divergent ideas about a software project. We can sketch interfaces, but the feedback gained is not always all that useful, and provides little insight into class-level design decisions. We can prototype out several possible solutions to see which is best, but this is extremely costly, and likely to be refused.
What I’m driving at is: I think we need more divergence in software design, but if this is to be achieved, it won’t be through activities or process models, it will be through tools that give good, cheap feedback.
Tier 3 - The Per-Click Level
In a way, these first 2 “tiers” are obvious. Simon presented the idea of analysis-tier cost-benefit thoughts, and it seems obvious that everyday design activities are goverened by this kind of thinking, if at least implicitly. But what intrigued me about this idea is the way that, taken to the extreme, it ties into another idea that has long been travelling around my research group.
A couple years ago, my group started really focusing on design environments, and 2 ideas that came out as desirable were super-undo (much like Photoshop’s concept of History) and layers (much like Photoshop’s concept of, well, layers). I don’t necessarily know the underlying desires that pushed us towards these features. On one hand, we figured, creating UML diagrams is essentially a drawing exercise, and photoshop is an image manipulation tool, so what’s good for the goose is good for the gander. But I think there was more to it than that, we sensed that these features could provide something for software that had previously been missing.
Insight into what these features provide can be found by considering the cost-benefits of design at the single-action level, which I have spontaneously called “tier 3″. When you are designing, and you have a partial design in front of you, you have several options. You can continue to flesh out this design, of you can explore several options and choose one, or you can undo some of your work and try a new direction for the design altogether.
Its really not so different from the thought process you undergo when you decide whether to perform a user test or charge forward with a promising, if untested design. The decision-making on this micro-level revolve around your notions of cost-benefit. There is not mathematical analysis that you perform for this, you don’t weigh the numerical value of exploring versus completing. But in the back of your mind, you feel a certain way about your options.
To illustrate this, consider the process you use when you’re writing in a fully featured text editor like Microsoft Word. If you want to try to rephrase something, you can try just making the change, confident that the program’s many undo’s will restore your old version if you don’t like the way your changes worked out. Or you might move your cursor above an old paragraph to try rewriting it, allowing you to glance down at what you had before opportunistically, guiding you towards a new version that is different, but draws inspiration from the old one.
Compare this to using an old word processor, maybe an old version of wordperfect, running in DOS. Here, you might only have 1 undo level, if any at all. At best you can move the cursor with the number pad, but you might not even have a cursor, being forced to backspace back through, deleting everything after the point you want to change. Copy and paste features aren’t what they’re going to be.
In the latter case, the cost of making changes, of adjusting course, of exploring your design space, is very high. You are implicitly discouraged from trying a given design path. So you dutifully chug down to a single, likely imperfect document. Similarly, if you do want to try something new, the benefit is often reduced. Suppose you want to try a new version of a previous paragraph. You may not be able to easily move your cursor up to write alongside the old paragraph, forcing you to take your hands off the home keys and scroll up every time you want to check your old paragraph against the new one. Your benefit for the “try a new paragraph” activity is limited (because of its cost, its all interlinked).
In the end, with the poorer word processor, you are less inclined to follow a good, exploratory, divergent design process. Its a hassle, so you become a bad designer because of the tool you use.
All the Tiers Together
And of course, these tiers ripple up. If its hard to compare paragraphs, the cost-beneift of this activity is low, and you won’t bother writing a second one. If your writting process doesn’t involve paragraph comparison, the docments you write are less likely to be effective, and so perhaps document writting becomes an activity that is less desirable, in a cost-benefit sense, in a larger design process. If it is extremely hard to write good documents, you might be less inclined to jot down your design thoughts in a document, and might be more inclined to make handwritten notes or drawings. This continues to ripple up. Maybe if you have an analysis activity that you’re considering, that involves creating writeups of the attributes of several possible designs. If the cost of electronic document creation is high, the cost-benefit of an analysis activity might be unfavorable, and you might not bother. In theory, the word processor you use can determine whether you explore several architectural designs for a building.
And so we get back to software. The fact that our UML-document-creators don’t have good undo options means that we are less inclined to explore different options. The fact that they don’t have layers means that it is hard to gain the benefit of comparison if we do create multiple designs. These facts together mean that exploratory UML document creation is not all that great from a cost-benefit standpoint, which means that creating UML documents isn’t such a great deal, which cheapens the value of up-front diagramatic design in the first place. Taken to its extreme, a poor UML tool prevents us from following a good design process at all.
This may seem like exagurated reasoning, but I think there is some truth to it. People won’t do things they don’t see as worthwhile. If we want software engineers to design we need to engage their sense of value on the per-click level. We need to provide them with tools that give them real, useful feedback, at a low cost in terms of time and mental effort. We can prescribe processes from on high all we want, but if we are fighting against a designer’s day-to-day, minute-to-minute, thought-to-thought instincts about what to do next in the tools they use, we’re doomed to failure.
