Grass, Omelettes, and Just In Time Complexity
I have spent a strange amount of time thinking about lawn mowers. Growing up on a farm in Maryland, I can still remember the feeling of dread waking up on a Sunday morning to see my dad lugging mulch up the driveway. For those not familiar, this is the international sign for “summer is here and it’s time for you to spend 3.5 hours mowing the lawn in 95 degree heat and 80% humidity”. (Side note: When asked how he could pick up such heavy furniture despite not having lifted weights in 30+ years, my father responded “I guess I just realized that if I didn’t figure out how to move it then it wasn’t going to get moved”. Dad strength is like gravity: you just can’t explain it). Even doing a lackluster job mowing was a nothing short of full afternoon activity. This was not uncommon in the community that I grew up in, and I used to marvel at the different mowing options across my circle of friends: push mowers, handheld weed wackers, push weed wackers, ride mowers, zero turn ride mowers. No matter the skill level or job that needed to be done, it seemed like there was a mower tailor made for your needs, one that had next to nothing in common with the other models other than the fact that they all cut grass. From the manufacturers’ perspective, this strategy of having numerous disjoint models makes a whole lot of sense. It makes sales pretty straightforward: you just buy the mower that fits the size of your lawn. If you are a basic user with a tiny front lawn, you can get something simple. If you are an advanced user mowing acres of property, you can grab the model with all the bells and whistles that might otherwise be overwhelming.
Unfortunately, software companies often don’t have the same luxury as John Deere. Rather than releasing disjoint versions of a product, enterprise software companies are usually confronted with the challenge of making a single product that can span the entire spectrum of complexity. A product simple enough for a small lawn, yet powerful enough for the 14 year old in the August heat, all built on the same foundation. Creating something that resonates with a group of people is an incredibly difficult task. Building something that resonates to numerous groups of people is on an entirely different level. Yet this is the exact challenge at the heart of building a great software product.
There are many theories out there on how to build a great product, but to me it all boils down to effectively leveraging “just in time complexity”: the idea that a user should never have to know about the more complex parts of your product until the exact moment that they need it. By abstracting the difficult pieces until the exact right moment, you can keep things simple for the novice but powerful for the pseudo user. I heard one entrepreneur once describe their user experience as having “levels”, with each one building upon what you learned in the previous. The goal is to have these levels balance the linearity of Super Mario Brothers with the flexibility and open world nature of Grand Theft Auto. The question is how?
The Short Order Cook Side to Software
It turns out that our mundane daily lives are rife with examples of effective uses of just in time complexity.
Consider for a moment the short order cook at your local diner. Not just the hero of every Sunday morning, the short order cook is also a fascinating everyday case study in the balance between simplicity and complexity. On the surface, the cook’s task is simple: cook breakfast. But anyone who has ever been to a diner and seen the bible sized menus that are standard at such establishments will understand that what the short order cook does is nothing short of wizardry. Pumping out multiple orders in a timely manner while ensuring that a given table’s items come out at roughly the same time is anything but simple. How do they do it?
Author Matthew Crawford discusses this topic extensively in his book “The World Beyond Your Head: On Becoming An Individual In a World Of Distraction”. In his book, Crawford attributes the lightning efficiency of the short order cook to the usage of what he describes as “mental jigs” -- simple, self-imposed structures that offload thinking from a human to a system. In the case of the cook, these “jigs” would be things like how the plates are laid out, where they put the different pots on the burner, and other simple things that help keep the cook organized and enforce simplicity. On the surface, things look simple, and any old joe could walk in and cook a pancake if that’s all they had to do. But put an expert behind the burner, and the system begins to come to life, it’s normally hidden complexity coming to light at the exact moment it’s needed.
I think there is a lot that software design can learn from diners when it comes to wrangling complexity. The thing that attracts customers to new software products is very often the product’s simplicity -- they just want to cook themselves a few eggs on the weekend. Before you know it, they start to realize that they really enjoy breakfast, so they decide to bring it into their day to day routine. Now showing up to work with a spring in their step, their colleagues slowly start to notice that they’ve got a pretty great thing going. Next thing you know their whole team wants in on breakfast. The marketing team on the same floor also wants in, except they want pancakes not eggs, and they need them in a few flavors. Also, the remote employee overseas needs you to make a minor change to allow them to plug the stove into their outlets. So begins the bottoms up brunch.
This is also where things start to get complicated as a product development team. Excited by the prospect of new customers and expanding revenue, it is very common and natural to want to add the requested new features to your product as quickly as possible. After all, the menu of features is only a page or so long, so what’s one more feature?. The product might become a bit more complex, but not noticeably so. Things plug along nicely, your customers are happy that their feature requests are being fulfilled, and everything feels fine.
Until one day things aren’t fine. It may take a quarter, it may take a year, it may take three years, but one day you realize that your product has lost it’s magic. No longer a simple, approachable initial experience, you now have a complex, confusing, and frustrating product that presents features that are completely irrelevant to most users and serve only to needlessly complicate things. Products are a lot like people: first impressions really matter. Frustrated with the initial user experience, customers start to churn off your product in lieu of the next new thing.
Enter the Jig
Here is where we must take a page out of the short order cook book. We can’t wait until the restaurant is busy, we must choose a mental jig early and proactively. Deciding on what your jig will be is one of the most important product decisions you will make in the early stages, and is existential to long term product success. Initially, this may feel like an unnecessary abstraction between your user and what they are trying to accomplish, but it will establish a familiar foundation that will become key as your product grows in complexity.
It can be tempting to kick this can down the road, but that too can be dangerous. It is easier to solve technical debt, because it lives behind the scenes. It is nearly impossible to solve interaction design debt, because it sits front and center. You probably did not notice that Kevin De La Noy produced The Dark Knight, but that he was not part of Batman Begins. You probably did notice that Rachel was played by Katie Holmes in the first movie, and Maggie Gyllenhall in the second. By the time you have issues with complexity, it is too late. The only thing that would annoy your user base more than the current headache you’ve built is forcing them to totally relearn things from scratch.
If the goal of just in time complexity is to help your product stand the test of time, there is likely no better example than the Microsoft Office suite. While it is easy to knock on Microsoft Office’s design, it really does do a pretty incredible job of hiding its complexity when you don’t need it while making it pretty easy to find when you do. The breadth of what you can do with something Microsoft Word is astounding, yet it’s more or less frictionless to walk up to it and start typing. Office accomplishes this through the mental jig of the task bar. I don’t think anyone on earth knows every feature that is hidden in that bar, but by categorizing the actions into a nice hierarchy. Microsoft has made it pretty easy to find what you need something while keeping it hidden when you don’t.
Another product that elegantly leverages just in time complexity is Notion, a recent Index investment. Notion’s mental jig is the “backslash bar”. Using functionality similar to that of an IDE, a user can simply type “/” followed by a word (“bullet”, “image”, etc.) to add the appropriate block to their document. As a regular user, I can honestly say that I have absolutely no idea what the full list of items that are contained in that menu is...because there’s no need to! Every time I need to add something, I just type “/” and that thing that I am thinking of (e.g. “Figma”) and 90% of the time the exact thing that I was looking for pops up, all without breaking my typing. That, to me, is the definition of just in time complexity.