When I ask Alex, our lead dev on Kin, to make a quick change to a customer’s account, he’ll do it. If I ask him to do the same thing a few more times that day, he’ll do it. The next day, if I ask him, yet again, to do the same repetitious act, he’ll do it. The next day, however, he’ll walk in and say “Hi, I built this dashboard for you so that you don’t have to ask me to do that damn thing a dozen times a day anymore, ok?”. That happened this past week.
We jokingly called it the “Don’t throw your trash in my backyard” effect. The thought being, if enough junk piles up in Alex’s backyard, he’s gonna figure out a way to fling it back into my yard to deal with.
This wait-and-see approach to building a feature in software is great. In a less informed (but perhaps more common) design model, we build what we anticipate users will need. In a model like this, a clear and obvious need arises first, and the designer acts to solve for it quickly and accurately. It’s a refreshing experience given that so much of the work we do everyday is to solve perceived problems that a perceived user may have one day.
It reminds me of another old adage: Give a man a fish, he eats for a day. Teach a man to fish, he eats for a lifetime. So it goes.