Category Archives: Design

What would a designed philosophy look like?

I’ve been bothered by a simple question: if philosophy is, as I believe, a design discipline, what is 1) its material, 2) its specifications (“deliverables”, the plan of the designed thing), 3) its artifact (the designed thing itself), and 4) its actualization (the actual using of the designed thing), the qualities of which are the ultimate, though indirect, goal of design?

I am asking this way, not because of some compulsion for finding structural parallels, but because the problem of what a philosophy is and should do has been perplexing me. What is a philosophy? What is its nature? Is it the assertions? The logic? Is it a kind of thinking style?  When we apply the philosophy, or what is the nature of this “thing” that is applied?

It all becomes a little less perplexing (or gives me some degree of grip on the problem) when I compare it to other forms of design and make structured comparisons.

Even with the most concrete and tangible kinds of design, the ultimate intended effect is practical and experiential, and experiences are painfully indirect. The fact that designs in use disappear in the activity of using does not help matters at all.

Let’s start with some concrete examples, and see if they suggest new ways to think about philosophy. I will answer the question with two design disciplines I know well, UX and service design.

With UX, 1) the material is digital media (screens and other interfaces, and the underlying systems which enable and constrain what is possible); 2) the specifications are process flows and screen schematics (wireframes); 3) the artifact is the software or site; and 4) the actualization is a good user experience — effortless, pleasant and fruitful interaction with the software.

With service design, 1) the material is the entire extended organization (including not only the whole organization, including employees, partners, physical and digital infrastructure, practices/processes, policies, etc., but every point where value is co-created by delivery of the service, that is, with customers and users of the service); 2) the specifications are moment architectures and service blueprints; 3) the artifact is the service in its various forms across delivery channels; 4) the actualization is a good service experience for every actor involved in delivering, supporting or receiving the service.

So, giving philosophy this same treatment, 1) the material of philosophy is language in the most general sense (including not only words but symbols of every kind); 2) the specifications are lessons in the most general sense (books, essays, lectures, conversations, arguments, models, paradigms); 3) the artifact is concepts (understood as thought-producing mental behaviors, which is confusing because these behaviors are impossible to state directly and factually, but must be demonstrated); 4) the actualization is a thoroughly second-natural way of understanding (meaning that it becomes spontaneous and transparent) some domain of life (or the entirety of life) in a way experienced as better. By better, I mean more comprehensible, more livable and more valuable. By better, I mean we are able to avoid feeling perplexed, bewildered or indifferent to our lives.

As with all design, the work must be done with the actualization in mind, which is why the process is one of iterative experiment with direct involvement with those who will finally actualize the design. This is why human-centered design practice, or, in the case of service design, polycentric design practice are not specialized types of design but, simply, design competence. The implications to the practice of philosophy are significant. Does this help explain why philosophers crave conversation? Is the attempt to persuade an informal kind of philosophy design practice?

This is a first crack, so everything is up for discussion.

Redemption by design

Rorty, being intensely Rorty:

…the intellectuals of the West have, since the Renaissance, progressed through three stages: they have hoped for redemption first from God, then from philosophy, and now from literature. Monotheistic religion offers hope for redemption through entering into a new relation to a supremely powerful nonhuman person. Belief in the articles of a creed may be only incidental to such a relationship. For philosophy, however, beliefs are of the essence. Redemption by philosophy is through the acquisition of a set of beliefs that represent things in the one way they really are. Literature, finally, offers redemption through making the acquaintance of as great a variety of human beings as possible. Here again, as in religion, true belief may be of little importance.

And redemption by design is arranging the elements of life — people, things, ideas, etc. — in systems that allow them to cooperate for mutual benefit, however benefit is conceived by the cooperating agents.


I would like to count among the number of cooperating agents, “infrapersons” — psychic components of personality whose dynamic relations produce myriad moods, feelings, experiential colorings. Different designs will engage different infrapersons. Writing with a Bic pen or a #2 Ticonderoga is a different experience because it engages different infrapersons than writing with a Pelikan Souveran M800 or a Rotring 600 pencil. Sitting in a cubicle under a cold fluorescent strobe suppresses elements of self that might come out when sitting under sparkling halogen in a studio space. We feel more “like ourselves” when more of our self — more of our own infrapersons — have an opportunity to emerge and participate in our living. An important task of designers is to acknowledge and serve neglected infrapersons. To the degree it accomplishes this, design generates excitement, newness and je ne sais quoi. Cynics might dismiss this as slaking appetites for pointless consumption, but this is an uncharitable view of the profound relationship people can have with things in the world. I view these proud “anti-materialism” sentiments as a leftist strain of “not of this world” puritanism.)

Philosophy adoption

Susan asked: how is the philosophy design you envision different from Kuhnian paradigm shifts? The answer she extracted from me gets to the heart of my project, and I will need to emphasize this point in Second Natural: The physical sciences, and the attitude toward truth inspired by the physical sciences places all emphasis on epistemic and practical knowing (“what” and “how”) and trades off moral (valuative) knowing (“why”), which becomes a sort of ethic of scientificality. “The truth hurts” and being scientific means embracing the pain of sacrificing all other values.

But if we accept that we live in a truly pluralistic reality, and embrace the consequence that no single philosophy is capable of accounting for reality without strategically excluding, distorting or underemphasizing some realities in favor of others, we are freed question this tradeoff. A new scientific paradigm may give physicists a new way to conceptualize some stubbornly puzzling corner of their field, but these advantages might not be worth what is given up for ordinary people whose conceptual needs differ from those of physicists.

Once we see concepts as tools for selective perception, categorization and reasoning which permit some kinds of response and suppress others, we are freed (to a degree) to think of philosophies, components of philosophies and philosophical implications as matters of adoption. We can say physics theories what the best atheists say of God: “I have no need of that hypothesis.” If our concerns do later come in contact with theological or scientific problems, we might have to rework our personal philosophies in order to faithfully contend with their claims. This is especially true if we wish to win the respect of those communities and persuade them to accept our own beliefs. But this is not all that different from the adoption of any other technology that integrates with its design context.

Approaching the designerly

In the 20th Century everyone aspired to be scientific. Unfortunately, the image of science and scientific knowledge was distorted by rationalist fantasies, and attempts at scientific practice were encumbered — and, in fact, sterilized — by misnorms.

In the 21st Century we we are off to a good start, aspiring to be designerly. However the image of design is also distorted and many key design practices are either omitted or falsified. Too much emphasis is placed on “creativity” and too little on the social conditions productive of (and produced by) effective design collaboration. Design practice is still a romantic antithesis to 20th Century misconceptions of science and engineering — which bog design down with the same sterilizing burdens that has plagued scientism.

What is needed is a better synthesis of science/technology/engineering and design that supports a more productive (or should I say “serviceable”?) redrawing of the definitional boundaries, divisions of labor and collaboration, and organizational relationships between the disciplines associated with deploying technology for human purposes.

Service design research FAQ

When you work on a project with Harmonic it is very likely you will have the opportunity to participate in design research. This is something many people have never done before. We find that some people are either curious or anxious about what they can expect.

The following is a list of questions I’ve been asked more than a few times, and the answers I’ve given that seem to help people new to service design research feel informed and prepared, expressed in my own voice. Some of my fellow Harmonicas have expressed concern over how some of my answers are worded, so please know that anything here that strikes you as overstated or impolitic has likely been left in despite the advice of my colleagues.

Why are we doing so much research?

Short answer: Understanding the people involved in the service is, by far, the most important thing a team can do to ensure the success of a service.

Services are provided by people, for people. If you understand the people who receive the service, provide the service, and support the service behind the scenes (what we call in general terms the “actors” in a service) our chances of designing a service people value is far more likely. Our goal is to design services that people find useful, convenient and emotionally satisfying — the kinds of experiences that generate brand loyalty.

But people are surprising. Often what we think we know about them (even what we think we know about people in general) is wrong, and in ways that obscure real opportunities to improve their lives. Having a unique understanding of people gives a team access to new perspectives, new ways of thinking about serving them and can drive innovation and differentiation that is not only different but remarkable and relevant. (We call this “precision inspiration”.)

What kinds of research do you do?

To put it in the simplest terms, we think of our research in terms of foundational research (which helps us understand the actors who receive the service and those who provide and support it, which includes their needs, attitudes, behavior, contexts and worldviews), generative research (which helps us discover opportunities and conceive new ideas for improving service experiences), and evaluative research (which helps us see what ideas are most valuable to actors and how they can be made even more valuable). All these methods are qualitative, which means they are conducted with small numbers of people with a goal of gaining deep insights into not only what they do, and how they do it, but why they think, feel and behave the way they do. Most of the research we do contains elements of foundational, generative and evaluative research, but toward the beginning of most projects, the emphasis is on foundational and generative research, so most of what will be discussed here will focus on these.

