Blog All Dogeared Pages: Richard Ford’s The Sportswriter

Quotes from The Sportswriter by Richard Ford. Highly recommended (as are the sequels).

For your life to be worth anything you must sooner or later face the possibility of terrible, searing regret. Though you must also manage to avoid it or your life will be ruined. (p. 4)

Sometimes we do not really become adults until we suffer a good whacking loss, and our lives in a sense catch up with is and wash over us in a wave and everything goes. (p. 9)

There are no transcendent themes in life. In all cases things are here and they’re over, and that has to be enough. (p. 16)

All we really want is to get to the point where the past can explain nothing about us and we can get on with life. (p. 24)

Things just come into your mind on their own and aren’t your fault. So I learn this all those years ago–that you don’t need to be held responsible for what you think, and that by and large you don’t have any business knowing what other people think. (p. 77)

Better to think that you’re like your fellow man than to think…that no man could be you or take your place, which is crazy and leads straight to melancholy for a life that never existed, and to ridicule. Anyone could be anyone else in most ways. (p. 81)

We should all know what’s at the end of our ropes and how it feels to be there. (p. 85)

What’s friendship’s realest measure? I’ll tell you. The amount of precious time you’ll squander on someone else’s calamities and fuck-ups. (p. 97)

A life can simply change the way a day changes–sunny to rain, like the song says. But it can also change again. (p. 107)

Married life requires shared mystery even when all the facts are known. (p. 131)

If you lose all hope, you can always find it again. (p. 131)

Some things just can’t be explained. They just are. And after a while, they disappear, usually forever, or become interesting in another way. (p. 223)

You can’t be too conventional. That’s what’ll save you. (p. 335)

At one time or another–like it or not–we all become invisible, loosed from body and duty, left to drift on the night breeze, to do as we will, to cast about for what we would like to be when we next occur…Just to slide away like a whisper down the wind is no small freedom, and if we’re lucky to win such a setting free, even if it’s bad events that cause it, we should use it, for it is the only naturally occurring consolation that comes to us, sole and sovereign, without props or the forbearance of others–among whom I mean to include God himself, who does not let us stay invisible long, since that is a state he reserves for himself. God does not help those who are invisible too. (p. 339)

The only truth that can never be a lie, let me tell you, is life itself–the thing that happens. (p. 374)

Grief, real grief, is relatively short, though mourning can be long. (p. 374)

Winter Break 2007 Reading List

Adaptive Path shuts down for the last two weeks of the year, and I’m taking a few days off at the end of that, so I have three weeks of reading (and of course writing) ahead of me. I have a stack of books I’ve been neglecting for a long time as I suffer through this strange period of not reading very much. Thus, I’m hoping to tackle the following over break:

Half the fun of posting (and reading other people’s) book lists is discovering the books you should be reading. So. What else should I be reading?

Review: The Reflective Practitioner (Part IV)

This is the final part of my review of Donald Schön’s The Reflective Practioner. See parts I, II, and III for the earlier sections.

What does it mean to be a reflective practitioner? Schön says

[E]ach individual develops his own way of framing his role. Whether he chooses his role frame from the profession’s repertoire, or fashions it for himself, his professional knowledge takes on the characteristics of a system. The problem he sets, the strategies he employs, the facts he treats as relevant, and his interpersonal theories of action are bound up with his way of framing his role.

This is why, I think, we see so many clashes on the various design mailing lists about what to call ourselves, what our roles should be, and where the boundaries are for disciplines like experience design and interaction design. It is different frames colliding. One practitioner thinks interaction design is interface design, another thinks interface design is a subset of interaction design, and on and on. Schön suggests that rather than fight about which of these frames is the correct one, we simply practice “frame analysis.”

When a practitioner becomes aware of his frames, he also becomes aware of the possibility for alternate ways of framing the reality of his practice. He takes note of the values and norms to which he has given priority, and those he has given less importance, or left out of the frame altogether…Frame analysis may help practitioners to become aware of their tacit frames and thereby lead them to experience the dilemmas inherent in professional pluralism. Once practitioners notice they actively construct the reality of their practice and become aware of the variety of frames available to them, they begin to see the need to reflect-in-action on their previous tacit frames.

