Andy Matuschak writes that Effective system design requires insights drawn from serious contexts of use and that Tool-makers usually lack connection to a serious context of use (see also matuschakHowCanWe2019). Serious contexts of use act as a forcing function when building new systems, preventing you from over optimizing any specific component and making sure the person using the system is actually bought in to improving the system.
But what is a serious context of use?
As far as I can tell, the defining characteristic is that a serious context of use is a use-case embedded in a context that the person using the system takes seriously. That feels quite tautological, so let’s unpack it:
“A use-case embedded in a context” is rather clunky, but just “use-case” is insufficient because use-cases can easily become separated from their contexts and building for a context-free use-case can be almost worthless. (Remember the primary use of a serious context of use is for systems and tool building.) For example, say you were building a hobbyist-grade 3D printer, and a use-case you were focusing on was printing gaming miniatures. The hobbyist isn’t just a gaming miniature printing maniac, though. They likely want to print other things, they have time, budget and other constraints. They want to then use those miniatures. They perhaps need to be able to easily get and customize designs. If you don’t take this broader context into account you could end up making an incredible miniature-making tool that the hobbyist finds completely worthless.
In traditional engineering, this context is often distilled down to a finite list of requirements. The requirements approach works if you understand the system very well (and thus know which parts of the context matter and which don’t) or the context is incredibly constrained. However, for tools that are a part of someone’s workflow (which many tools are) this is rarely the case and it’s impossible to capture all the important parts of a context in a set of requirements.
The person using the system needs to take the use-case seriously. The trick is that there are many things that people do that they don’t take seriously, and many things that would not be considered “useful” from the outside that people take very seriously. People take things seriously if there is consequence to failure. The need for consequences may be why most pure note-taking tools are terrible: almost nobody experiences consequences for taking bad or no notes. At the same time, people often take things that aren’t objectively “useful” very seriously. Most hobbies fall into this category. Is fly fishing useful to anyone? You could do some mental contortions to say “well it’s relaxing which then allows the person to be more productive …” but the reality is that they take it seriously for reasons other than its usefulness.
It’s important to realize that A serious context of use does not need to be useful. Usefulness is something that can be justified to an outside observer. Trying to target being useful from day one is a trap that many technologists fall into when trying to set technological goals. Asking “what applications is it useful for?” Of a new system is disingenuous because Systems must take performance hits to get out of local optima so it’s very hard for new systems to be globally useful. Additionally, systems often create their own best applications. Instead, the trick is to find a serious context of use that is within reach, regardless of how “useful” it is. Often it is only by doing the systems research to strive for a useless serious context that the useful applications can be discovered.
To some extent, a serious context of use prevents “cheating”