Why do we need to do research with our own front-line employees?

Often when a company’s services fall short, it has little to do with the competence or attitudes of the employees who deliver the service. It has much more to do with how employees are evaluated or compensated, policies that limit what they can do for customers, or require them to do things customers don’t want. Or employees lack information needed to help. Or the systems they use get in their ways. Or employees are starting from behind, trying to salvage an already damaged experience, and (in extreme cases) numbed from constant exposure to customer anger. In other words, often a bad experience is not the employees’ fault, or anyone’s fault. The service has just organically evolved into something that isn’t working out for everyone.

And more often than not, no one person understands every factor that is contributing to the problem. The people on the front line who know the problems well are not always in a position to change the situation. And the people with the power to make changes are often far from the sites where the service is delivered and are operating with incomplete and sometimes incorrect information.

We do research with employees to help understand the big service delivery system, so we can find ways to make everyones’ lives easier. And we try to talk with them in ways that encourage them to tell us the full, unfiltered truth as they experience it, which is why we favor individual sessions, or sessions with small teams who collaborate together, especially when we are talking with front-line employees. We can only get the full truth if they are relaxed enough to speak freely and naturally.

How do we decide who we are going to talk with?

In order to ensure we are designing a service that works for everyone, we talk with a representative cross-section of people who use or might use the service we are designing. We are interested in both what they have in common, but also any important differences that might need to be considered.

Using what we learn from members of the client team, stakeholders we interview and available existing research we study, we list all the factors that might change the needs or attitudes or use contexts of the people involved in the service. These are developed into criteria we will use to determine the kinds of people we need to talk to.

Then we develop quotas for each of the criteria. We try to get at least three participants who have each of the criteria we identify, so we can get a sense of how that factor might affect the service. We try to get three because this is the minimum number where we can tell the difference between idiosyncratic answers and typical ones.

These quotas are used to recruit our research participants.

Why do we call them “participants”?

We call the people we invite to our sessions “participants” because they play such an active role in the session. Participant might even be an understatement. Effectively, we are asking them to play the role of teacher, and to help us understand who they are, what their life is like, and what they need and want in a service. We do design activities meant to help them do this teaching, but these are tools to aid the collaborative process of generating understanding.

Aren’t your sample sizes awfully small?

Typically, we will talk with twelve to twenty-four customers and with the same number of employees. To a person accustomed to marketing research, yes, this looks like a puny sample. The small samples make more sense, though, when you realize that what we are after is not only answers to questions — questions we think are the right ones to ask — but an understanding of how people see the world. This can sometimes help us see new non-obvious questions or even help us see that we have been asking the wrong questions!

The kind of research we do, especially early in the process, is designed to help people teach us about their lives, their needs, their way seeing the world, the significance of the service and its context to what they care about. This is very different from surveying them or asking them a list of questions. Imagine if you were learning a new subject at school, but instead of allowing the teacher to explain the subject to you, trying instead to survey the teacher to get the factual data you think you need to pass your tests. To allow someone to teach it is important to allow them to present information in their own way to convey the material in its own terms. (I like to believe we use the word “subject” to refer both to academic subjects and human subjects because we come to understand them by allowing ourselves to be taught.)

Instead of asking our participants a long list of question invite people to tell us stories, to help us understand how they see the world, to help them communicate what is most relevant to them, and in general to help us understand what questions we should ask them to learn what we need to know to design the best service for them.

By the time we are done with the first round of research, we have the information needed to design much better quantitative research. If you start with quantitative research, you’ll have a bigger sample, but you risk having statistically significant answers to insignificant, irrelevant questions.

How do we decide what we will do in the sessions?

We start our process by identifying the research objective: what does the research need to do in order to support the design? This is often mostly a re-statement of the project goal. We need to inform the design of the service by understanding all the people involved in it, their lives and how they might engage the service.

Then we identify areas of inquiry. In order to achieve the research objective, what will we need to learn about. Areas of inquiry are not questions — they are topics the team will ask to be taught about in various ways.

Once the areas of inquiry are defined and agreed upon, the team designs the research approach. It will include interview questions and interactive exercises designed to give the research participant opportunities to learn about the areas of opportunity.

The team then writes up a research protocol (sometimes called a “research guide”) and designs the materials used in the session.

It is important to note that the protocol is not a script. Some parts of it might be read like a script at some points, but the facilitator will use the protocol loosely to pace the session and to ensure the areas of inquiry are covered. But it is only a guide, and facilitators will often deviate from it. The goal of a session is to get the participant to teach, and that means keeping it conversational and giving the participant enough space to tell us things we might not have anticipated. Our sessions are designed for uncovering the unexpected — because this is where the biggest opportunities come to light.

Who from my organization should attend sessions?

Ideally, everyone would attend. Realistically, at least one person from any department or role that will be involved in shaping or delivering the service based on the research should be involved in the research.

We recommend this for two reasons. First, different roles notices different things in the sessions, and interprets them in different ways. Having a wide range of disciplinary lenses present in the sessions enriches the team’s understanding of what it hears.

Second, service design touches many roles throughout the organization. We believe people have a right to help shape their own futures. But pragmatically, it is a great way to build alignment, credibility, ownership and enthusiasm for initiatives if respected members of the teams who will contribute to the service were directly involved in shaping the service, and can explain why the service was designed the way it is.

What do I need to do to prepare for a session?

Generally, very little preparation work is needed. If you are observing a session the team will give you everything you need to know before the session. Often the team will schedule an orientation session to help everyone understand the purpose of the research and the flow of the session. Anyone who is playing an active support role will get additional training. Prior to each session the facilitator will remind everyone of what they need to know.

Generally, for in-person field research, everyone involved in a session will be given all the equipment they need. If the session is remote, you’ll want to bring a notebook and something to write with. We ask that you do not use your laptop for note-taking when conducting an in-person session.

What are the sessions like?

Typically sessions last ninety minutes, and are followed by a debrief that lasts between thirty minutes to an hour. Please plan to attend the debrief for your session, because this is a very important part of our process.

Normally, the session starts with an overview. The facilitator thanks the participant and explains the purpose of the session. The people attending the session are quickly introduced. Then the facilitator gives an overview of the session and sets the participant at ease by telling them that we are here to learn from them, that there are no wrong answers, that it is okay if they don’t remember everything and most of all to please tell us the full unfiltered truth about their experiences, and to not worry about hurting anyone’s feelings. We will sometimes joke with them and generally do whatever it takes to make them feel comfortable and ready to converse naturally with us. We answer whatever questions they have and make sure they have filled in the required release forms, understand the compensation and give us permission to record.

Then we usually start with an interview, leading with some easy warm up questions. We learn about who they are. We will sometimes ask them their opinion on something tangential and fun to answer. Where do they like to eat, or what is their current favorite service? Then we get background on how they use the service, what they value about it, how it compares to other services, etc. We also sometimes touch on their current brand perceptions.

Then we shift into a more interactive mode, and do some collaboration. Almost always will ask them to tell us stories that help us understand their needs, while we visually capture the story, step by step. We are interested in hearing about their whole experiences, not only the part where they might use the service. And we ask them to tell us not only what they did, but how they felt, what they were expecting, what they were thinking about, what they wanted to accomplish. We also might visualize their service ecosystem, inventorying the people, places, tools, and related services that make up their lives. Frequently the team will design other interactive exercises to help us get at needs, behaviors, attitudes and preferences.

Another activity we often do is show prototypes to participants and ask them to respond. By prototype, we mean any kind of artifact that allows the participant to imagine what it would be like to engage the service. It might be storyboards or screens, or we might ask them to act out service scenarios with us.

If all goes well, the facilitator will build enough rapport with the participant loosens up and feels free to express their feelings in their natural voice. We like to get these moments on video so we can show them to people who were not in the session. We want to help everyone in an organization relate to the humanity of their customers and the people who serve them, and to see the human impacts of decisions.

How do these sessions differ from pre-Covid times?

Online sessions are very similar to in-person. The big difference is how the activities are done. In-person, we are handing our participants the pen and asking them to interact with the materials. This is more difficult remotely. We are often using virtual surfaces, electronic sticky notes, and doing some of the interactions for the participants under their direction.

The dynamics are also a little different, especially for customers. When we do in-person session we often visit them in their homes, offices — in their spaces. We work hard to make them comfortable, but sometimes it takes a few minutes for them to get used to us being there. It seems to be a little easier to adjust to a video conference. The downside is there is a connection made in person, and insight you get from being in their space that doesn’t happen with the same intensity in a remote session.

