We talk a lot about caching in the web-development ecosystem and that attention is usually well-warranted. Caching is a neat idea that helps our apps behave quicker in most situations (when well tuned). View fragment caching, database query caching, class variable memoizing, E-tagging, etc — these are all neat forms and implementations of the caching premise:
In computing, a cache is a hardware or software component that stores data so that future requests for that data can be served faster
Caching is just storing a copy of some data somewhere that’s faster to access than the original source. So what is human caching? And why is it the best caching strategy for any web app?
Human caching is simply the moment when one of your users doesn’t need to open your app because they remember the piece of information they were seeking. The data is cached in the mind 🧠. Performance wise, it’s unbeaten. Even a 50 millisecond request can’t beat the speed of neurons 😉
I know… this might not sound novel or groundbreaking, and this is a half-way gag post, but there’s actually some deeper insight and value to be had here. The human cache concept may actually be an analogue for how satisfied your users are with your application.
When the human cache has a hit, it means you’ve done a good enough job at delivering your key value proposition to your user that they’ve remembered it. When the human cache misses (they had to open your app again), it means that you didn’t previously deliver what they wanted in a way that was memorable. Giving users what they want is why they pay us money!
Let me give you an example. Which of these two screens do you think you’ll remember some information from in 10 minutes?
I know that’s a contrived example, but when the information is conveyed in pure simplicity, it seems much easier to remember. I’d bet you’ll still be able to recall the specific ‘available’ amount ($422) even hours after reading this article thanks to the simplistic design on the left.
The key takeaway with this concept is intuitive but we forget about it all too often as developers — most of us want to see all of the data, all of the time. Even here at Judoscale, we love data. When it comes to scaling and queue time, we give you all the data we can. But the reality is: it’s easier to remember less.
So I posit this question: what if the maximum value we can deliver to our users is the minimum amount of data required to convey the message, delivered in a format that’s uniquely memorable in their minds? This requires careful planning, a pragmatic mind, user feedback, and creativity. But it has the best payoffs.
And you know the feeling. We’ve all used apps before that we love and rave about. So often the key features of these apps is a sense of lasting value; the realization that you’ve actually retained insights from the use of the app.
When our team considers new features or new UI components, we try to bring a healthy dose of pragmatism to the table. Shiny things are neat, but they can degrade the simple-value-delivery mechanism. Questions like these help us hone our focus on the impact to the human cache (directly or indirectly):
Are developers coming to our app to keep up with their queue time, or only checking things when something goes wrong?
When a team wants Slack alerts, what exactly are they wanting to be alerted about?
How do we pursue marketing that conveys our purpose while not being forceful?
The questions tend to boil down to, “How do we deliver what the users want in a way that’s effective and memorable?” Or maybe, how do we prime the human cache best?
Oh, it’s worth mentioning too, the human cache concept is a total pivot from user-analytics-driven strategy. It goes without saying, but a human cache HIT yields zero user analytics data. Going further, embracing the human cache paradigm changes the perspective on the user-analytics data you do get. That data now represents the areas you should focus on distilling down! You’re essentially optimizing for users to not need to hit your app. The analytics you see are actually cache misses.