Schön is basically saying, Put down your arms. In all professional practices, there are different schools of thought which often result in very different personal frames for practice. If we instead look at them as frames, we can consider and even move between them as necessary. For some projects, it may make sense to step outside of the frame of “interaction designer” and instead take on the frame of “interface designer” and visa versa.

Some other tidbits from the book I found fascinating:

Experienced practitioners, Schön claims, because of their mastery of the “media” surrounding their practice, “cannot convey the art of his practice to a novice merely by describing his procedures, rules, and theories, nor can he enable a novice to think like a seasoned practitioner merely by describing or even demonstrating his ways of thinking.” He goes on to say, “People who do things well often give what appear to be good descriptions of their procedures which others cannot follow.” Heh. The implications for the conference circuit here is enormous. But I have found this is very true. It is very hard to convey the nuance of design and designing and being a designer in a presentation.

Schön also notes the importance of clients in the life of a practitioner. Practitioners agree to use their “special powers” for the good of the client, and clients in turn “agree to show deference to the professional.” Without this social contract, the role of practitioner breaks down. But the practitioner has to deliver on this promise as well, of course. This is especially true with reflective practitioners because their methods and techniques change in response to the situation and through conversations with the client.

Although the reflective practitioner should be credentialled and technically competent, his claim to authority is substantially based on his ability to manifest his special knowledge in his interactions with clients. He does not ask the client to have blind faith in a “black box,” but to remain open to the practitioner’s competence as it emerges…the client does not agree to accept the practitioner’s authority but to suspend disbelief in it. He agrees to join the practitioner in inquiring into the situation for which the client seeks help; to try to understand what he is experiencing and make that understanding accessible to the practitioner; to confront the practitioner when he does not understand or agree; to test the practitioner’s competence by observing his effectiveness and to make public his questions over what should be counted as effectiveness; to pay for services rendered and to appreciate competence demonstrated.

If it’s not clear from this lengthy review, I highly recommend this book. Although it was written 25 years ago, its relevance for professional practice, and especially the design practice, is still high. Framing problems and our personal frames around professional practice is a great way to think about how to approach projects and our work lives. May we all be reflective practitioners.

Review: The Reflective Practitioner (Part III)

See Part I of this review for the introduction and background.

Framing a problem means making a hypothesis of the situation. But you need to test the frame somehow, and that is where experiments come in.

Reflective practitioners perform on-the-spot experiments to see if they have framed the problem in the correct way, meaning that the problem can be tackled in a manner that is agreeable to the practitioner and that keeps the “inquiry” moving ahead. The practitioner takes into account the unique features of the problem in crafting the experiment, drawing on “a repertoire of examples, images, understandings, and actions.”

Unlike scientists, practitioners undertake these experiments not just to understand the situation, but to change it into something better. Experiments consist of “moves” like in chess. Any hypothesis has to “lend itself to embodiment in a move.” A practitioner makes a move and sees how the situation “responds” to that move, each move acting as a sort of “exploratory probe” of the situation.

Here is Schön on how the experiments work:

The practitioner’s hypothesis testing consists of moves that change the phenomena to make the hypothesis fit…The practitioner makes his hypothesis come true. He acts as though his hypothesis were in the imperative mood. He says, in effect, “Let it be the case that X…” and shapes the situation so that X becomes true.

Schön calls the experiments “a game with the situation.” Practitioners try to make situation conform to the hypotheses, but have to remain open to the possibility that they won’t. Schön notes

The practice situation is neither clay to be molded at will nor and independent, self-sufficient object of study from which the inquirer keeps his distance.

The inquirer’s relation to the situation is transactional. He shapes the situation, but in conversation with it, so that his own models and appreciations are also shaped by the situation. The phenomena that he seeks to understand are partially of his own making; he is in the situation that he seeks to understand.

If a move doesn’t work, practitioners should “surface the theory implicit in the move, [critize] it, [restructure] it, and [test] the new theory by inventing a move consistent with it.” When practitioners find the changes to the situation created by their moves to be satisfactory, that is when they should stop experimenting, and/or move on to the next part of the situation.

By creating these in-the-stuation experiments, Schön notes, rightly, that “practice is a kind of research.”