The biggest positive tradeoffs are probably geographic flexibility and the simplification of logistics. With remote sessions it becomes affordable to recruit participants from many diverse regions instead of limiting sessions to a small set of locations. In-person sessions require a lot of coordination of people traveling to the market where the research is being conducted and ensuring they have transportation to and from the session location. Remote sessions remove most of this complexity.

Once Covid is overcome we return to relative normalcy, some of the methods developed to cope with the pandemic will stay in our toolbox and continue to be used to fit client needs and make optimal tradeoffs.

What am I supposed to do in a session?

There are multiple roles in a session. Generally, one person facilitates and one or more people assist. When we do sessions in-person we normally limit the number of people in the session to three, not counting the participant. Participants are not used to research, and they can get stage-fright if too many people are staring at them. With remote sessions it is possible, though not desirable, to have more attendees.

If you are assisting with the research, you will get special instructions and training from the team on how to use the research tools. With remote sessions we sometimes ask for help operating our virtual whiteboards. With in-person sessions we sometimes need assistance with organizing materials or operating cameras. It is never terribly complicated, and you will never be put in any situations for which you were not prepared.

The primary thing to keep in mind is that we are trying to create a conversational dynamic. This requires some conditions that we do our best to set up and maintain. What we do not want to happen is for the session to feel or look like a meeting where multiple people are talking together, and this tends to be the default unless steps are taken to prevent it. When the session is in-person, we usually try to arrange ourselves so the facilitator and participant are facing each other and others present sit to the side out of the direct line of sight. With remote sessions, we often ask everyone to turn off their cameras and microphones except the facilitator, until it is time to open the session up for questions.

Taking notes is very important. Write down anything that speaks to the areas of inquiry, strikes you as relevant to how the service should be designed, or surprises you. And if the participant says any great quotes, capture as much of it as you can, or at least jot down some of the key words and roughly what time it was said so we can find it in the transcript later.

Your notes will be useful during the debrief.

What should I know about asking questions?

During the session, try to hold your questions or comments until the facilitator prompts participants. It can be helpful to write questions down as they occur to you.

Sometimes the facilitator has a specific way to ask the question in mind. And sometimes the facilitator will leave more silence after a question than is comfortable. Trust the facilitator, and resist the urge to jump in and clarify questions, or to try to help the participant answer or break awkward silences. It’s hard to do, but it is important.

When the floor is opened for questions, try to ask open-ended questions. The trick is to start the questions the right way. Starting with “Can you talk to us about…” or “Please tell us about when…” almost always finish well. Sentences that start with “Do you…” or “Would you…” are risky. If you notice your question has devolved into a multiple-choice and you are finding yourself stringing together a bunch of “or” options, your question is on the wrong track.

The good news is you can always interrupt yourself and say “Actually, let me try asking this question another way.”

What am I supposed to do in a debrief?

After the session ends, the team will reconvene for a debrief. This is one of the most important activities we do during field research. The purpose is to capture what was learned in the session while it is fresh in everyones’ mind.

The debrief facilitator interviews the team on each area of inquiry, documenting what was learned in a format that makes it easy to compare findings between different participants.

Often there are disagreements or differing interpretations of what was said, and this is good. The discussions around differing understandings are central to the process and helps the extended team align on what has been learned.

One thing to keep in mind: A debrief is not meant to be an exhaustive compiling of everyone’s notes in a single document. The debrief is meant to be a summary of what the group learned. Someone not in the session should be able to pick up a debrief and learn who was interviewed and how much was learned from that participant about each of the areas of inquiry. The debriefs are a powerful tool the team will use during analysis.

How do we make sense of what we hear?

When the field research is done, the team analyzes the debrief forms and the outputs from the activities, supported by video footage and/or transcripts of the session.

The analysis is done partly in collaboration with the people who helped do the research. Sometimes we will conduct an internal team interview to outline the high level findings of the research. We then use the debriefs and transcripts to guide discussions and exercises to find patterns and themes in what we learned.

We will also compare the stories we heard and look for commonalities and variants which are documented in an experience map which visually documents the experience customers and others are having receiving and delivering the experience.

When possible somewhere toward the middle of research analysis the team will invite employees of the organization into the analysis process. We call this Research Open Studio. We show people our raw research materials, including the stories we gathered, and selected footage from the sessions. We share the findings in their current rough state, along with the questions we are asking ourselves, and bring them into our conversation so they can share the thought process and the excitement of discovery.

When do we get a readout?

Often within a few days of completing the research the team will send out an informal top-line summary of findings, and sometimes will include links to the debriefs. But the full presentation of what the team has learned usually comes at the beginning of the next workshop, when the research is digested and interpreted to identify opportunities to improve or even reinvent the service and to generate new ideas.

What do we do with what we learn?

The research outputs are designed for multiple purposes. First, they are designed to communicate what was learned as clearly and compellingly as possible, and to help the organization align around a single version of the truth created by the extended team.

The second purpose of the research outputs is to serve as workshop tools, to help with opportunity identification and prioritization, idea generation, concept assessment and concept prioritization. The experience maps, the themes we identify and the other artifacts generated during research analysis become ideation canvases workshop participants use to think about experiences from a customer’s or front-liner’s perspective.

Am I going to love research and want to be involved in it as much as possible in the future?


Genre Trouble

Thank you Richard Rorty:

“The more original a book or a kind of writing is, the more unprecedented, the less likely we are to have criteria in hand, and the less point there is in trying to assign it to a genre. We have to see whether we can find a use for it. If we can, then there will be time enough to stretch the borders of some genre or other far enough to slip it in, and to draw up criteria according to which it is a good kind of writing to have invented. Only metaphysicians think that our present genres and criteria exhaust the realm of possibility. Ironists continue to expand that realm.”

1) I love this quote. I have extreme trouble coloring inside the lines of preexisting genres, given the fact that my worldview is a synthesis of an esoteric and Nietzschean perversion of Pragmatism, a hall-of-mirrors reflective design practice, and an idiosyncratic take on religion bordering on universal heresy (which is why I’m Jewish). Consequently, I have little hope of (or interest in) writing a book that does not generate a genre. This is why I will need to continue to self-publish. I feel a combination of impatience and panic when it is suggested that I need to nail down my audience, as if they already exist, and write to them, for their sake.) Also, nobody is going to craft a book to my standards. I may need to buy letterpress and bookbinding equipment.

2) To find a use for a new kind of writing… The above passage was embedded in an extended pragmatic exploration of Derrida’s writing. Rorty suggested that we forget what Derrida was asserting, and instead ask: what was he doing with his writing? I like translating this to: Forget the content — what does his genre want to do, and why? He is doing something new with writing, and to allow it to do its new thing for us we have to release it from the purposes and rules governing the genre(s) of philosophy.

3) Point 2 is getting very close to my interests (which is hardly surprising given that Rorty is the proto- pragmatist pervert). To create a new kind of writing, then find a use for it — is very much, to my designerly eyes, like intellectual R&D. This follows the pattern of how many technologies are developed, especially very new and unfundable ones. Some playful or obsessive technologist in love with a problem or a material intuits a possibility and follows hunches to produce some ingenious invention. This invention inspires other similar types — lovers of engineering problems — to push it further, just to see what they can get it to do. Eventually, the inventing proliferates, refines and develops to the point where it attracts the attention of some practical mind who sees in this invention the key to solving some specific real-world problem. Now a technology is ready to cross the threshold between technology and product.

4) What kind of mind escorts a potentially useful technology through the journey that transforms it into a useful, usable and desirable product and out into the marketplace? Lots of people try to do this work. The ones who are best at shaping technologies into products (a.k.a. goods or services) that fit human needs, desires and life-practices are designers. Designers (whether they are called that or not) are the people who see human life as vast, complex, often messy, systems, and understand that products are subcomponents of these human systems. The success of a product hinges on how readily it integrates into these human systems. (Increasingly designers are considering more than end-user integration, and are getting involved in manufacturing, distribution, promotion, merchandising, purchase, use, service, disposal, recycling, etc.) Wherever human and nonhuman systems are meant to integrate, designers increase the chances the integration will succeed. Some designers see a technology and immediately grasp its product potential, others keep up with technologies of various kinds so when they are given a human problem they can play matchmaker between this problem and the solutions in their imaginations, still others start with a thorough understanding of people and their lives and learn to define these problems so they inspire solutions from more technological minds. The best designers do all three, and effectively straddle and blur (or, rather interweave and entangle) the lines between technological and human systems.

