OK I confess, Abraham Maslow got to this concept before me – in 1966 to be precise – when he observed “To a man with a hammer, everything looks like a nail”. In my defence your honour, Silvan Tomkins and Kenneth Mark Colby got there before him and Abraham Kaplan before them.
In a 1964 article for The Library Quarterly, Kaplan put it as only a philosopher can, “We tend to formulate our problems in such a way as to make it seem that the solutions to those problems demand precisely what we already happen to have at hand.” Colby put it more straightforwardly, “if you give a boy a hammer, he suddenly finds that everything needs pounding.”
The underpinning law – The Law of the Instrument – is arguably more relevant in the 2020s than it was in the 1960s. Replace the hammer with Figma and the nail with a digital interface and we’re pretty much up to the modern day. At the heart of the challenge, as Tomkins said is “the tendency of jobs to be adapted to tools, rather than adapting tools to jobs.”
This matters for two reasons. First, it is all too easy for the designer to be blissfully unaware of the influence of the tool on the output. And second, rushing to the tool runs the risk that the designer loses sight of the problem they are tasked to solve.
Exploring how the tool influences the output in the context of digital design is best considered on a decade–by–decade basis. Those of us who’ve been around enough corners for a long enough time can remember what the web has looked like during each era as it has evolved.
The graphically heavy, architecturally lost, SEO–ly invisible websites of the 1990s were built on tools such as Geocities, Fortunecity, FrontPage and Dreamweaver. There is a little bit of chicken and egg here, as the tools were architected to produce the kinds of websites that were prevalent at that time, which in turn started to dominate the internet, which meant that the tools were enhanced to offer more of the same, and so on. Rinse and repeat and you end up in Cameron’s World.
We can’t even think about the 2000s without immediate reference to the F word – Flash (very definitely NOT the saviour of the universe) – and few arguments can justify the type of output which emerged from that particular platform. Photoshop featured large during that period too, with many websites written using a text editor to hammer out HTML, CSS and JavaScript by hand. The result was a website style for the decade which was graphically heavier, more dense and with less emphasis on typography and content than is typical today.
Into the 2010s, InVision and Sketch arrived ahead of Figma as the industry began joining up wireframe design, user input and iteration with the creative design process. The result was leaner more typographically expressive websites, with the fad of skeuomorphism replaced with flatter and more pastel design. Bevels, drop–shadows and lozenge buttons were mercifully put out to pasture.
Moving in to the 2020s, these tools have been joined by a maturing set of website self–builders such as Squarespace, Wix and Webflow.
At a macro level the evolution of these tools represents progress and the web is a more usable place than it was 20 years ago, but that doesn’t mean that we should lose sight of the creative and interface assumptions and “house styles” which have emerged along the way. We mustn’t forget that they lead us in a direction which includes a whole range of pre–baked design decisions. Often these design patterns are positive, but they are decisions nonetheless, whether deliberate or otherwise.
The second and larger danger of “jumping on to Figma” connects with Tompkins’ observation about the human bias of “the tendency of jobs to be adapted to tools, rather than adapting tools to jobs.” In the language of UX he’s referring to our propensity to lose our laser focus on the problem we are tasked with solving.
We recently completed a programme of research for a travel company who wanted to increase online booking conversion and within the project our attention quickly turned to the problems which the booking flow needed to solve for travellers. At first glance that might sound trivial or self–evident – surely the user just wants to book their journey?
Explorative research revealed that it’s not just as straightforward as that. See below a list of some of the problems users wanted the website to solve for them:
- I want to travel from Point A to Point B
- My ultimate destination is Point C and want to arrive as close to Point C as possible
- I am travelling with a young family and want the shortest crossing between two countries
- I am budget–conscious and want to find the dates on which my travel will be cheapest
The research uncovered other user problems to be solved, however even this truncated list provides important insight which needs to influence booking process flow. It needs to include departure and destination options, geographical information for those who are unsure of their route options, early inclusion of price and pricing options for the budget–sensitive, crossing times and onward travel times.
And while Figma is a wonderful tool, none of those problems get solved by playing with the componentry of an interface layout. The product meaningfully connects the design process with the build process, with well–structured componentry, relevant design patterns and easy prototyping to aid iteration and user–input, but considering how to solve these problems is a different craft. The tools for that craft are white boards and post–it notes and sharpies!
In a sense its unfair that I am using Figma as my reference – it just happens to be a wildly popular tool at the time of writing. Certainly it’s a key part of the armoury of many UX designers and UI designers, but we do well to remain aware that the tool, like all tools, biases the output. And that our primary responsibility always is to solve business problems and meet user needs.
