The app, an Object, allows the user (Agent) to navigate a specific Environment. What some might consider a problem space. The Environment is both map and territory.
The narratives (sometimes abstracted into interfaces) that the creators use to guide the Agent through the Environment are almost always in monotone. A new theory of design would benefit from the creation of new narratives, ones that can be blended, spliced, overlaid and explored from multiple perspectives.
Designing a multi-faceted narrative to navigate these Environments would reveal and thus confirm the underlying systematic foundation inherent to this (and all) technology.
It would acknowledge the rhizomatic pathways that hijack imposed attempts at linear path-making (and path-taking).
And it would encourage an orientation towards the design of flexible boundary spaces, filled with Emptiness (per Kenya Hara) within which we can encourage the emergence of Agent defined paths, that deemphasize the pre-defined and pre-designed paths formed the creators.
A product that needs to be consciously used every single day is a fragile one.
Fragility is not inherently bad, but it forms a weak foundation. The impetus for immoral behavior emerges when this foundation supports a system that values attention quantitatively.
This is where we find ourselves today. In the land of Google's "toothbrush test" and an entire industry tragically named "growth hacking".
There is a wonderful grace to a product that can not only exist - but function without our input. Creating a product of this calibre is far, far harder, than a product that demands daily deference.
A product may operate on several timescales, depending upon its features and ambition. While it may operate perpetually, it may only engage with you, personally, every month, or year.
This difference between operation and engagement is an important distinction. A lot of products operate perpetually...but they don't have to brag to us about it with a litany of low-value notifications.
When considering the timescales your product operates across, there's also value to observing the timescales your team operates across.
Do the timescales match? Are you "moving fast and breaking things?" with a twice-daily release schedule? Is freneticism the best form of activity?
What might you build and release upon the world, if you had a single month and then no opportunity to update or add to it?
How can you establish a product development system that doesn't need to keep developing? You could interpret this concept many ways: as a product that is self-improving, a product that is so simple & focused it doesn't need updating, or that the product stretches across to the people using it, who keep it maintained out of their own self-interest.
A product team is designed to build, not to maintain, so build it will, even if it's unnecessary - or even excessive.
Types of Timescales
- Access (how many times the product is accessed / opened)
- Engagement (the quantity of time invested)
- Value (the quality of the engaged time, calculated based on the time required to achieve the individuals desired outcome).
- Operation (the time the product spends operating for the user, either in the foreground or background)
- Disconnection (the time it takes to stop using the product and get to a neutral contextual foundation - factors into Residual Forms)
What timescale(s) does your product operate on? How often does it engage?