5) What if we view philosophy as it is done today as technological development? And applied philosophies as slightly more focused technologies carried a step closer to problem types? Is there not room for a discipline that uses design methods (especially HCD, human-centered design methods) to apply philosophical technologies to very particular cases. Such a discipline would research problematic situations and the people, things and contexts that constitute them, define problems to be solved with the help philosophical “technologies”, shape conceptual systems that resolve these problems and develop materials to help an organization adopt the improved, more useful, usable and desirable philosophy? What if we use deep HCD to throw organizational business-as-usual thinking into crisis, so that it clears the ground and opens it into perplexity (what Wittgenstein identified as the philosophical negative-space of “here I do not know how to move around”), upon which a new philosophy can be designed (“to understand how things in the broadest possible sense of the term hang together in the broadest possible sense of the term.” as Sellars put it).

6) If I view my problem as a genre problem, I can say I want to write a book outlining a new discipline as the first (at least first self-conscious) product of this discipline. I want to design a philosophy of philosophy design. It will be erected on an assumed metaphysical foundation — a faith — that doing such a thing is not only permissible, but necessary. But, being a designed conceptual product, it will seek voluntary adoption instead of argumentative coercion. It will try to demonstrate that this discipline, viewed in this way, viewed from this carefully designed perspective will be a useful, usable and desirable way for certain kinds of people to live their lives and make their livings, and that (this will be secondary) that organizations that hire and support people who do this kind of work will help generate more usefulness, usability and desirability for its employees, partners and customers.

7) Whatever we call them — Organizational Philosophers? Concept Designers? POV Framers — they will be responsible for:

  • Understanding how different people involved in an organization or part of an organization (department, office, team, etc.) think;
  • How these ways of thinking converge, diverge, harmonize and conflict;
  • What tradeoffs each of these ways of thinking make in terms of what domains of knowledge they do a good job of comprehending and communicating, versus what they must deemphasize, ignore, suppress or neglect in order to have clarity?
  • What tradeoffs these ways of thinking make in terms of values — what values do they elevate and serve, and what must they deprioritize or sacrifice in order to focus their sense of purpose?
  • What tradeoffs these ways of thinking make in terms of method — what kinds of action does it guide effectively and what kinds of action does it misdirect, encumber or fail to support?
  • Analyzing what the organization wants to be and to accomplish, and determining what an organization’s thinking needs to help it comprehend, do and care about.
  • Leading the development of conceptual frameworks the organization can use to think together in order to better be and do what it aspires to.
  • Communicate and teach the new conceptual frameworks using various vehicles such as visual models, verbal and visual explanations, taxonomies, glossaries of shared vocabulary, reference materials and training programs.
  • Testing and iterating both the frameworks and the communication/teaching vehicles.
  • Socializing and encouraging adoption of concepts across the organization.

This is what I want to do with my life, and this book will be a justification, a description of how it should be thought about and done, and be a proof on concept of what the profession produces.

Now, this is just me writing about a possibility. I cannot guarantee it will stick, and I’m not even sure I didn’t just derail my original plan for Second Natural, but it is at least getting me closer to what my intuition seems to want me to talk about.

I did not start off meaning to write this post, but here we are.

This is why we read Richard Rorty.

SD and UX research

I often get asked questions about the relationship between service design (SD) research and user experience (UX) research. The answer is very simple, but communicating that simplicity is not easy. This post will attempt the briefest, clearest answer possible.

Explaining the difference in the two forms of research will require briefly explaining the relationship between UX and SD, so let’s start there.

  • User experience is  typically defined as the practice of designing digital touchpoints. Digital touchpoints are usually parts of a larger experience that extends beyond digital to non-digital touchpoints, such as voice, physical spaces, printed materials and broadcast media.
  • When many kinds of touchpoints, including digital, are designed together to deliver a coherent experience (usually, but not always for a customer), this is known as omnichannel experience design.
  • Service design extends omnichannel design beyond, by designing for every person (service designers call them “actors”) involved with receiving the service and delivering a service (customers and employees interacting “frontstage”) and with supporting the service behind the scenes (employees working “backstage”). Anything involved in the delivery of the service — whether it is a human actor, departmental or team structures, a front- or backstage touchpoint, a technology, a process or even a policy — falls within the scope of service design.

It can be helpful to think about the relationship in terms of design materials. Every design discipline shapes a certain kind of material to produce value for the people who use it.

  • The material of user experience is digital media.
  • The material of omnichannel design is touchpoints.
  • The material of service design is organizations.

The differences sketched out above should set the stage for understanding six main differences between SD and UX research. Most of the differences are matters of degree, and of course, there are always exceptions.

One key point that should be noted is this: Service design does not in any way replace UX, nor does service design research replace UX research. Rather, service design helps UX do a better job of designing touchpoints that support the larger service experience.

