RedUX : User Centered Design : Golden Hammers
Back in 1966, Abraham Maslow said, “I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.” This is a cognitive bias known as “The Law of the Instrument”, or “Maslow’s Hammer”, or even “Golden Hammer”. Check out the wiki here…
https://en.wikipedia.org/wiki/Law_of_the_instrument
This cognitive bias is not just about hand tools, but how we humans approach every unknown thing we encounter. We look at the problem. We search our internal knowledge base, looking for a solution that fits. If we find something that might work, like a hammer, we try it. If we have any measure of success, the hammer’s status is elevated in our minds, and we try it more often. Before you know it, the hammer is our go to solution for each new problem we encounter.
As developers and designers, it is important for us to be diligent in making sure we aren’t always reaching for a hammer when we approach software creation. Web Developers should keep their toolset broad, by leveraging the full language of whichever technology stack they have access to. Designers should do the same…Understand the capabilities of the stack being used for the project, leverage it fully, while keeping your designs within those bounds.
In the enterprise, a lot of work is still accomplished in spreadsheets, which are the hammers of choice for many corporate employees. They have been using them for years, and have become very comfortable emailing copies to their coworkers, sharing them via internal repositories, and performing the endless integrations of changes from others. They are so used to the hammer, it’s become their only tool.
This is most evident when we approach them to understand their true business process, as we begin to design a web application for them. How often do we hear, “Just build us Excel on the web.” I cringe every time I hear that comment. Makes me want to grab a hammer. Just kidding.
Let’s try this example. It’s not mine and I do not know the original source, but I think it’s a good exercise. Say you are not designing a web page, but instead you are designing the layout of a desk for someone. You have the following items to place…
- Keyboard
- Screen
- Mouse
- Coffee cup
- Phone
- Notepad
- A pen
Picture in your mind: How would you arrange these items on a table?
I’m going to guess that you are imagining the Keyboard being front and center, with the mouse to one side of the keyboard and the screen centered just behind the mouse and keyboard. The coffee cup is probably just past the mouse, the phone is off to a side, and the notepad and pen are an afterthought. Pretty common layout these days. Was I close?
But remember that I said above that you were designing the layout for “someone”. Did you just lay it out for how you like it? Did you take out your “hammer” and solve the problem?
In this example, the “someone” is your grandfather ( or other elderly relative ), who has the computer for when his grandson comes over, to play games. Your grandfather does not email, he writes letters to his sister about twice a week. His grandson comes over once or twice a month. Your hammer has failed to provide a good solution for Grandpa.
We could have done such a better job if we understood the user first. Had I told you about your user ahead of time, you would have approached the solution much differently. At a minimum, I’ll bet the Notepad and Pen would have had a much more prominent placement in your layout. Maybe if we talked to Grandpa, we would have learned that it’s beginning to get hard for him to see to write without additional light. Knowing this, we would add a desk lamp to our toolbox for future solutions.
We must keep our design language wide, so that we have many tools in our toolbox. We must understand our user’s needs before we even begin to design a solution. We are not our users, and we must not limit our ability to solve their problems, by having only a hammer in our toolbox.