In the final installment, Part IV, I will review Schön’s implications for practice in the world and see how it relates specifically to design now.

Review: The Reflective Practitioner (Part I)

I’ve been circling around Donald Schön’s The Reflective Practitioner: How Professionals Think in Action for years now and finally got around to reading it. As it turns out, I should have read it a long time ago, since it has so much to say (indirectly) about design and what it means to be a designer today, especially designers in the experience design realm. As it turns out, there is a reason for the fact we’re constantly fighting about things like role/discipline boundaries and titles. The book also offers and analyzes a way of working that is very very much how I work and, I suspect, how many people in my field do as well.

The Reflective Practitioner was written in the early 1980s and took as its premise that the world of work was changing rapidly, that there was a group of people (Richard Florida’s Creative Class mostly) who, unlike doctors, engineers, and scientists, didn’t rely on technical knowledge for their expertise. Schön calls these people “practitioners” and their ranks include everything from social workers to city planners to architects and designers. People who, in the words of Charles Reich, “can be counted on to do their job, but not necessarily to define it.”

Practitioners, Schön says, have “an awareness of complexity that resists the skills and techniques of traditional expertise” and are “frequently embroiled in conflicts of values, goals, purposes, and interests.” (Much like ever project I’ve ever worked on!) Being a practitioner means that the traditional methods and techniques of analytical thinking and scientific process simply don’t work. Problems in the messy world of practitioners “are interconnected, environments are turbulent, and the future is indeterminate.” What is called for under these conditions, Schön argues, are professionals who can, as Russell Ackoff says, “design a desirable future and invent ways of bringing it about.”

All isn’t roses for practitioners, however. We’re struggling against 400 years of Technical Rationality, which is “problem-solving made rigorous by the application of scientific theory and technique.” Technical Rationality is ingrained in our workplaces and in our universities, and the professions that practice it (doctors, lawyers, engineers) are emphasized and revered over those that don’t. Professions that practice Technical Rationality apply general principles (medicine, law, physics) to specific problems to achieve unambiguous results (health, justice, bridges, etc.).

However, Schön points out, “Increasingly we have become aware of the importance to professional practice of phenomena–complexity, uncertainty, instability, uniqueness, and value conflict–which do not fit the model of Technical Rationality.” Instead of simply problem solving, practitioners instead need to problem set. That is, “to determine the decision to be made, the ends to be achieved, the means which may be chosen.”

Schön says,

In real-world practice, problems do not present themselves to practitioners as givens. They must be constructed from the materials of problematic situations that are puzzling, troubling, and uncertain. In order to convert a problematic situation to a problem, a practitioner must do a certain kind of work. He must make sense of an uncertain situation that initially makes no sense.

Problem setting is where we “name the things to which we will attend and frame the context to which we will attend to them.” This cannot be achieved by Technical Rationality, because Technical Rationality depends on understanding what the end is. Only through naming and framing, which do not depend on applying general scientific principles, can these complex problems eventually be solved.

This, however, doesn’t stop practitioners from looking for tried-and-true methods and techniques that will solve all their problems in a neat way. You see this all the time with designers at conferences and on mailing lists, searching for the next great method. Schön says that for practitioners, replying on methods and techniques will leave them solving problems of relatively little importance, for both clients and society at large. It is only by “descending into the swamp” where the practitioners must forsake technical rigor that the really important and challenging problems will be found.

How practitioners should do this is in Part II of this review.

Review: Managing Humans

On a tip from Joel Spolsky, I picked up the informative and entertaining Managing Humans: Biting and Humorous Tales of a Software Engineering Manager by Michael Lopp. Not that I have read many of them, but Managing Humans is probably one of the best no-bullshit books on managers, staff, and office life in general for those of us who work in the software/web/engineering/design world. I recommend it not only for people like myself who are getting their feet wet managing people, but also for people who aren’t managing anyone in order to understand what their boss (and their boss’ boss) does and thinks about all day. If you’ve ever wondered, What do those managers do all day? this is the book for you.

Lopp goes over the basics of running a team: from hiring (on resumes: “you have 30 seconds to make an impression on me”) to resigning (“Don’t give too much notice”) to dealing with difficult employees (“Get the freaks to solve their own problems”), Lopp (or his alter-ego Rands) has practical advice on how to deal with it. And not crap like “Get your team to be the best it can be!” but tactical suggestions on how to play common scenarios. like bad meetings, employee freakouts, and dealing with burnt-out staff. And he does it in a readable, funny way.