Another thing that should be noted: None of the six key differences I list are matters of technique. The toolbox of techniques used in service design overlap with those of UX, with only minor variations in how they are used. A UXer attending a service design research session is unlikely to see any completely novel methods , but is very likely to be shocked by the breadth of material covered and the rapid pace of the sessions. They might feel anxious about an apparent lack of thoroughness. This is by design, though, and I hope that what follows (in #3 and #4) will shed light on why.

Difference #1: Who helps conduct sessions 

Because the material of service design is the whole organization, many people are involved in the design of a service. A typical service design may change organizational processes, IT systems, policies, physical spaces, call center scripts, even how departments are organized. To improve the chances these changes will be made, it is important that the people who will be making the changes (or will be affected by these changes) understand why these changes are worth the effort and discomfort. If people reject the research or dispute the design decisions, change will not happen. Alignment of understanding is absolutely crucial.

The best way to create this alignment is to bring as many people  along to help with the field research. Service design research is the ultimate alignment tool. When respected representative stakeholders from across the organization participate in research, witness firsthand how the service affects people’s lives, and contribute their own disciplinary knowledge and perceptions to the effort, insights from the field are deeper, more impactful, and more credible across the organization.

UX also benefits from client participation, of course, but can normally win sufficient alignment with far fewer people.

It is important to note that one of the most important stakeholders to include are UX designers, who will derive many of the same benefits from SD research as they would from UX research, or at least from foundational or generative UX research. (More on this below).

Difference #2: Who is recruited to participate

Because a service is designed for both those receiving the service and those providing and supporting it, the research is done with multiple types of participants situated in different parts of the experience, both front-stage and back-stage. Additionally, because services are experienced in many places in many different channels, it is often necessary to conduct research in multiple kinds of settings. For instance, a service design team might investigate how a service is experienced in the home and in a retail space, and how the service is delivered digitally, by voice or in person. While UX research recruits a variety of cohorts and considers use in a variety of contexts, service design expands the number of participants, roles and settings beyond what is typically considered in UX.

Difference #3: Breadth of inquiry

Service design’s scope is relatively vast compared to UX. Not only must we investigate more actors and more settings, we often use different approaches for each of them, to help the team get insights on how the service comes together and how it is experienced by everyone involved. Further, service design is trying to piece together a whole experience as it unfolds over time and zig-zags across channels, so the scope of each research session tends to cover longer spans of time than a typical UX project, and investigates a participant’s experience with equal attention wherever it leads, regardless of channel. With UX research, times spans are often briefer, and non-digital channels are treated as context for the UX design, not as something that itself might be redesigned.

Difference #4: Depth of inquiry

Because its scope is so broad, service design does not go into the detail and depth that UX design does. This is why no service design should ever go directly into implementation. Service design only defines UX design problems it does not resolve them.  Every touchpoint, digital or otherwise, defined by service design requires further work by design specialists who have mastered the craft of designing that type of touchpoint, with service designers staying involved to ensure the service as a whole stays consistent and seamless.

UX research is concerned with gathering insights that will guide the detailed design of a digital touchpoint. It seeks to get deep, detailed information on the person’s use context, mental models, vocabulary, physical and perceptual abilities, etc. Service design research only skims the surface of these questions, in order to keep an eye on how the touchpoints are integrated with one another and other components of the service.

In evaluative research, service design only validates concepts at a high level, concerning itself mostly with the usefulness and desirability of touchpoints in the context of the broader service, and deemphasizing usability to the greatest degree possible.

The only part of UX research that service design mostly replaces is the foundational research, and even there, only partially.

Difference #5: How analysis is conducted

As mentioned above, service design research is the ultimate alignment tool. To stabilize and refine alignment, service design teams will often conduct analysis socially and in the open, preferably in a location where members of the organization can drop in and participate. At Harmonic, we have called this “open research studio”. The analysis is intentionally visual and easily digested. Stories and other insights gathered from the field are displayed in ways that invite conversation and direct collaboration on the artifacts.

The process of collaborating encourages cross-disciplinary conversations and brings out a shared understanding that is relevant and comprehensible to everyone in the organization. And because so many people have had direct involvement in shaping the understanding it is likely to be complete and credible.

Difference #6: How findings are applied

Finally, returning to the earlier point that the material of service design is organizations, a material this complex is too much for any single mind to contain or any single talent to shape. The whole organization must be mobilized in redesigning itself to deliver better experiences. Everyone must learn to function as members of a design team. To make this transition as intuitive as possible, many service design research outputs are designed specifically to serve as large-scale collaboration tools. Most service design research findings include various kinds of experience maps meant to be physically hung on a wall or otherwise shared, and to allow teams of people to interact with the surface as a canvas for collaborative work.

Of course, the design research findings are always tools used for designing. But because the interpreters of other kinds of design research are usually experienced designers who already know how to interpret findings to make design decisions, researchers are free to emphasize the content of the findings over their form. The fact that many of the people doing the design are inexperienced working in that way places special demands on service designers to think more about the form and explicitly make them not only easy to understand, but easy to use in support of opportunity identification, ideation, or evaluation.


Wow, that was not brief after all. But I hope it was at least clear. I’ll make one more attempt at brevity with a summary:

  • Service design research seeks to understand many types of people who receive, deliver and support the service
  • …it accomplishes this understanding using a wide variety of research approaches in many different settings
  • …the research is conducted, analyzed and applied by large rotating multi-disciplinary teams which should include UX designers…
  • …but it does not replace UX research, which should be used to both inform and evaluate the detailed design of each digital touchpoint in the service.


Conceptual Integrity and Empathic Anticipation

In the late 90s and early 2000s, designers used to repeat the mantra “learn once, use everywhere.”

It appears to me that this ideal has been waning for the last ten years or so, in favor of a different ideal, which involves understanding what people will be thinking, feeling and trying to do at each moment of an experience, in order to anticipate their needs and likely responses.

The first ideal emphasizes working systematically to develop and maintain conceptual clarity, consistency and coherence. The goal is to help people understand how the system works so they can learn it and control it easily. Let’s call this ideal Conceptual Integrity.

The newer ideal emphasizes empathizing with people and understanding their experience so that learning or understanding the system is unnecessary. The system shapes itself around their needs, their wants and their desired actions. Let’s call this newer ideal Empathic Anticipation.

It is clear that the two ideals conflict to some degree, which means tradeoffs must be made. Perfect Empathic Anticipation requires flexibility from systems to conform to the momentary needs of a moment. Conversely, perfect Conceptual Integrity would limit the repertoire of interactions to a small and learnable set, and would not support arbitrary deviations to address needs a person might have in only one moment of an experience.

Of course, no design is fully one or the other. Most designers try to strike a balance between the two ideals. The best solutions manage to minimize tradeoffs and cleverly conceal the tradeoffs that are made so people don’t even notice them.

But to make these kinds of tradeoffs designers need at least three skills and toolsets to support those skills.

First, to design with conceptual integrity, designers need to know how to think and work systematically, both conceptually and concretely, so that the relationships between the whole and its parts are perfectly clear and logical.

Second, to design with empathic anticipation, designers need to know how to develop deep insights into the people they are designing for, what they are trying to accomplish and how this need fits into their lives as a whole, so that each moment of the experience accurately anticipates and effectively responds to their needs, both functionally and emotionally.

Finally, to pull together the right experience for this particular person in this particular situation, we need to know how to think about design problems and make the best tradeoffs. We must never automatically apply our own favored skills and best-mastered tools, but rather select our methods intelligently in response to our understanding of the problem. To do this, we need to draw on both ideals and bring them to bear on design approaches themselves.

Foregrounds and backgrounds

I am looking in my anomawiki for a quote from Nietzsche about foreground and background philosophies. I am digging through one of the themes I’ve catalogued, “depth“, and noticing — somehow for the first time! — how many of these quotes involve water, and specifically cold water. Reading Nietzsche I slowly discovered a symbolic language — or did I invent it? — It is probably best to say that in experimental interaction with his corpus, I instaurated a certain symbolic language that invests Nietzschean passages with multiple layers of powerfully direct intuitive meaning. (These meanings have been so intense that at the peak of my early Nietzschean encounter, I sometimes got butterflies in my stomach in the evening anticipating waking up the next morning and reading him.) I’ve learned to interpret water as a symbol of chaos, not only in Nietzsche, but also in Jewish scripture, which is why my Hebrew name is Nachshon. Coldness is another symbol, signifying betrayal. Nietzsche speaks often of coldness at the depths and heights. When we immerse in chaos, when we undergo the deepest, most trophonian perplexities, we often find that our own value hierarchies get loosened and shaken up. And when we ascend so far that we can survey a more expansive whole, this can also effect an inner political shift. The valley is temperate and more stable, but Nietzsche’s preferred valleys were near cold lakes and icy peaks, to remind us of our tragic situation between beneath and beyond.

I did not mean to write this much about Nietzsche.


Here is the quote I was looking for:

The recluse … will doubt whether a philosopher can have “ultimate and actual” opinions at all; whether behind every cave in him there is not, and must necessarily be, a still deeper cave: an ampler, stranger, richer world beyond the surface, an abyss behind every ground, beneath every “foundation”. Every philosophy is a foreground philosophy — this is a recluse’s verdict: “There is something arbitrary in the fact that he [the philosopher] came to a stand here, took a retrospect, and looked around; that he here laid his spade aside and did not dig any deeper — there is also something suspicious in it.” Every philosophy also conceals a philosophy; every opinion is also a lurking-place, every word is also a mask.

This passage implies that a person can always dig beneath and undermine his own philosophy if he chooses, and raises the question: why don’t we keep digging forever? What are the “stopping conditions”, to put it in wicked problem terms?

My own suspicious stopping point — (and yes, you should ask “why here?”) — is a metaphysics of radical surprise. Due to the relationship between truth and reality, truth is pluralism which “goes all the way down”, that reality is an infinite sphere whose center is everywhere and circumference is nowhere. Truth is the attempt of each center to make sense of the whole — a whole which is constituted entirely of centers. No center can embrace this infinite whole, so we radiate our being outward into the other centers, and they in turn radiate back. The interwoven radiating centers congeal into real situations and overlapping approximate truths, most of which have some validity, and all of which contain significant blindness toward what others know, and which necessarily make tradeoffs, only some of which we are aware. From time to time we are shocked out of our wits by the irruption of some reality for which we are unprepared, and often we have no idea how to make sense of it, unless we actively make that sense. This making of new sense is philosophy.

Some of us even go looking for shocks. We especially seek them when we are dissatisfied. And especially once we learn how easily apparently stable, unquestionable truths can be undermined, and once we learn to handle some of the unpleasant hazards of undermining and gain confidence in our ability to make new sense where we’ve loosened up and broken down old sense, undermining becomes a tool for overcoming some of life’s occasional horrors. In other words we are free to design philosophies that support a life we want. Like all design, philosophy functions in real contexts, must make optimal tradeoffs to meet requirements while respecting constraints, and they will succeed and fail in different ways to different degrees.

My background philosophy tells me that we can and should design our philosophies using all the best practices of human centered design. This is the best we can possibly do. The closest a human being can get to truth is to believe ideas that work well, meaning they help us do what we need to do, they prevent us from feeling perplexed, or getting confused or making mistakes, and they help us feel the value of our lives. (These, by the way are the criteria for good design laid down by Liz Sanders in the most influential paper no designer knows about.) None of these philosophies should be expected to hold up in every possible context and withstand every criticism, and if that becomes our primary goal, it is certain that this all-encompassing generality and well-armed defensibility will demand tradeoffs that will harm a person’s quality of life in innumerable ways. This deeper philosophy is pragmatist through and through, and draws on many strands of pragmatist thought including Actor-Network Theory. I call it design instrumentalism. It is never far from chaos, and dips in and out of perplexity as a matter of method. I can only handle it in small doses. As I was reminded this morning, Nietzsche said “I approach deep problems such as I do cold baths: fast in, fast out.

My foreground philosophy is what I designed for myself as my everyday conceptual models to shape and guide my understandings. I crystalized them in image and word in Geometric Meditations. The ideas might seem profound, but that is because of their careful design: this philosophy was designed to maintain value-stability ‘warmth” at depths of thought where a soul risks coming apart. That is not to say I do not believe them wholeheartedly, because I do, but I believe them with wholehearted irony, meaning that I see them as some among many ways to make sense. The conceptual models in Geometric meditations function as an interface I intentionally designed to shield me from the instability and complexity of design instrumentalism.

I am sure this has made sense to nobody, but I needed to think it through.

Raw experiential resources for my next book

I am making a list of some strange phenomena which are the daily fare of strategic designers, but which are seldom experienced outside the field, at least not in the way designers experience them. By designers, I mean anyone engaged in human-centered design. These phenomena do not occur at the same intensity and frequency in problems that do not explicitly contend with subjectivity. Designers must live with them at full intensity, for long durations, without any easy escape route. Here is the list, so far:

  • Dependency on conceptual models (which I will just call “models”) to guide the forming of a system that is experienced as clear and coherent to those who participate in them
  • Uncanny difficulties in agreeing on models among members of design teams, which render subjective differences stark
  • Difficulties in interpreting phenomena, and especially subjective phenomena, among different team members
  • Difficulties in weighing design tradeoffs among different team members
  • Existential pain associated with relinquishing (or even temporarily suspending) models that one has adopted — even in order to listen and understand another perspective — a phenomenon that can be called “pluralistic angst”
  • Dependence on profound respect, trust and goodwill among team members to navigate through and out of pluralistic angst
  • Tactics employed by well-intentioned people to avoid the pain and effort required to overcome pluralistic angst
  • The ubiquity and invisibility of models — and the best models are the most ubiquitous and the most invisible — not only in design, but all understanding, which only becomes detectable in pluralistic conflict
  • The miraculous way truths and unnoticed realities leap from nowhere (ex nihilo) when a different model is adopted and used
  • The weird way a change in a sufficiently foundational model can sometimes change (transfigure) the meaning of one’s life as a whole, even when the change is meant only to affect a localized problem
  • The fact that there are no determinate techniques, rules, criteria to overcome pluralistic angst (though there are approaches that can assist the process) — that people are thrown back into their bare unequipped souls to find the resources needed to overcome it together
  • The solidarity among team members which can result from overcoming pluralistic angst with respect, trust and goodwill

Anyone who has been through the harrowing experiences described about enough times 1) to recognize what is happening, 2) to find faith that these things can be overcome, 3) to understand the value of overcoming them, 4) to find the attitude of soul most conducive to overcoming them (which includes grace toward one’s own missteps, doubts and moral failings during the process) might start seeing similar phenomena everywhere, at all scales, from international politics to personal relationships to one’s own inner conflicts. Or, at least this is what happened to me.

