An *object* lesson
How realising the subject and object are the same can help us design and build better!
In my last post I waged an unforgiving, brutal war on the subject-object divide. I apologise for the carnage. I do hope you have recovered.
This divide, for those who don’t know or perhaps couldn’t get through my last post (😭), is a conceptual framework for approaching the world. It is similar and oft-synonomous to the mind-body divide, also known as Cartesianism. As I noted, this conception structures our thought such that we conceive of our consciousness as untouched by physical world; we are viewed as abstract entities who are able to rationally evaluate the world of objects (but these objects in turn do not affect us). Objects are conceptualised as inert - they can be dislocated from their context without effect.
So, in contrast to the subject-divide, I suggested that objects exist with us and our cognition in complicated ways, such that they:
change our goals
shape what we do
can literally be our thoughts
Yet I ended my argument with a question, and the promise of an answer: why and how does rejecting this divide matter for design and technology?
Well, because:
Considering how we think with things helps us understand how digital tools constrain and enable certain types of thinking
How would you map out a new service, or product? How would you map out anything ambiguous, with unknowns? Would you use a spreadsheet? Probably not - but perhaps you wouldn’t think through precisely why.
You might just think that spreadsheets ‘feel too rigid’.
So, instead you might use something like Miro, Balsamic, or just a plain paint tool, which can:
allow for easy dragging and dropping of different entities
show entities existing in a spatial relation to one another
create overlapping groups of entities
You implicitly realise that spreadsheets don’t do this. Instead, spreadsheets encourage rigidity. They ask for discrete categories, not ambiguity. They also demand hierarchies. They have intrinsic left-to-right and top-to the-bottom organizing principles.
On the other hand, if you wanted to create a list of a bunch of entities, with different properties that can be sorted and filtered, you would instinctually very likely use a spreadsheet.
Now, I know a lot of us know this. But we rarely focus on how the (digital) material that we use constrains or enables our thoughts. And, as I was at pains to point out in my last post, we think via our actions and via things. Spreadsheets will make you think hierarchically, in discrete categories.
We tend to default to our most used tool (and existing templates within those tools) for just about any of our goals. But the tools and formats we use are perhaps as important as what we use those tools for.
The main lesson here is to consider the tool - don’t resort to the first tool at hand. I wrote about this at length a couple of years ago, referencing Heidegger, Agile and all sorts of fun stuff.
One of the great things about startups is that the absence of existing structures means that tools aren’t embedded in ways of working, and thus staff aren’t required to use these tools as a matter of course. It’s often the case that there is space to find and determine the most effective tool for the job. Startups often use other startups’ products, quickly pivoting to the most effective tool rather than being stuck with legacy systems.
This isn’t just about effectiveness, but rather disassembling and disavowing ossified ways of thinking and allowing digital tools to facilitate alternative methods of thought and creativity. This is why I always suggest to avoiding default tools - it’s easy to do, but it’s often ineffective, especially if your profession requires any aspect of creativity.
A useful method to force yourself to reflect on what tool to use is via a simple formula:
Often tools are the among the first thing dealt with when starting a task - yet in a unthinking way. But it’s only after considering the outcomes you want, and considering how you want to get there, should you consider the tool that should be used.
As an example, say I wanted to design a feature for a learning management system - something like Udemy. I might ask: what are the outcomes we want? A new feature that drives learning goals? An understanding of our users’ needs?
Obviously there are many other questions I would ask myself if I wanted to achieve these outcomes, but for the purposes of deciding what tool to use, the subsequent questions should first deal with the how we get there.
For example, we might want to undertake design explorations to get the outcomes we need. Or perhaps we need to conduct design research. Or rank some key of priorities. Each of these will speak to different conceptual aspects such as levels of granularity, creativity, and the structure and layout of the ‘things’ - the artifacts - we are creating.
Following this, I would want to ask myself about the conditions that the how will take place within, such as whether there are a lot of unknowns, whether there are a lot of perspectives, or whether we are expecting to work on a short term or a longer term project. Conditions speak to things like access, depth and breadth.
Depending on the how and its conditions we can then select the most effective tools to help us think most effectively for the situation. Our thought will inherently be structured in a way to facilitate the outcomes we want.
As an example, say the outcome we chose was a quiz feature for Udemy with the goal of enhancing users’ learning goals. We might realise we want to consider how a quiz could unfold and draw spatial connections to represent the unfolding of the different routes. The conditions might involve stakeholders who want to access it to contribute, but have low technical knowledge. We might decide on something like Google Draw, which gives easy access for many users to think in terms of spatial connections, routes, and ways things can ‘unfold’.
Of course, there is a kind of friction when a new tool is introduced to someone who isn’t used to it. I want to suggest that this happens not just because they don’t know how to use it, but because new tools are akin to messing with their thoughts. These tools, externalised cognitives structures that they are, don’t always nicely align with internal cognitives structures - at least in the first instance.
Thinking in new ways can be uncomfortable. Flexing new cognitives structures is challenging. When we realise that’s because our thoughts are woven into the materials, it’s much easier to address the challenges in picking up new tools.
What does the tool want from us? How will it change us? In my last post I discussed how objects change our goals. Designed artifacts do not just allow us to achieve goals, but also co-create goals. Which brings me to my next point:
Digital tools must help us reflect on the goals they co-create
Some time ago, I was working with a large agency as a nominated ‘expert’ on human-centred systems to help fight disinformation on social media as part of a project to improve media literacy for the UK government. We were testing different ‘interventions’ that could help users identify disinformation on social media posts. We included interventions like misinformation labels and a feature that reminded of your values when you encountered potential misinformation.
It was an interesting project, with a lot of interventions that didn’t work and a few that worked quite well. One of the interventions worked very well - people correctly identified posts filled with misinformation. However, this also resulted in people engaging less with non-misinformation posts; in other words, engagement in social media dropped overall.
We had successfully got people to reflect on their consumption, reflect on how they engage with information, and on why they are doing what they are doing. But in their more informed state, they decided that they didn’t want to engage with social media as much generally.
We completed this report and passed in on to the government.
Then: silence.
We expected regulation, or some kind of further action from the government. Yet we heard nothing. It was only recently I found that our report was squashed by a MP. Apparently he had connections to the tech world.
The lesson: when people reflected on what they were doing, how they were spending their time, they often disengage with tech. And the tech world does not want this.
We think that tools are about allowing people to create goals, but they are a part of a system that is a co-constitutive act of goal creation, between the designers/developers, the business, the end-user and all of their relative contexts. Again, refer to Latour - who I spoke about in my last article - to learn more about this.
Helping a user to reflect on goals they co-create with the technology they use is vital - it engenders awareness, self-control and self-sovereignty. Thus, creating technology that helps do this is a necessary responsibility to allow autonomy to flourish. And it’s one that businesses often push back on.
Too often, businesses demand that users want things - they want user to want something and get aggravated when this manufactured desire doesn’t take root. This aggravation is perhaps warranted - they have created a business on manufacturing these goals within people and they know they will fail when these goals don’t materialise. When the goals that technologies want people to have are the same that they actually have is where we see technology being effective (though if people ‘want’ unethical things, then….).
The Vice President of the ‘metaverse’ at Meta wrote an internal, hand-wringing memo about the decline in numbers of people at Meta itself using the metaverse software.
“The simple truth is, if we don’t love it, how can we expect our users to love it?”
He then went on to say he would “hold managers accountable” for having their teams “use Horizon at least once a week,” according to the Verge. This co-creation of new goals isn’t always a co-creation. It is sometimes one-sided - demanding.
What kind of software demands that you use it, then orders you to desire the goals it wants you to desire? Do I want to want to have a house in the Metaverse?
But at least, in this instance, it is highly visible how our needs are being structured. It is apparent, and it is unsavory, due to the very obvious lack of utility and joy found in the metaverse. This is a very visible and aggravating (attempt) at restructuring desire and the consequent goals.
Generally, desire is structured by the conditions we are in. Knowing what we actually want is an impossibly recursive exercise that always looks to regress to a previous step to find the conditions that caused the successive step. I want what I want because of my childhood, but my childhood was shaped by advertisers, who were shaped by capitalism, which was shaped by historical forces, etc etc.
But this doesn’t mean we can’t reflect on the nature of how are goals came about and why we want them. This, however, often needs active facilitation. Allowing a person to reflect on the nature of their goal creation is vital. Why the hell do I want to get an Uber? Why do I want a “Like”? Why do I want to host a goddamn legless meeting in the metaverse with my colleagues? Do I want this, really? Help me think about this.
By manifesting representations of these competing goals and how these goals are formed, designers can help people consider how their goals are being constituted. This is a difficult game, because as Lewis Mumford said, a technological system needs is to entrench its own power - and entrenching its own power is often hiding what you want the user to do. But a truly human-centred, ecologically centred system must be attentive to to ensuring that the business’ goals and the user’s goals become the same not because the business wants it to be that way, but because the user is aware of this goal creation, and sanctions it.
Awareness of the genesis of your creation is the first step to changing who you are, and taking ownership of your being.
I am reminded of OKRs - Objective and Key Results, a way to measure team’s trajectory toward particular goals. They are often used poorly by businesses; as a way to drive action. But they are fascinating, because for software designers and developers, they articulate the goals of the business and the software it’s creating. Rather than leaving goals implicit, they drive home that they want people, both staff and ‘users’ to do something. This manifestation of the goal(s) should be standard in software - what are we (the technology and you) trying to do, and is the crossover betweens us sufficiently acceptable and useful?
Certainly it can be difficult to know even what businesses want - but this brings me to my next point, why you should always:
Get people to articulate ideas as objects
There is a romantic notion that ideas are received almost as kind of blessing, fully formed and perfect, as though from another realm. Yet ideas are often more vague than they are perfect. It’s easy for ideas to be perfect when they are vague because it’s difficult to point out flaws in them as detail is lacking and can easily be glossed over.
But when we are forced to make our ideas tangible, we are required to commit our ideas to certain boundaries, adjust to certain constraints, and reflect on their now defined, bounded state.
Ideas, in other words don’t exist until they interact with the world. Indeed, rather than ideas, we generally have something more akin to intents - vague, precognitive, amorphous gestures toward the world. Through enacting these intents, ideas are formed.
This isn’t anything new - something emanating from digital technology - rather this is how we have evolved.
In the field of cognitive archaeology, studies of tool making has shown a reliance on perceptual-motor and grasp systems, and the dorsal intraparietal sulcus anterior but not the pre-frontal cortex.
I know you know exactly what that means, but I’ll explain anyway. Early stone age technology seemed to rely on action planning and affordance perception rather than abstract planning.
What this means is that how ancient hominids created wasn’t through abstract thought. Instead, they acted, observed the results of their actions, and then acted again, based on the perception of new types of actions that were available to them. They hit a rock with another rock, witnessed how the rock changed, then hit that rock further to accentuate the change. This is called ‘knapping’ and is how most tools were made in prehistoric times.
They didn’t have ideas, per se. They build up a sort ‘gestalt apparatus’ that facilitated creation. The entire system of creation - the rock and the sequence of actions that will lead to it - was in essence, an idea they had. Their physical creation wasn’t a representation of an idea they had, rather it was a result of the actions they took, based on the available affordances, and subsequent actions available to them based on affordances newly created by their actions.
We, now, are much the same. In fact, it’s far more extreme with the kinds of complicated ideas we have. We cannot predict the way our ideas will interact with the world with any certainty. Far better is to enact and observe - the idea is co-created with the world. In the act of applying one’s attention to the world, the world itself changes - reality collides with our intention in ways that are scarcely predictable, but are highly informative. Our ideas are through their enaction. You can go so far as to say that there is no separation between an idea and its emergence in the world. This isn’t to say that we don’t have ideas and then try to make them a reality, but the point is that ideas are not in our heads, they are more broad intentions, their manifestation is equivalent to their application unto the world: this is an idea.
A sentence is a perfect example. Most sentences you come up with are written or said by virtue of the ‘feel’ of how previous words or sentence ‘felt’, and the response to it. Even if you think of the exact words to a sentence you are about to say before you begin speaking, you are essentially speaking the words in your mind - and even then, they may change based on how it feels, how it sounds, as you say it in your mind, and later, as you say it with mouth. You can’t come up with a sentence without ‘saying it', any more than you can come up with a thought without thinking it, or an idea without it being realised in some form.
The reason I harp on about this is because it is utterly vital to get ideas down is some form: sketches, sentences, paper mache - whatever. When ideas take a form - any form - they generate detail, constraint, opportunity - all sorts of further information, which is fed back to us to allow for further refinement. Indeed, the greater variety of mediums used, the more informative the tangible feedback will be.
You’ve probably worked with senior stakeholders who have vague ideas, yet they don’t understand how or why these ideas can’t or don’t have traction in the real world. This is a reflection of them not realising that their ideas are co-consitutive, between you, them, and their enaction. However, often, their ideas are perfect in their heads, because they are vague and they don’t encounter the multitude of constraints and challenges.
I have to say: it always boggles my mind how, when people are talking about ideas, design, or planning, they usually don’t draw, write sketch - whatever. Not only is this single-dimensional, it severely restricts your capacity to think about and with your ideas.
Get people to write down their ideas. Get them to commit, to realise the challenges and opportunities inherent in their ideas.
And remember, as much as objects are part of another person’s ideas, you are too. But that’s a whole other topic…
See you next time.