Design and Implementation Trade-offs

A couple of days ago I wrote about how important it is for designers to know their materials. The material for interaction designers is code, so a baseline understanding of what code can and can’t do is essential for designers to be effective.

I learned this principle in one of my favorite books: The Art of Computer Game Design, by Chris Crawford (Osborne/McGraw Hill, 1984). Crawford was one of the early Atari game designers/implementors. (I use the slash because the distinction wasn’t as clearly drawn then as it is now.) His book lists seven design precepts for computer games. The seventh of these is titled “Maintain Unity of Design Effort,” and includes the following passage:

Games must be designed, but computers are programmed. Both skills are rare and difficult to acquire, and their combination in one person is rarer still. For this reason, many people have attempted to form design teams consisting of a nontechnical game designer and a nonartistic programmer. This system would work if either programming or game design were a straightforward process requiring few judicious trade-offs. The fact is that both programming and game design are desperately difficult activities demanding many painful choices. Teaming the two experts is rather like handcuffing a pole-vaulter to a high jumper; the resultant disaster is the inevitable result of their conflicting styles.

More specifically, the designer/programmer team is bound to fail because the design will make unrealistic demands on the programmer while failing to recognize golden opportunities arising during programming.

Crawford illustrates this by using a couple of examples from his career. One that’s stuck with me comes from the development of the game EASTERN FRONT 1941, a war game for the early Atari 8-bit computers. While he was programming the game (which he’d also designed), Crawford spotted an opportunity: a simple addition to its calendar routines would allow color register values to change as game time progressed. This allowed the color of trees to change to reflect the seasons. A minor detail for sure, but one that added depth to the experience. (Keep in mind that programming for these early computers meant always optimizing for limited memory. This minor change came at the expense of only 24 bytes of computer memory; a “cost-effective improvement” in Crawford’s words.)

Software development is much less painful today than it was in the late 1970s and early 1980s. Still, limited budgets and timeframes call for trade-offs. Knowing where the opportunities and constraints are helps when you’re called to decide what to include and exclude in the work.

Tools of the UX Trade

The tools we use when we design have an important influence in the work we produce. Conversely, sometimes the work we want to do can’t be carried out with the tools we have. This nudges us to either look to other fields for inspiration or invent new tools altogether.

As a child, the architect Frank Gehry was fascinated with fish. This fascination carried through to his work. In the 1980s, Gehry started producing fish-shaped lamps, and eventually won a contract to produce a large fish-shaped sculpture for the 1992 Olympic Games in Barcelona.

Sculpture by Frank Gehry, Barcelona (1992.) Image by Till Niermann, CC BY-SA 3.0 via Wikimedia. (https://commons.m.wikimedia.org/wiki/File:Barcelona_Gehry_fish.jpg)
Sculpture by Frank Gehry, Barcelona (1992.) Image by Till Niermann, CC BY-SA 3.0 via Wikimedia.

Gehry’s team needed to figure out how the fish would be built. Traditional architectural drawings are best when describing buildings composed of flat planes and volumes, but this structure’s undulating surfaces were anything but. The standard tools of trade trade weren’t going to cut it.

One of Gehry’s collaborators suggested they look at a software tool called CATIA, which had been developed by French aerospace firm Dassault Systems for designing aircraft. CATIA allowed Gehry’s team to delegate the complex calculations to computers, and made the fish structure a reality.

CATIA also opened new possibilities for the firm — and the field of architecture more broadly. Buildings such as the Bilbao Guggenheim Museum and the Walt Disney Concert Hall in Los Angeles wouldn’t have been possible to design and build using traditional tools. Introducing new tools into the mix made a new type of building possible, and the field of architecture hasn’t been the same since.

Walt Disney Concert Hall in L.A., by Frank Gehry. Image by Visitor7, CC BY-SA 3.0 via Wikimedia. (https://commons.m.wikimedia.org/wiki/File:Walt_Disney_Concert_Hall-1.jpg)
Walt Disney Concert Hall in L.A., by Frank Gehry. Image by Visitor7, CC BY-SA 3.0 via Wikimedia.

When I look at the tools UX designers use, I mostly see software aimed at designing screen-based user interfaces. Applications such as Photoshop, Illustrator, and Sketch are excellent at rendering forms on flat screens, but not much more than that. This constrains possibilities; as the cliche says, if all you have is a hammer, everything starts to look like a nail… and these apps are all hammers.

We also lack tools for exploring the semantic structures and relationships that underpin information environments. The closest we come is whiteboards and diagramming apps such as Visio and OmniGraffle. I’ve met many taxonomists whose primary tool is Excel; software designed for manipulating numbers!

There are clear gaps in this space. It’s surprising, given that the focus of UX design is often software itself. Why haven’t we produced tools suited to the needs of designing information environments? Is it a matter of the market not being big enough? Or do they exist and I’m just not aware of them? What tools from other fields could we adopt to meet our needs?

Screen Thinking

The tools you use influence how you think about your work. When all you have is a hammer, everything looks like a nail. Consider the tools available to designers of information environments. Here are four that are representative:

Creating a new artboard in Sketch:

New artboard in Sketch

Creating a new file in Illustrator:

New file in Illustrator

Creating a new file in Photoshop:

New file in Photoshop

Creating a new file in Adobe Comp:

New file in Comp

The assumption in these apps (and others like them) is that the object you’ll be working on is a screen. This is understandable; these are apps we use to work on the visual design of user interfaces. However, there’s much more to UX design than just what things will look like.

How do you express the connections between screens? Is it easy for you to explore alternative relationships between objects in the system? What tools do you use to work on the structural and conceptual models of information environments?