I was driven deep into existential philosophy, including phenomenology and hermeneutics then into pragmatism and its offshoots in social science to try to understand the weird kinds of pain I experience as a designer. Philosophy has never been speculative or abstract to me. It is concrete, near and a matter of life and death.

As a result of this search for understanding, I have designed myself conceptual models to help me re-understand the human condition as largely one of conflicting conceptual models.

It is here that it becomes fairly obvious how philosophy and design connect and merge into something inseparable. That is what I plan to write about and publish next, now that I have crystallized my core conceptual models in the form I believe they deserve.

Design Collaborator’s Bill of Rights

Recently I’ve been asking my teammates to exercise certain rights I believe all design collaborators on projects should have. So far, the rights have been listed as occasions arise, but I’m starting to want to keep a list, because I don’t want to forget them, but also because they feel sacred and I would like to see them worded precisely and laid out systematically as a Design Collaborator’s Bill of Rights. I will be updating this list, and once it stabilizes I might letterpress it as a physical piece.

  • The right to a brief: every team member has the right to request a clearly framed problem to solve autonomously (as opposed a specification to execute).
  • The right to clarity: every team member can request a detailed explanation for any aspect of the project, until it is completely understood.
  • The right to justification: every team member can raise explicit concerns with decisions, and to have the concerns addressed.
  • The right to propose alternatives: every team member is free to conceive and communicate different approaches to solving problems.
  • The right to have pre-articulate intuitions: every team member can expect to have pure (pre-articulate) intuitions respected as valid, and to be assisted in giving the intuition explicit, articulate form.
  • The right to speak: every team member’s voice will be actively welcomed in discussions, meaning that opportunities to enter the conversation will be offered and space to communicate without interruption will be protected. 
  • The right to be fully understood: every team member can expect active listening from teammates, which means they will be heard out and interpreted until full comprehension is accomplished.

The Jewish-Christian overlap

One of the best things about becoming Jewish is that the process has clarified for me very precisely what I love and what I dislike in Christianity.

What I love in Christianity is exactly what I love most in Judaism. Jesus distilled the most beautiful elements of Judaism and made them harmonize and inter-illuminate. He was an unsurpassed genius, and it was through him that Judaism became capable of producing modern humanity as we know and love it.

What I dislike in Christianity is where Jesus ends and Paul begins — the whole magic legalistic universe he invented and shoehorned his christized Jesus into —  which is also precisely where it betrays Judaism.

I’m not one of those boring people who rejects Paul because he was mean, harsh or misogynistic. According to most experts, relative to the standards of his time he was above average in all the virtues good liberals prize most. He may have even helped advance liberalism, and for that outcome I am grateful, even if I find his methods distasteful.

No: my problem with Paul is that his worldview is poorly conceived and designed. It’s a hacked-together mess, lacking in plausibility and usability. If Paul’s concept of God is the only one you have available, it is a miracle if that doesn’t force you into atheism. The only part that’s any good design-wise is the sliver that reinforces what Jesus tried to teach.

To summarize: Judaism and Christianity overlap in Jesus’s teachings. Judaism and Christianity diverge where Paul started inventing his own religion.

A little something to upset everyone.

Design-Centered Human

Someone asked me, with respect to my work, what I call myself these days. If people understood 1) what design is, and that 2) all design, done competently, is, necessarily human-centered design, I’d want to be called simply a Designer. Because this is nowhere near the case, I call myself a Human-Centered Designer.

At that point my friend Tim called me Design-Centered Human. That’s pretty apt.

Anomalogue Press

I’m told I’m a descendent of publishers (Scribner’s Sons). I certainly do feel book-craft in my blood. I care intensely about the best ideas being given the form they deserve, from conceptualization to language, typesetting, page composition, printing, and binding. I cannot believe that I can buy a life-changing book for less than the cost of a luxury car.

I keep fantasizing about starting a press dedicated to publishing the heirloom thoughts of great contemporary thinkers. I am imagining art chapbooks of about 24-36 pages, each containing one essay written in a rigorous, non-scholarly style for an ideal reader — intelligent, informed and critically sympathetic. The essays would not be popularizations — and in fact might be even denser and harder to read than a full book — but would be streamlined to exclude footnotes and references to other works. The point is to immortalize the thinker’s best idea in the most compact, most beautiful words in the most perfectly designed and constructed physical form possible. They would be letterpress printed, of course, on cotton paper and sewn into chapbooks.

In exchange for the content, the author would get half the copies to give to loved ones, and I would keep half to sell.

I would definitely want the first author to be Richard J. Bernstein, whose Beyond Objectivism and Relativism changed the course of my life.

The worst product management fad, ever

I’ve been pretty outspoken about the damage Lean Startup has done to design.

Mostly, I have emphasized the way such engineer-centric methods tend to encourage rushed release cycles that expose users to inconsistent user interfaces, often flawed ones. I’ve complained that an engineering mindset conceives products as things, where a design mindset thinks of products as experiences real people have using them, and that when design is controlled by people with engineering mindsets, experience becomes a thing added to the other thing engineers make.

From this engineering mindset, Lean Startup makes obvious sense. The entire process is optimized to the goal of improving the product as rapidly as possible, the product being, once again, a thing. By this logic the users become valuable means for discovering new places where the product might be improved. Instead of wasting valuable days testing prototypes in artificial scenarios that only examine parts of the experience in ways that might not represent the full context of use and doing so with very small samples of users — why not release the product to much larger samples of users using it in the wild for real purposes, and to monitor that usage so that problems that show up in these real situations can be addressed in the next release that is never far away?

To a design mindset, this is exasperatingly wrongheaded. When designers perform usability tests on a product, yes, the product is improved — but the product is improved (with the help of voluntary, paid test participants) before it is released in order to protect any real users from having bad experiences with the product. This is because — and this is key — any unexpected change, even a change for the better, forces the user out of a learned habitual mode of use into a figuring-out mode that refocuses attention on the product instead of on what the user wants to think about and do.

This is why the engineer’s objectification of “the experience” is not a semantic nit-pick, but a true distortion of meaning with big consequences. If “the experience” is a part of the product that can be improved through experimenting on real users, why not do it? But if the experience is understood as being what happens when real people use the product, the incessant improvement of the product will be seen to occur at the cost of a deteriorating experience.