Highly Recommended (for managers especially).

Review: Harry Potter and the Deathly Hallows

I don’t usually review non-design books here–unless of course, I can somehow relate them to design. But I won’t do that to Book 7 of the Harry Potter series. And No Spoilers for those who are still reading or will wait to see the movies.

I finished the book in about 13 hours of solid reading–about 20 hours after I bought it. I seldom have such a pop-culture moment–probably not since the Star Wars Episode I (ugh) premiere or the Survivor Season 1 finale have I gotten so wound up about an event like this. It’s doubly odd since I was a late-comer to the Harry Potter train. It was really my wife and kid reading them over the last year that dragged me kicking and screaming into the books and movies. About two years ago, I had even written part of a blog post called “Put down your Harry Potter and pick up His Dark Materials instead” but I never published it. Instead, I slowly got sucked in, and here we are.

One of the marks of a good author is this: can they make you care about inanimate objects in their books? There is a horrible scene in one of the later Patrick O’Brien books when the ship’s crew has to get rid of these two particular brass cannons, tossing them overboard, that had been a part of the series for years/books. It was devastating to me. I had many of the same type of moments while reading the last Harry Potter book. J.K. Rowling is no stylist like O’Brien, but she is just as good of a storyteller, if not better.

It’s the craft behind the books that is so good, and it is particularly obvious in Deathly Hallows, as the pieces of previous books, some stretching back to the first books of the series, fit together like some massive table-sized puzzle, made up of smaller puzzled. Reading Deathly Hallows, I found myself saying, “Oh, that’s why that happened” or “that’s what was going on there” more than once. It’s really a masterful bit of plotting, and it is something the likes of which I have never seen before, except perhaps in massive comic book arcs like the Dark Phoenix Saga of my youth. One only needs to compare the heavy-handed plotting of, say, the Star Wars movies or even (blasphemy!) The Lord of the Rings, to see the achievement here.

So goodbye, Harry. I can’t wait to read you again, some 20 or 30 years from now, with my grandchildren. Or perhaps, even just by myself.

Review: Dreaming in Code

Anyone who has ever worked on a large software project that has gone seriously awry and is behind schedule will do as I did: wince their way through Scott Rosenberg’s Dreaming in Code. Dreaming in Code is an account of the three years (and counting) spent designing and developing Chandler, a Personal Information Management (PIM) system, led by Mitch Kapor, the creator of Lotus 1-2-3 and the author of the seminal Software Design Manifesto, which should be required reading for all interaction designers. [Full disclosure: Mitch is a client and my experience working with him and his team was nothing like the quagmire detailed in DIC. It was challenging but fun, and Mitch is a visionary guy, able to leap between big picture and tiny details. Always have clients who are smarter than you.]

Chandler itself is a visionary idea, one that is similar to MayaViz’s CoMotion software in that it treats all bits of data (addresses, calendar entries, email, etc.) as fluid objects that can change and be used in different forms. Building that idea turns out to be a massive problem, as is detailed (sometimes in almost too much detail) in DIC. Readers who don’t have any programming background will likely find themselves occasionally glossing over some of the technical discussions and details, but as an introduction to what it takes to create a piece of software and as a primer on software history and methodologies, DIC is really top-notch. Very readable and it untangles subjects like programming methodologies more clearly than anything else I’ve ever read on the matter.

If you’ve never done a project like Chandler, this book is a window into what it can be like, although, as the book points out, every project is different. The Chandler team inadvertently makes a series of painfully bad errors in process, starting with the two years they spend without a solid design to work from, then their choice of a programming language none of the developers was an expert in, and even (as it turns out) in the choice of medium (desktop vs. online application). Then, as the slog continues, through its alpha releases, you are left just shaking your head: first in exasperation, then sadness, then resignation. It’s a wonder that any big software project gets done.

There’s some great pieces of wisdom tucked into this book as well. One in particular, to explain the slow start of the project, notes that it is always easier to make tools (and tools for the tools) than it is to make the product itself. Something that designers with our love of models also need to beware of.

