Software as a tool: how engineering trumps user experience and why design thinking can fix it

Software as a tool: how engineering trumps user experience and why design thinking can fix it

  • Comments 0

Lately I’ve been thinking lots about design thinking. I’ve been doing so because I think deeply about lots of things that affect me. Design thinking affects me because I am living in a culture of engineering thinking. What I mean by design thinking is a particular perspective on solving problems that really helps people. I work on a product that is a tool, so great tool design and great product design, in my mind, are not created from the same recipe. I name examples of tools from trades: hammer, saw, stethoscope, tongue depressor, scalpel, wrench, screwdriver, ratchet, pencil, eraser, and many other items that we can grasp, touch, and manipulate with more than one sense.

The other category of tools, often used by the same trades, involves the virtual. The most useful aspect of these tools, we can’t touch. We can manipulate them indirectly in way not learned through experimentation as a young child. Although this is changing. I won’t talk about the next generation of computer users, that’s a topic for another blog. Everyday many professionals in all types of professions use software as tools. What is so different about engineering a hammer and engineering software? First, software is more complex and itself is a system and a hammer, although having gone through many iterations over time, is static.

You could build a house by hitting nails with a rock. You’d have to find the most effective rock for your hand size and strength as well as type of nail and striking surface. A hammer would work better because the leverage you get from the handle results in fewer strikes to get the nail in and ultimately finishing your house faster. So efficiency of task is important for tools. But how would your hand feel after striking the nail with a rock and striking a nail with a hammer? One could imagine a very sore hand, especially on the palm and possibly the small bones where the fingers join the hand. So ergonomics are important with tools. Even within the hammer types, the handle is important–it’s shape and materials will save your hand from vibrations and other potential malformations of the grip while striking the nail.

Thinking like an engineer, then, where solving efficiency problems is number one, what’s a more efficient way to get the nails in any given surface? A high-powered nail gun solves this problem. Ergonomically, a nail gun may not provide comfortable solutions for holding the gun and pulling the trigger repeatedly. But if we consider the experience from the user’s perspective, then what the user values is really important. Consider the carpenter who enjoys the skill of striking the hammer head just perfectly on the nail head with the precise force that knocks the nail into a two by four in just two blows. This game might be part of what the carpenter loves about his job. The boss might tell the carpenter that from now on the crew is using nail guns because they are twenty percent faster. The experience of the game is lost. A number of items comes to mind. What if the carpenter actually likes using the nail gun because it’s equally as satisfying but for different reasons, then you’ve replaced one pleasant experience for another. But if you’ve solved the efficiency problem but not the problem of removing a valued skill, then you’ve got a bad experience. The carpenter will use the nail gun but his job will be less satisfying. This brings up issues of empowerment to the workers and is the fundamental driving force for participatory design.

Let’s compare an example of a tool that exists in both the software and non-software form. A tool fundamentally helps getting a task done. Let’s find an example of a tool that allows the user to accomplish similar tasks but one with a tool, or a collection of tools, and the other with a software tool. Although it’s never easy to find an example or analogy that fits fully as an illustration, I’ll use the example of architectural tools. These tools are an interesting example because they exist as a complex enough system whether or not they exist in the real or in the virtual. Architects, before using software tools, used pencils, paper, and modelling tools to create their masterpieces. The particular advantage that software tools have over tangible modelling tools (like balsa to create 3D buildings and trees) is that a possibility to create alternative designs exists to show their clients side-by-side. Quickly exchanging different pieces of the computer model is easy compared to reconstructing the tangible from scratch. In this case the tools both virtual and tangible appear useful but for different reasons. However, an expert who builds tangible architectural models may not find the experience of creating models in software similar and even useful because it removes the texture and touch sensation from the architect’s hands. Even if the architect does not create the 3D models, then drawing blueprints and sketches may be the most enjoyable experience. The architect’s tools, pencil and paper, are an important aspect of being an architect. However, the experience of using 3D modelling software is considerably different. Although engineering software to represent and render architectural models in 3D has been the focus of software tools, the cognitive work an architect’s brain must achieve to create the 3D virtual representations is considerably different from building them as tangible models from feeling touch and texture. The architectural software tools create a experience for an architect that can be awkward because software user experience paradigms may not be functional for the work of creating architectural models. In other words, the user experience was not designed for architectural work.

However, if design thinking would have been key instead of engineering thinking, then some of the important aspects of being an architect might have been preserved. Design thinking consists of creative problem setting and solving processes with the goal of meeting user needs. As such, from the examples, we’ve seen that tools undergoing advancements in engineering, whether from the actual to the virtual or with tools such as a hammer, are likely to undergo such advances without attention to the user’s experience.

I’ve taken a while to get to this point, but I see examples of engineering advancement out of sync with advances in user experience. In most cases, the user experience is a consequence of engineering. When the user experience is a consequence of engineering, it always results in a less than optimal one. I am using this thinking exercise to point out that engineering culture dictates bad experiences. Only through a design thinking culture and prioritizing user needs can the design of good user experiences and engineering advances exist in parallel.

Another point I wanted to make was that designing user experiences for tooling and for consumer products are different. I work on a software tool that developers use to develop software. One question I think about on a regular basis is, what’s similar and different about the user experiences of tools and of consumer products? Can they be the same? Would it make sense to make Visual Studio as delightful as an iPhone?

Leave a Comment
  • Please add 3 and 5 and type the answer here:
  • Post