From tools to environments
Software has evolved beyond just being a tool. It is time to question the most popular software analogy and find a better one.
We often talk about software as being a tool. I think this is a somewhat outdated analogy. In today’s world of interactive applications running on everything from classic personal computers to even more personal mobile phones, watches, and mixed reality headsets, software is no longer merely a tool we get out and use for a specific task, it has grown into an environment we live in.
That means building software is no longer just about inventing new and better tools, it now also involves the shaping of our environments. If we keep thinking of software as just tools, we contribute to our modal confusion and prioritize the wrong things in their design.
Sure, certain aspects of software are still tool-like and best described with that term. For instance, most of the things in Photoshop’s aptly named tool palette can be thought of as tools. They extend your hand’s reach into Photoshop’s canvas and enable you to manipulate the virtual canvas with more or less direct interaction and more or less real-time feedback. That can be seen as analogous to wielding a hammer — the prototypical tool and the mother of all tool analogies — to hit a nail. But Photoshop is a whole workshop filled with different tools, and a virtual space to work in — a stateful environment you change and shape as you wield your virtual tools to manipulate virtual images.
To have or to be?
If you have read along for a while, you can hopefully see a familiar pattern shine through here once again.
Tools are things we control, and we use them to manipulate other things in our environment. Tools are supposed to manipulate well defined categories of things, like hammers which are for “manipulating” nails. And they have well categorized — and deeply cognitively “understood” — functions or usage patterns that make them effective as tools and us more effective in manipulating things. This is categorical having mode thinking all over again: A certain category of tool is for a certain category of action to achieve a certain category of result. Obviously, if you think of something as a tool, one of the most reasonable and arguably important questions to ask about it is: What is it for?
Environments on the other hand, are places we inhabit. We may still feel the urge to control these environments and manipulate them to fit our needs, which sounds a lot like what we software people usually appreciate about them. We’re just so fixated on the having mode, aren’t we?
But environments are also something we “just” live in. Perhaps temporary, but we are on a trajectory to spend more and more time living in software environments for longer periods of time. And it doesn’t matter whether we put goggles on to do so or not; a small screen that fits into your pocket with some portal to social media has been shockingly effective to immerse ourselves in different worlds absent from our physical reality for more than a decade now — for better or for worse.
Inhabiting an environment makes us susceptible to what happens to us while we are in it. Nowhere is that more apparent than with social media. You can see how social media clearly does much more than just provide us with tools to connect and communicate. The environment we inhabit when we scroll through our timelines and swipe through infinite images and video clips and tap little stars and hearts impacts us, influences us, changes us. At the same time we ourselves also change the environment in direct and indirect ways. And all of that is governed by an all-knowing higher-order entity commonly known as “The Algorithm”, which few of us are initiated to fully understand, while the rest of us have to live in awe and wonder and sometimes horror about how it can know the things it knows.
A poor environment offers little agency. We constantly stumble across limitations and experience friction. We are confused agents in an arena sparse of useful affordances. To get anything done, we need to learn its ways of doing things, working around the lack of affordances, because it has no interest in learning from us how we wish to do things.
In the worst case scenario a poor environment has been designed to tap into our deepest cognitive functions to exploit our weaknesses and manipulate us into certain behaviors, like constantly supplying us with things we haven’t seen before but find so attractive that we can’t stop scrolling until we realize that we yet again wasted another hour for… yeah… for what exactly? If we are so concerned about what something is for, how come we are so easily distracted from it?
A good environment gives us agency. It empowers us to explore, discover, change, and shape it. It will support our agency, and the more agency we have in this place, the more comfortable we feel there, the more we feel that we belong here. As we discover its preferred ways of doing things, it will also graciously adapt to our preferred ways of doing things. But if we want to or not, even a good environment will have an impact on us. We are in a feedback loop of reciprocal realization with it, whether we are aware of it or not, and whether we want to be or not. We are in a fairly close being mode relationship with it.
Minimum livable environment
Realizing our being mode relationship with the environment means that we can transcend from simply analyzing use cases for tools to define how we control and manipulate things with them to paying attention to how our agency in this environment makes us feel living here:
What do we enjoy?
What would we like to adjust?
What is broken and needs to be repaired?
What surprises us about it?
What makes us uncomfortable?
A consequence of this for a product design process is a requirement to create a livable environment as soon as possible. I need to be able to live in it, before I can make good judgements about how I want to change it to improve my experience of being here. And I have to be there to experience it. No planning process can deliver even a fraction of the depth and fidelity of experiencing reality yourself, here and now.
This is not the same as advocating for a minimum viable product! That is usually driven by a hypothesis to test product-market fit, where user experience is at best considered as one of many factors, at worst ignored as something too wonky and expensive to test that early in the development process. Compromises are made to identify customers who are willing to accept sub-par experience to use the product, as they are a valuable indicator that an addressable market exists.
Notice the results-oriented goal-driven having mode attitude at work here: If it’s so painful to use, but people still use it anyway, we know that they want to do what it is for so badly that we must be onto something — we identified a job to be done, a category of result our tool delivers a promising category of action for.
That thinking is not wrong. In fact it is undeniably effective, but it will only ever get you to validate ideas you came up with and designed into the prototype in the first place. Because it’s uncomfortable to live in the environment you built, chances of people showing you what they would like even more, offering you their own ideas, eventually causing you to pivot, are severely diminished. The chances are not zero, it still happens, sometimes, and when it does it’s almost always surprising. Because instead of embracing these insights, shaping an environment to encourage them, your process frames them as failures, and what is necessary to encourage them as wasteful.
I don’t think it is a coincidence that building software for yourself usually yields better outcomes. In the classic results-oriented having mode perspective we tend to explain this through:
familiarity with the domain,
awareness of alternative but inferior approaches,
knowledge and understanding of mechanisms and use cases, and
clearly-defined goals and well-chosen priorities.
Consequentially, if you only see through the lens of the having mode, finding good solutions to problems requires you to build up domain knowledge, or extract it from those who already have it.
Looking at this through a process-oriented being mode lens, however, gives us a different way to explain this: Building software for ourselves means we want to live in it as soon as we can, and we will probably make exactly that happen relatively quickly. And once we have done that, we immediately sense everything that’s clearly wrong or subtly not quite right, because it doesn’t feel good. And because we care about what we use ourselves, we put at least some effort into making it feel good.
Living = to have and to be
That doesn’t mean that domain knowledge isn’t useful — and this is where arguments like this are often misinterpreted. This is not an argument against domain knowledge, it is an argument for acknowledging its amplified relevance in the context of experience.
Similar to how music theory can be useful domain knowledge for creating music. Yet, some of the most influential musicians with songs that deeply touched large audiences claim that they don’t know much about music theory. Instead they “just did what sounded right”. Meanwhile, many people spent years learning music theory, but never manage to write a song that makes them or others feel anything.
Domain knowledge alone is not enough. It is domain knowledge married to great experience that yields us the result that makes our heart sing.
We can of course measure, analyze, and operationalize insights from our experience back into having mode patterns, which is for instance what focus groups and user research do. Everything gets translated and recorded into propositions and we lose most of the insightful feeling stuff along the way (which is of course something you’ll have to disagree with, if your world view requires that everything can be expressed as propositions, because there is only propositional knowledge).
However, if you are living in your own environment, paying close attention to how it feels, you can attempt to improve that experience directly — and you can do it using both analysis and intuition! If you are proficient in using both, you can get the best of both worlds, combined. It’s not an argument against analysis, it’s an argument for acknowledging its amplified relevance in the context of intuition.
Guided by experience of the whole
This is exactly what Christopher Alexander proposes in The Nature of Order, book 2, The process of creating life, chapter 14, Deep feeling [highlights mine]:
Our current modes of perception are not always tuned to seeing wholeness in the world around us; and the exact definition of the structure of wholeness — the system of centers at all scales, with their attendant degrees of life and coherence — is cumbersome and hard to grasp when we try to grasp it by analytical means.
The living process can therefore be steered, kept on course towards the authentic whole, when the builder consistently uses the emerging feeling of the whole as the origin of his insight, as the guiding light at the end of the tunnel by which he steers. I am suggesting that if the builder, at each step of a living process, takes that step which contributes most to the feeling coming from the work, always chooses that which has the more profound feeling, then this is tantamount — equivalent — to a natural process in which the step-wise forward-moving action is always governed by the whole.
Roughly this, I am almost certain, is what traditional builders did. They paid attention to the feeling of the emerging structure: and thus were able to stay within the guidelines of the existing and transforming whole. Guided by feeling, they were able to function almost like nature: They were able to make each small step count in the emergence of a new unfolding whole.
For us, in our era, it is not so easy. The word “feeling” has been contaminated. It is confused with emotions — with feelings (in the plural) such as wonder, sadness, anger — which confuse rather than help because they make us ask ourselves, which kind of feeling should I follow? The feeling I am talking about is unitary. It is feeling in the singular, which comes from the whole. It arises in us, but it originates in the wholeness which is actually there. The process of respecting and extending and creating the whole, and the process of using feeling, are one and the same. Real feeling, true feeling, is the experience of the whole.
Being guided by the whole, and being guided by feeling, are therefore nearly synonymous. What I call feeling is the mode of perception and awareness which arises when a person pays attention to the whole. When people pay attention to the whole, they are experiencing feeling.
It may seem far-fetched to suggest that all questions of city planning, engineering, transportation — not to speak of building — should be decided by feeling, by the feeling of the whole. But that is, indeed, what I am proposing. It is an intelligent and practical way forward.
Justifying intuition
Using experience and intuition, however, leads to these strange design decisions that are hard to defend analytically — not just to others, often even to yourself. You just know that it’s the right thing to do, because it obviously is better to do it that way. But you may not know why it does. And so you can’t explain it.
Unfortunately, this is often what we have to do. That this process is scientifically based on your subconscious picking up on patterns and fueling your implicit learning doesn’t really help you convincing others who haven’t experienced it themselves. Keep that in mind when you read product reviews by people who base their opinions exclusively on other people’s reported — analytically-processed and “propositionalized” — experience, and have never experienced it themselves.
If your design process demands analytic proof, you’re screwed. Of course, not every intuition leads to a deeply insightful design decision. In fact most of them likely do not. However, a process that categorically disallows intuition-based decisions will filter all such insights out up front, leaving you with just what can be analytically inferred and is justifiable through propositions.
Interestingly, we all know this, deeply. This is not a revelation. Have you ever needed to come up with some clever justification for something that was obviously the right thing to do, just because the process demanded that you are able to argue for it? We end up in situations like that all the time, and then we waste our time inventing stories and arguments to retroactively justify something that deep inside ourselves we just know is right. All hail S2 processing to protect us from the foolishness of our S1 intuition!
Many of us have become so numb to the constant disappointment and frustration that we have built powerful coping mechanisms that we no longer realize it. We have successfully unlearned to respect our intuition.
But it’s still there for you to recognize.
All you need to do is pay attention.
Mirror of the Self is a fortnightly newsletter series investigating the connection between creators and their creations, trying to understand the process of crafting beautiful objects, products, and art.
Using recent works of cognitive scientist John Vervaeke and design theorist Christopher Alexander, we embark on a journey to find out what enables us to create meaningful things that inspire awe and wonder in the people that know, use, and love them.
If you are new to this series, start here: 01 • A secular definition of sacredness.
Overview and synopsis of articles 01-13: Previously… — A Recap.
Overview and synopsis of articles 14-26: Previously… — recap #2.
Another great way to start is my recent presentation Finding Meaning in The Nature of Order.