Why Tools Are Important

While design thinking should ideally be tool agnostic, this isn't how people really work or think. Learning the ways that tools affect our thinking and vice versa can reveal a new paradigm of design process.

Tools are critically important to how humans work. Our use of tools distinguishes us from other animals in the animal kingdom.

As tools evolve, so does our thinking. We work differently, act differently, as tools enable us to perform actions we couldn't do otherwise or the same actions with greater speed. There are some things that we couldn't even design without having particular tools.

A Model for How Tools Work

A tool can be seen as a mediator between two often conflicting models: a conceptual model and a domain model.

The domain model contains the rules of the problem we're trying to solve. Graphic design, for example, employs layout, hierarchy, form, grids, typography, and so on, to produce crafted visuals, books, and communications.

The conceptual model encapsulates everything about how the tool works as an implement. Graphic designers may use Adobe Illustrator, which doesn't have any built-in notion of hierarchy or grids, but rather presents a designer with text boxes, paths, fills, and strokes.

As we learn to use a tool, we gradually build a mental metaphor for how the tools works, linking a goal we have (e.g. "place a title on a page") to actions we have to take in the tool (e.g. "create a text box and pick a font").

The better the tool, the closer the conceptual model mimics the way we want to think about the problem the tool solves. That doesn't mean the tool must mimic the domain model, although that's still a legitimate approach to design a tool. Tools and software can also be evaluated by how much we have to learn to operate the tool.

Our relationships with tools should be symbiotic. We either mold our thinking to the tool, or mold our tools to our thinking.

Tools Molding Our Thinking

Google and other search engines have changed how we find information. We think in terms of queries and browsing results in a matter of minutes or seconds instead of traversing references in a library for hours or even days.

A puppeteer controls a traditional marionette through a set of strings attached to a control bar. Recently, robotic and digital puppets can be controlled by full-body suits or clever tracking systems so someone can control it with her body. The result is a completely new range of expression one can achieve.

A vanilla text editor app is sufficient, albeit inconvenient, for both writing a novel and writing code, but the latter is much better served by a full IDE like Xcode or rich editor like Emacs or Vim, which provide features for navigation, help, completion, and error checking that are invaluable to programmers. Other editing apps can aid in structuring long works like novels that support plot, characters, and story structure.

The problems with working this way is there are too many tools available, and there are new ones being developed all the time. If we spend too much time evaluating or customizing them, we won't get any work done. Also, if we get too dependent on any one, we won't be effectual if it stops working or goes out of fashion. If it's too generic or has awkward interaction, then we may end up struggling with the tool more than thinking about the problem we're trying to solve.

Molding Tools to Our Thinking

Sometimes, the tools we've been given aren't good enough. Most software tools we find are are targeting the largest market possible, a business process that results in generalized functionality. The other end of the spectrum points to project-specific tools, which are tailored for a particular task.

We can get a lot of advantages by building our own tools. More important than making us more productive, we can craft tools to mimic our thinking, orient them around models closer to the design problem at hand. Instead of using software that "thinks" in geometric terms, we could build a app operates with the rules of hierarchy and layout that we specify. That way, we can think about how hierarchy and layout achieve the design goals, instead of struggling with the software's quirks and unrelated features.

To enable this workflow, designers need a partnership with coders that enables fast turnaround for custom apps, or they need to learn to code themselves in a system that enables fast prototyping. Each project could have a set of tools that "know" the rules and become creative partners instead of naive automatons.

Tools are important because they help and hurt us, and it's possible to build better ones for more intelligent paradigm of working. Denying their value and resisting their influence is folly. We can never fully separate the tools from our thinking and how we work.