What designers want is to change the experience as little as possible as infrequently as possible. This is why we work so hard to understand the people we are designing for so we can get the product as right as possible before users invest themselves in learning it and incorporating our product into their lives. “Pivots” in product purpose are extremely disruptive to users, and represent at the least a need to invest in relearning, and at worst can alienate users if the product pivots away from their needs. In products users love, pivots feel like betrayal, and in fact pivots are calculated betrayals. They should not be treated lightly. Designers concept test in order to avoid the need to betray users who have trusted a product enough to adopt it. Designers usability test for at least two reasons. The first is obvious, and seems to be the only reason understood by the engineering mindset: to remove as many flaws as possible from the experience before users are harmed by them. But there is a second reason: to avoid the need to change the user interface later, after users have invested effort in learning them. As Beatrice Warde taught us, great design is invisible, and as Martin Heidegger taught us, when a tool stops functioning as expected it goes from invisible “ready-to-hand” to distractingly conspicuous “present-at-hand”. It stops being an extension of one’s body, mind and (I’d argue, heart) and becomes an unwanted rupture in attention.

One topic I plan to cover in my upcoming book, Philosophy of Design of Philosophy, is the ethical issues revealed by all the various flavors of extended cognition, which I plan to bloat into a much larger (Haraway-ish) theory of extended self. When a user adopts a product, that user has invited that product into the user’s own being. Contrary to currently hip “Eastern” attitudes that insist that we are not our possessions, I would argue that in an important sense we are most certainly our possessions, and most of all those possessions we use every day and count on to be there when we need them, just like our hands. The trust that users show when they invest in learning a tool so well that the tool vanishes into their body, mind and will should be counted sacred — and I will argue in my book, formalized into a tool covenant.

I am am definitely rambling now, because I haven’t even gotten to my main point yet — yet another way Lean Startup has harmed our daily lives. But before I shift to this next theme, I want to try to pull together the implications of the points I have made so far.

  • If a human being’s self, to some important degree, is constituted by the things they use;
  • And if this constituted self is only whole when these used things vanish and become extensions of their bodies, minds and souls;
  • And if changes to tools break this invisibility relationship and by extension break the extended self;
  • It stands to reason that great care should be taken to change tools as infrequently as possible, as little as possible, only when necessary and only when the change is known to be more beneficial than harmful!

No, most of us don’t see things this way. Even designers don’t. Users lack the language to describe the anxiety they feel when they cannot count on tools they rely on looking or acting the same way when they pick them up to use them, nor can they justify their feelings of betrayal, indignation and violation when product managers decide to overhaul the design of their product. It is as if strangers can rearrange rooms of our homes randomly whenever they feel the whim. We cannot describe, justify or argue for what our sanity requires because we think using philosophies which do not support the thinking of thoughts that clarify our situation and equip us with language to do something to improve our lot! Our working philosophies need to be redesigned to suit this need — and many others that are causing our worst social problems.

My core idea is: We can’t agree on how to emerge from our myriad crises because the folk philosophies we use to do our thinking and persuading are not up to the task. But we can design better philosophies with tradeoffs more suited to our contemporary situation that will render confusions thinkable and give public voice to feelings that are currently isolated inside individual souls. Since I’m coining terms left and right, I’ll add another: design instrumentalism is the concept that thoughts are things we use for our own human purposes (instrumentalism) and which therefore ought to be thought of less in terms of truth vs falsehood and more in terms of better and worse designs, which means that philosophies ought to be designed, using design methods.

And now, enough digression: the second way Lean Startup is harming our lives is by stuffing design processes inside Agile processes, and in the process making it nearly impossible for designers to consider experiences holistically so that every part of an experience relates to the others in a way that makes clear intuitive sense.

Our sanity requires us to sense relationships (even if we aren’t explicitly thinking them) between all the elements of what we experience — the people, the things, the events of the past, present and future, our own purposes, etc. These relationships are how we make sense of things — or, more accurately, they are the sense we make of things. When these relationships are missing, or inconsistent, or blurry, we are unable to make sense of our experience, and we feel perplexity and anxiety, if for no other reason that something is wrong and we cannot even put our finger on where the wrongness is coming from. We don’t have words to explain, only to express our emotional reaction to the chaos.

It is the job of designers to architect these relationships — to place “inside” experiences those connections people look for in all experiences — so there are relationships there to intuit in order to make sense of things, then to give concrete shape to these relationships so they feel unfailingly real. This gives users a feeling of solid ground under their feet. Lack of solidity, coherence, consistency, reliability, endurance — I will call this condition experience volatility.

But these relationships do not emerge automatically in the process of adding features to a product (or service). They cannot necessarily be overlaid onto products as they are built out bit by bit, feature by feature (that is, by constructing atomistically). They coherence needs to be developed at the level of the whole and the part simultaneously, which means both need to be kept fluid as long as possible, which is precisely what design does as a matter of method. Jumping straight in and building and bolting, and breaking and re-bolting is a cumbersome, frustrating and wasteful way to develop holistic systems, and this is why when systems get engineered atomistically the holistic sense of the experience is normally what is sacrificed.

But there’s yet another problem! I need to research this part more, but the IA (Information Architecture) conference I attended last week heightened my awareness of how pervasive stories have become in our design processes. Agile works on the model of nested stories of increasing scale. This has the effect of imposing models of step-by-step procedures onto interactions. The way I put it, it tends “wizard” things by making them behave more like branching linear processes than like objects, or environments, or conversations which afford users more control. I am also finding that Service Design tends to do something very similar, so that the design almost automatically constructed on a timeline backbone.

Time happens to be my least favorite dimension (not to imply that I like breadth or width much better. ) Sometimes time, timelines, the elements of literature/ theater) are the right organizing structures of design, but we shouldn’t assume or or make automatic choices due to habits of method. The structures that undergird our designs should be carefully considered before being chosen.

Back in the early aughts, before UX was a thing, back when I still called myself an Information Architect, the company I worked for acquired a legendary business anthropology outfit. The department they became post-acquisition was called xMod, short for “experience modeling”. This strikes me as an excellent name for the holistic meaning-structure development activity that helps overcome experience volatility, and which again, is made impossible when building and design start at the same time and design is rushed into producing specs for engineers ASAP, lest those engineers sit idle and waste company resources, instead of doing their jobs, which is building something — anything!

So this is my argument 1) that Lean Startup has exponentially increased experience volatility since its mass adoption, 2) that experience volatility matters to our lives, because in a very real way it injects volatility into our own being by constantly breaking our extended selves, and 3) the only reason we don’t all understand this and protest it is because the folk philosophies we use to think and communicate are badly designed for our current situation, but that 4) we can and should redesign our philosophies to help us live saner, more peaceful, and happier lives.

If anyone has actually read this far: Thank you for your patience!

So many ideas. So many coinages.


The “material science” of people

My dad is a retired ceramic engineering professor. He is what many people would call “extremely left-brained”. He is the kind of guy who stays up late into the night doing math puzzles for fun. Engineering has always been a core part of his personal identity, even after he became a professor. For him teaching was a process of making new engineers. His job was to take unformed high school graduates and transform them into good engineers, capable of tackling the toughest problems with knowledge, ingenuity, tenacity and a dash of principled impishness.

Like many highly analytical people, my dad tends to view design as a mostly subjective domain, dealing with aesthetic taste and feelings, as opposed to the kind of objective problem-solving engineers do.

This misconception of design is not uncommon. It is especially prevalent in engineering-led organizations. And since designers spend much of their time collaborating with engineers this misconception has practical consequences.

So changing my dad’s view on design and its relationship to engineering seemed like an interesting challenge, and one that might even help solve some tough real-world problems.

I tried several approaches. I talked to him about theory. I explained human-centered design methods. I told him stories about projects. I tried to convey to him what I find fascinating and frustrating about design problems. None of it stuck. So, I backed up and reframed my communication challenge as a design problem. I knew if I wanted him to adopt my concept, I would have to make it intuitive, which meant connecting it to his own experiences and using as much of his vocabulary as possible. Here is what I came up with:

Back when he was teaching, some of the most important classes he taught were on material science. His students learned the properties of different kinds of ceramics under varying conditions, such as heat, pressure, stresses of various kinds, etc.), and how to apply this knowledge to solve engineering problems. Because good engineers build system out of well-understood materials with predictable characteristics.

I explained to him that designers face a similar situation, except our systems include not only physical parts, but also human participants, which we, like engineers, need to understand thoroughly in order to solve the kinds of problems designers are hired to solve. Our problems involve getting people to respond in some particular way to what we are making. Insights into how our human participants think, feel and behave in different conditions helps us develop systems that inspire the right kinds of participation in our systems. Participation might be nothing more than noticing some artifact and forming a positive impression. It might be adopting a tool and using it skillfully. Or it might be actively engaging and actually using a service.

