I heard a story once about an engineer who worked on the Disneyland site when it opened in Anaheim, CA in 1955.  

A month before the park opened, the new grass and sod were being applied to the grounds as one of the last items to be completed before the big grand opening. The parking lot was some distance from the park’s gates and required a lot of turf.  However, the sidewalks had not been planned or constructed to accommodate patterns. 

Before engineers would validate the proper placement of the sidewalks, a heated internal discussion grew among landscape designers and park developers over how and what to build.  One engineer suggested they allow visitors to walk on the grass for months in order to observe the paths they created themselves. Then they would build over those paths that showed the most foot traffic. 

Those sidewalks are still there today. 

One engineer’s focus on meeting the guests’ needs saved the park millions of dollars’ worth of error and political positioning.

I found this story on Quora a few weeks ago, and thought it was a testament to how observing - instead of assuming - can save you a lot of effort, and will end up serving the users best.

In the first product I helped building, there had been lots and lots of requirements gathering before we got to build the first functionality. Once we rolled out the pieces to the first set of users, they were disappointed to say the least - enraged actually; “This not usable at all! Do you even know what you’re doing?". Apparently requirements were made up by people higher in rank, without consulting those who would have to use the software on a day-to-day basis. Not the best move getting buy-in from actual users, but I can’t really blame them either; requirements are hard, often times you’re just making stuff up as you go along - with best intentions. Being in a crisis, we got to learn a lot the next few months. One of us got sent out to the customer location a few times, and got to observe how they were trying to use our software. That information proved to be invaluable, and gave us enough to start shipping better and more useful software. Users felt empowered by our software, eventually leading to earning their trust and approval.

Another example can be found in my current project - which is not that visible to users, but more behind the scenes. Instead of guessing performance targets, it’s by observing production metrics that we’re able to set realistic goals.

Observing instead of assuming usually leads to better results. Keep in mind that you can misinterpret what you’re observing too, and that there often is no other option than to assume. You can still avoid overly expensive mistakes, by validating these assumptions as early as possible.