“The grass is always greener on the other side.” The popular idiom discourages whoever’s listening from seeking out alternatives, suggesting that other options always look better from wherever we’re currently standing. But it has a funny problem: nobody ever explains why the grass is greener on the other side.

That’s because it isn’t. The truth is that your side is just yellower/trampled on/eaten… and that’s because you’re on it.

Moving to a different place will be fine at first. Then you’ll use it, too, and eventually it’ll look the same as where you started.

(In this metaphor, you’re a goat. 🐐)

In workflow design, in addition to the novelty of “shiny new object,” new and alternative tools are great simply because they don’t have the cruft you’ve built up in the old tool. That cruft might be noisy notes, a lifetime of guilt-inducing task management, or even just bad habits and behaviours. The problem isn’t the tool. It isn’t you, either. It’s you and the tool.

So, after switching, the problems seem to go away… only to re-emerge (possibly in a new form) later because the issues are generated by your usage, not by the tool.

The solution is to fall in love with the problem, not the (shiny, potential) solutions.

  1. Determine what your issues actually are, and try to figure out why they’re happening.
  2. Then, abstractly identify how you might be able to mitigate the problems.
    • Don’t say “I’ll use Bunch,” say “If I standardize certain work spaces on my computer, I can develop muscle memory for using those workspaces, reducing distraction and allowing me to spend less cognitive energy on finding everything I need to get engaged.”
  3. Last, identify some tests or success conditions that will tell you whether the solution is actually working. This’ll help minimize irrational perspectives on how well the honeymoon stage is going.

Only after taking those three steps should you choose a tool. Find something that can implement the abstract principles you’ve articulated, and be sure to follow-through on the tests.

In doing this, you’re actually creating and implementing a rough design theory. You’re using design science to make your work as easy and engaging as it can be! High-five for that.