Yes, aesthetics, taste, feelings and subjectivity are an important part of our job, but we are interested in how they coalesce into a person who will experience what we are making and respond with feelings, thoughts and actions that support the overall system we are developing. And that system is made up not only of the participants, but also non-human parts — the parts engineers build.

So, to summarize: design research is the material science of design. In material science, the goal is to understand the rules that determine behaviors of materials, so that when an engineer uses them in a system they predictably function as intended; in design research the goal is to understand the factors that influence certain types of people to feel, think and act, so if someone of that type encounters a design they will predictably respond as intended.

This seems to work well enough for its intended purpose. But unexpectedly, it started working on me as well. Since conceiving design and design research this way, the logic of the explanation has taken on a life of its own, and it has begun to change my own understanding of what design essentially is.

(To be continued.)

Discussion Salon rules

A Discussion Salon is a structured discussion designed to produce substantial conversations. It goes like this: everyone brings short passages on some theme determined ahead of time. Participants take turns reading passages, and the group converses on that theme.  Susan and I did our first one back in 2000, and we’ve been doing them sporadically since then.

Here are the rules in case you want to do one:

  • The purpose of the Salon is to generate dialogue. We want to make it possible to express ideas that cannot be expressed in normal, everyday conversation.
  • Quotes will be used to seed dialogue.
  • Please come to the Salon with one quote that is connected with the theme of the event.
  • Quotes play a central role in the Salon, but the purpose of the Salon is not sharing quotes. They are a means to stimulate dialogue. Dialogue should not be cut off or rushed in order to give everyone their turn to read. Not all quotes will be read.
  • This is an intellectual safe zone. No opinion is prohibited. The only rule is respect. If you find an idea offensive, please challenge it using reason and constrain your emotions and moral passions. Please do not self-censor out of fear of upsetting someone with your ideas. (But again — be respectful!)
  • We want to be sure people are given a chance to finish their thoughts even if the thoughts are complex. Interruptions can be vetoed by the current speaker, signaled by raising their hand.
  • Contributions to the discussion should always address the ideas of the previous speaker. Evolve the subject, don’t change the subject.
  • Dialogue should be kept thematically close to the quotes and should refer back to them explicitly whenever possible.
  • As conversation progresses and develops, new quotes can be introduced to feed the dialogue.
  • If a dialogue comes to an end, we will restart dialogue with a new quote.
  • The Salon has many modes of participation. Some participants will do more listening and others will do more speaking. Nobody should feel pressured to speak if they wish to listen, or to stay silent if they have something to say.


Next book: Philosophy of Design of Philosophy

Now that I’ve gotten Geometric Meditations into a finished state I am starting to feel a compulsion to write a more accessible book about design, tentatively titled Philosophy of Design of Philosophy. I’m excited to be freed from the excessive formal constraints that made Geometric Meditations take so long to finish.

There are several key points I want to make.

  1. Design needs to be rethought, along with its relationship with engineering. I propose re-defining design as “the intentional development of hybrid systems composed of interacting human and non-human elements.” Most importantly the human elements of the system should include the people for whom the system is intended, treated as an intrinsic part of the designed system, and interior to it — not exterior users of a system designed to be used by them. Follow this link to see a visualization comparing the “conventional” and “hybrid systems” view.
  2. We find it difficult to define design, and distinguish design from other creative activities (like art and engineering) because we think in a way that obscures the question. In particular, the way we think about making tools and using tools has gradually become inadequate for dealing with the world as it has evolved. Our working philosophies have grown obsolete, and their very obsolescence makes us look for solutions every but philosophy.
  3. Philosophies are essentially tools we use for living lives in an infinitely complex radically pluralistic reality. Every philosophy has advantages and trade-offs, meaning they make it easy, even automatic, to have some kinds of thoughts, feelings, perceptions and responses, and nearly impossible to think, feel, perceive and respond in other ways — and these other ways might be the key to confronting what are perceived, conceived and felt to be insoluble problems. Designers will recognize in this description characteristics common to all design problems, and that is my intention. The design field has developed effective techniques for dealing with problems of this kind. I propose we approach philosophy as design problems, using design methodologies to interrogate problematic situations we face to uncover and frame the most fruitful problems, to develop holistic approaches to thinking them that permit solutions to these problems, to iteratively experiment with and improve our practical thinking. I call this understanding and approach to philosophy “design instrumentalism”. We need to design philosophies that help us design better lives for ourselves, and this book will hopefully contribute to this project.
  4. Part of the reason we need to take design much more seriously is that who we are is changed by what we design. Indirectly, when we design things we use, we design ourselves. And this is because human being is extended being. To be a human being means to have one’s own being stream out into the world in every direction. Despite what spiritual conventional wisdom tells us, in some very important ways we are our possessions, we belong to where we live and we are our egos. But what we are can be released, transformed, improved or degraded based on what we do with ourselves: our environments, our physical tools, our conceptual/mental tools, our life practices, etc. This part of the book draws on extended cognition, cyborg theory, ANT, postphenomenology crossbred with existentialism, but I plan to be atrociously unscholarly, synthetic and magisterial in my approach and keep external references to a minimum. The goal here is to reframe human existence in a way that liberates us from the subject-object and self-other dichotomies that dominate the working philosophies that unconsciously shape our conscious thoughts. (The pre-conscious “how” of our thinking produces the “what” of our thoughts. I may have to also take some potshots at pop-psychologism that views the unconscious as sneaky little mind forces that lurk about behind the scenes motivating us this way or biasing us that way. Where most folks see secularized demons, I see poorly designed conceptual systems, a.k.a. philosophies.)
  5. The process of being human is a nonlinear (iterative feedback) process of co-evolution. As we change the world, the world changes us. This process has brought us to a perilous point where we must choose our next step very carefully.

This is an early sketch, but I think some of the ideas are interesting and consequential, and I think it will be fun to right. And my design approach will ensure that at least some people will find the book useful, usable and desirable.

Polycentric design

Design is the development of 1) systems where the definition of the problem includes elements who are people with some degree of autonomy, and 2) where the production and/or delivery of the designed system involves engineered sub-systems (that is systems that do not include autonomous personal components).

In other words, designed systems are nested systems made up of interacting human and non-human elements (“hybrid systems” as Actor-Network Theory calls them)), and some of the nonhuman elements become engineered systems (ideally explicitly framed as engineering problems).

The idea of design as a system that includes its users as internal to the system is not unprecedented (to name a few Cybernetics, Soft Systems Methodology, and traditional usability engineering have all folded users into their systems) — but it is not widespread among designers, who still tend to view what they make as for people who remain essentially separate from what they are designing.

To sharpen this definition of design it might be useful to define some other design-related activities.

The most important contrast is engineering, which, again, is the development of systems where all elements of the problem are non-autonomous, and predictably follow rules. Autonomous persons are excluded from (defined out of) engineering problems.

Some engineering does involve people but prescribes the rules of their behavior so that they become predictable components of the engineered system. This can be called social engineering. People are controlled and made non-autonomous in social engineering problems.

Naive design is design where the people involved in the designed system are assumed to be as the designer imagines them. In other words, in the course of the design work their goals, behaviors, values, perceptions, conceptions, etc. are not investigated. People are largely imagined in naive design problems.

Human-centered design is design where the people for whom the design is intended (the user, the customer, the audience, etc.) is included within the design problem as substantially unknown. Their personal autonomy requires active investigation, otherwise a critical component of the design’s success is being left to uninformed speculation. To avoid this risk, in human-centered design, the people for whom the design is intended are methodically involved throughout the design process.

As the implications of broader definitions of design come to light, more and more initiatives of various kinds are being recognized as design problems, and are being approached with the sensibilities, methods and tools of design. This has evolved at least one new species of human-centered design, which can be called polycentric design.

Polycentric design is design where multiple interacting people within the designed system are included within the design problem, including not only the primary person for whom the design is intended (user, customer, etc.), but other people involved in the system — ideally all the people who participate in the designed system. Understanding the complexity of such multi-actor interactive systems, and treating each actor as an autonomous person encountering the system from their own lifeworld requires more than a shift of concern — it requires new methods and tools.

Currently, the predominant polycentric design discipline is service design. Of course, services frequently feature multiple actors, and the quality of service depends heavily on the mindset of people delivering it, so it is unsurprising that polycentric design methods are developing in the design of services. But, unless we want to define the word “service” very broadly, the approaches used in service design can be used to design any system where humans are interacting with one another within a hybrid system. To name a few obvious examples, the design of organizations, of public spaces and of online communities could benefit from a polycentric design approach that might differ in important ways from service design.