Recommended.

Review: Managing the Design Factory

Donald G. Reinertsen’s Managing the Design Factory: A Product Developer’s Toolkit isn’t the type of book I typically read or review. But that’s fine; sometimes you need to look at the same thing through a different lens, and Reinertsen provides that: taking a cold, hard look at the design process and its outcomes. Despite the subtitle, I would say this more a book for product managers than for designers, but it contains plenty for designers to chew on and at least try to swallow.

Reinertsen’s first point: there are no best practices.

[T]he idea of best practices is a seductive but dangerous trap. Best practices are only “best” in certain contexts and to achieve certain objectives. A change in either the context or the objective can quickly transform a “best practice” into a stupid approach.

Instead of best practices, Reinertsen suggests we utilize “tools, not rules” and sets out to show and demonstrate some of them.

But first, he tackles some of the big questions, like what is the objective of the design process (what he calls “The Design Factory”)? Simple: to make a profit. Sales are the measure of how much users appreciate the value of our product, and we should be efficient in “converting time and resources into things people value.” (I told you it was a cold, hard look!)

[T]he only measure of the value of a design is its economic value. Our designs are not important because they are beautiful or because they are innovative; they are important because they make money. Our designs will only make money if we create recipes to turn material, labor, and overhead into valuable functionality better than our competitors do.

For Reinertsen, the purpose of the design process is to generate information (the “recipes” mentioned in the quote above). These recipes lose value over time (a recipe for a great 8-Track tape player wouldn’t be as valuable now as it would have been in 1974, say), so they must be managed and delivered in a timely manner. These recipes are also usually one-time processes. “There is no value,” Reinertsen writes, in creating the same recipe twice…we can only add value when we do something differently. If we change nothing, then we add no value.”

To make good recipes also requires good information, and the sooner the better. As most designers know well, making changes late in a product is far more costly than making them earlier on, so we need good information as soon as possible in the process to make the correct decisions throughout.

Information is a key theme throughout. One nugget of wisdom I found instructive was Reinertsen noting that “events that are less probable contain more information” and thus we should balance our risk/success rate to obtain more information. “When success is likely, the message of success contains little information, whereas if success is unlikely, the message of success contains a lot of information. Likewise, a message of failure contains more information if the failure is highly improbable.” We maximize the amount of information we can get by “approaching a 50 percent failure rate.” We need failure and risk. “When a design fails because we try something new that does not work, we generate useful information,” Reinertsen says. In fact, expert knowledge only comes from “being exposed to and remembering low-probability events.” What a great way to think about failure.

Risk isn’t to be avoided, but embraced. Reinertsen says we can make risk more attractive by

  • decreasing the magnitude of the downside
  • reducing the probability of the downside
  • increasing the magnitude of the upside.

Easier said than done of course. He goes on to note that “most product failures are caused by market risk” which is “a much tougher problem than technical risk.” Market risk is “determiend by how well the product specification meets customer requirements…Two factors that increase this risk are that customers often do not know what they want and that their requirements may change during the development process.” He then goes on to offer suggestions for managing this risk, including using a substitute product, simulating the risky attribute, and making the design flexible enough to accommodate changes.

Another thing that rings true is about deadlines in the design process:

[W]e rarely stop when we achieve a satisfactory solution, because this will simply result in a satisfactory product. Instead, we stop when we run out of time…activities are completed on-time or late. They are never completed early.

Interfaces are another key point throughout, but not interfaces how interaction designers typically think of them (as UI, say). Instead, these interfaces are the connections between different modules of a design–where one component of a system connects and communicates with another. An organization, too, is one such system, and Reinertsen looks at the various types of organizational structures and the communications between the different parts of a company. “The key driver of good communication is the amount of usable information communicated compared to what is needed to make good decisions.” In other words, you don’t necessarily have to increase the information flow to solve communication problems.

When designing products, Reinertsen says, it’s not enough to just find out what the customer wants. You need to find out “why they want it, and how they know they have gotten it.” This should be spelled out in what he calls a Product Mission, which outlines the product’s value proposition.

