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, the primary 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.