Why should a customer buy this product instead of a competitor’s? If this question cannot be answered in a compelling way in twenty-five words, then there is a fundamental problem with the design of the product…Most successful products have a clear and simple value proposition. Buyers typically make their choice between competing products on the basis of three or four factors.”

These factors should drive the design above all else. The Product Mission becomes “a compass for the design team, always pointing them towards true north.” One trick to do that, Reinertsen says, is to “write the advertisement for the product as one of the first team activities.” Another is to ask “what the mission statement excludes.” If it doesn’t exclude anything (the product is targeted to everyone, everywhere, at all times), it is useless.

Once you start having documentation (“specifications”), it is best, Reinertsen says, yto treat it as a flawed, living document, not something that is a fixed target. It’s a moving target and should be treated as such.

If you are a product manager or into the business side of design, I recommend this book for its clear-eyed view of the design process. Its economic perspective on our often-fuzzy art (“make the design resonate with more emotion!”) is a much needed tonic to design’s gin.

Review: Designing the Mobile User Experience

I was fortunate to get an advance copy of Barbara Ballard’s Designing the Mobile User Experience. In general, it is well-written, authoritative, and a boon to interaction designers working (or better, starting to work) in mobile. While I’m not sure this book alone will really enable you to design mobile user experience, it is a good introduction and overview of the mobile space.

It’s great that, rather than dive immediately into application design, Ballard spends the second chapter on the needs and contexts of users. I like that her definition of “mobile” has nothing to do with the device, but is instead a characteristic of the user. It’s the user that is mobile and is carrying the device. I was particularly drawn to the idea of user “microcontexts:” the social context, the physical environment, the application, and the interpersonal context of whom the user is interacting with all come into play.

Although the section on international usage patterns is good (albeit incomplete: no Korea or India?), Ballard makes some judgement calls that may only be true in the West. She says, for instance, that mobile devices being used by more than one person are rare. In some parts of Africa and, I believe, Indonesia, it is actually common. Families own sets of mobile phones and individuals simply take whichever one is charged and ready.

Ballard presents a number of different frameworks, models, and dissections that are useful for understanding the fractured nature of the mobile space. She presents a taxonomy of devices, a device hierarchy chart, the anatomy of Personal Computing Devices (PCD), and a method for selecting the device’s technology/platform (something interaction designers rarely get to do).

Designers, especially those new to mobile, will likely find the chapter on Mobile Design Principles particularly insightful, although here (like in other parts of the book) the technical jargon gets thick and becomes geared towards more developer types.

For designers of a certain ilk, the meatiest part of the book will be Chapter 6 on Mobile UI Design Patterns. (I personally find patterns hard to put into practice, but that’s another story.) Missing from some patterns is an accompanying image of the pattern, however, which makes some patterns hard to understand. Images of the patterns in actual use in addition to wireframe-like figures would have been nice. Designers who are into patterns might also checking out Ballard’s Mobile UI Design Patterns Wiki.

I was personally more interested in Chapter 7, strangely titled Graphic and Media Design. I’d call it, well, Interface Design. Using the brilliant metaphor of portrait miniatures, Ballard offers some really interesting advice for designing UIs for the small screen, such as that designers might want to replicate some of the characteristics of amateur art in their designs: no attention paid to the background, close cropping, and to play with perspective. Some color plates and examples of these practices on mobile devices would have helped this chapter.

Chapter 8, an overview of industry players, is probably crucial to any understanding of mobile even though for anyone with experience, this chapter contains very little insight. It’s also an industry that changes rapidly (although not rapidly enough in some cases). Likewise, chapter 9, on Research and Design, interaction designers will probably find puzzling and dated, springing from a very HCI/usability approach. A complementary book–and indeed, almost the inverse of this book–is Mobile Interaction Design, which I would recommend to really dig into interaction design for mobile. What’s missing from Ballard’s book is well covered there, and visa versa. I’d recommend the two books be read together (if you can afford the hefty price tags on both: $75 for this book, $60 for the other. Why are these books so expensive??)

As a final note, it will be interesting to see how the industry shifts (if at all) when the iPhone debuts in June. And how those shifts will affect this book. Very little is mentioned here of gestures, for example, and the iPhone makes some use of those, not to mention new haptic paradigms like multi-touch. Mobile design is changing rapidly and it is tough for any book to keep up.