---
title: "Susan Kare was already drawing code before she touched the Macintosh"
locale: "en"
url: "https://irz.fr/en/articles/susan-kare-macintosh-icons-en"
markdown_url: "https://irz.fr/en/articles/susan-kare-macintosh-icons-en.md"
category: "craft"
tags: ["Susan-Kare", "Macintosh", "icons", "design", "interface"]
published_at: "2026-08-19T09:41:00.000Z"
author: "Arthur Lacoste"
translation: "https://irz.fr/fr/articles/susan-kare-macintosh-icons-fr.md"
---

# Susan Kare was already drawing code before she touched the Macintosh

Graph paper, a 32 × 32 grid, actual-size preview and finally hexadecimal for ROM: the first Macintosh icons came from a workflow where drawing and technical constraint were inseparable.

Before a Macintosh icon reached the screen, its first form could be nothing more than a handful of darkened squares on graph paper.

Susan Kare remembers her high-school friend Andy Hertzfeld explaining the problem in almost material terms: get some graph paper, make tiny images from the squares, and he could transfer them onto the Macintosh display then under development.[1](https://web.stanford.edu/dept/SUL/sites/mac/primary/interviews/kare/mac.html) Kare had no computer-graphics experience; her background was in art, traditional graphic design and sculpture, and not long before she had been welding a life-size razorback hog for a museum commission.[1](https://web.stanford.edu/dept/SUL/sites/mac/primary/interviews/kare/mac.html)

The jump from welded hog to bitmap only sounds absurd if digital work is imagined as having no material constraints.

Kare compares bitmap graphics to mosaics, needlepoint and other practices in which an image emerges from discrete units.[1](https://web.stanford.edu/dept/SUL/sites/mac/primary/interviews/kare/mac.html) The 1982 sketchbook preserved by MoMA makes the continuity visible: graph-paper squares can stand directly for pixels.[2](https://www.moma.org/collection/works/188382)

The support then changes without really changing the logic: an early editor allows squares to be switched on and off, Hertzfeld later builds a 32 × 32 tool that shows every pixel eight times larger while a second window keeps the icon visible at actual size,[3](https://folklore.org/Steve%2C_Icon.html) and another window turns the drawing into hexadecimal data that can enter the Macintosh ROM.[4](https://folklore.org/Busy_Being_Born%2C_Part_2.html)

The whole chain can almost fit on one line: **metaphor, sketch, grid, bitmap, hexadecimal, ROM**.

That chain is why Kare's work remains useful to examine. A revival of black-and-white pixels is beside the point; what matters is the way final form, drawing method and execution environment were designed together.

> Production chain
> **The icon never passes through a purely abstract space**
> - Find a metaphor or sign that a person can recognise or learn.: 1
> - Reduce it to a grid where every square becomes a visible decision.: 2
> - Keep the magnified drawing and its actual-size result visible together.: 3
> - Turn the bitmap into data that software and ROM can consume.: 4
> The graphic is constrained by the environment that will execute it.

## Graph paper was not a retro aesthetic

It is easy to look at those notebooks today as charming handmade artefacts and conclude that the early 1980s simply had a more naïve visual style, although the grid had a far more precise job.

The Macintosh used a bitmap display. A tiny monochrome icon was not an ideal vector curve that could be rasterised comfortably at any scale later on; the designer was deciding which pixels existed and which remained white. A diagonal, an eye or the handle of a trash can became a sequence of discrete compromises.

Graph paper exposed that unit before Kare even had a comfortable screen tool.[1](https://web.stanford.edu/dept/SUL/sites/mac/primary/interviews/kare/mac.html)[2](https://www.moma.org/collection/works/188382)

The method removes a separation that often exists in contemporary design between source drawing and final rendering. A modern icon may be built from Bézier curves on an enormous canvas and only later reduced to 16 or 20 pixels, where details become soft, asymmetric or invisible. The designer then fixes the reduced result.

Kare begins much closer to the other end, with the final rendering surface already functioning as the working surface.

The method still requires thinking about the whole image, but the grid forces a different question: which pixels actually carry recognition when there is not enough space to rescue a weak silhouette with subtle texture, elegant shadow or a colour gradient?

Scissors still need to read as scissors with very little information, a document must remain distinct from an application, and a bomb has to indicate a system failure without asking for a paragraph of supporting copy.

The result is not merely a detailed image simplified afterwards. It is an image conceived directly at the level of detail the product can use.

## The editor shows two versions of the same drawing

In February 1983, Hertzfeld built Kare an icon editor inspired by MacPaint's “Fat Bits” pixel editing. A large window displayed a 32 × 32 grid with each pixel magnified eight times, while a smaller window showed the icon at actual size.[3](https://folklore.org/Steve%2C_Icon.html)

> Illustration: Macintosh icon editor with magnified grid and actual-size preview. The 1983 tool exposes the pixel as working material while keeping the final-size result visible. Here Kare is drawing a tiny portrait of Steve Jobs. Credit: [Andy Hertzfeld / Folklore.org](https://folklore.org/Steve%2C_Icon.html).

That interface detail contains a strong design rule: **never confuse the space where work is edited with the space where its result will be used**.

A line may look smooth in the magnified grid and disappear at actual size, two separated pixels can turn into noise, and moving a single pixel may change the expression of a face.

Rather than asking the designer to remember that transformation, the tool keeps both views present.

Kare says she later moved much of the work into MacPaint, which also provided enlarged and actual-size views alongside tools for lines, circles and erasing.[1](https://web.stanford.edu/dept/SUL/sites/mac/primary/interviews/kare/mac.html) Moving from paper to software therefore did not abandon the grid; it added immediate feedback.

The same principle survives in good icon work today: a symbol edited at 400% is deceptive if nobody looks at it at 100%, and an icon intended for a navigation bar has to be tested in that bar beside its neighbours rather than admired alone in the middle of a huge canvas.

The technology changed. The perceptual problem barely did.

## The bitmap literally ends up in code

The first workflow was even more direct than the later 32 × 32 editor.

Kare recalls being shown how to take the artwork, work out its hexadecimal equivalent and type that representation into the system.[1](https://web.stanford.edu/dept/SUL/sites/mac/primary/interviews/kare/mac.html) Hertzfeld later added a “Hex Window” that generated the representation automatically.[4](https://folklore.org/Busy_Being_Born%2C_Part_2.html)

Period screen dumps preserved on Folklore.org show the transition for famous symbols including the bomb and Happy Mac. The editing window contains the visual bitmap while another part of the tool exposes the values needed to place it in ROM source.[4](https://folklore.org/Busy_Being_Born%2C_Part_2.html)

> Illustration: Macintosh icon editor showing the bomb icon and its ROM representation. The same object moves from visual grid to a representation that can enter ROM source. Design is not delivered as some abstract external asset; it becomes part of the software system. Credit: [Andy Hertzfeld / Folklore.org](https://folklore.org/Busy_Being_Born%2C_Part_2.html).

That step is worth dwelling on.

Today an icon file often lives far from execution, passing through Figma, an SVG export, an asset package, a UI component, a build pipeline and finally a rendering engine; the abstraction is enormously useful because nobody has to think about framebuffer memory each time a symbol changes.

It also makes it easy to forget what happens after export.

Early Macintosh icon work offered no such luxury. The bitmap was already a data structure. A designer could almost physically see the cost of a pixel and its translation into bits.

This does not imply that modern designers should write SVGs in hexadecimal, a punishment that would benefit nobody. The useful reminder is simpler: an interface asset remains data executed inside a technical context involving resolution, rasterisation, contrast, density, memory, latency and accessibility.

Abstraction helps only while the final behaviour remains visible somewhere in the process.

## A good metaphor does not need to be literal

Pixel constraints do not explain the success of Kare's icons on their own. A perfectly crisp shape can still be incomprehensible.

In the Stanford interview, Kare describes a practical process built heavily around reactions from other people: she would propose several ideas, show them around and see what worked.[1](https://web.stanford.edu/dept/SUL/sites/mac/primary/interviews/kare/mac.html)

For MacPaint's fill tool, she tried paint rollers and other concepts before the pouring paint can proved easier for people to understand.[1](https://web.stanford.edu/dept/SUL/sites/mac/primary/interviews/kare/mac.html)

Her standard for a successful icon remains demanding: ideally somebody who has never seen it can understand what it does, or the symbol is memorable enough that one explanation sticks.[1](https://web.stanford.edu/dept/SUL/sites/mac/primary/interviews/kare/mac.html)

That already separates **immediate recognition** from **learnability**.

Not every computer function has an obvious physical object; cut can borrow scissors and delete can borrow a trash can, while undo, synchronisation, branching or a privacy state become much harder to describe literally.

Kare did not assume that drawing skill alone could make an unfamiliar concept universal. She also searched existing visual languages and symbol collections.

The Command key is the clearest example.

## The Command symbol began as a density problem

Macintosh keyboard shortcuts originally appeared in menus beside the Apple logo. Steve Jobs objected to seeing Apples repeated throughout long menus and asked for another sign.[5](https://folklore.org/Swedish_Campground.html)

The design problem is almost comical: what exactly does “command” look like?

Kare remembers exploring several control metaphors, including signs with a more authoritarian feeling, before deciding that they were too harsh. Looking through symbol books, she encountered the form now associated with ⌘, described as a Scandinavian sign for an interesting feature or place.[1](https://web.stanford.edu/dept/SUL/sites/mac/primary/interviews/kare/mac.html)[5](https://folklore.org/Swedish_Campground.html)

Its appeal was partly abstract and partly mechanical. The symbol was distinctive, friendly and easy to express in pixels.[1](https://web.stanford.edu/dept/SUL/sites/mac/primary/interviews/kare/mac.html)

This case breaks an overly simple icon-design rule that says every action should be represented by a familiar real-world object.

The Command symbol does not naturally explain a computer command. Its strength lies elsewhere: it is easy to recognise and reproduce, neutral enough to sit beside many different actions, uncommon enough to collide with almost nothing else, and understandable after learning.

That fits Kare's own criterion. When immediate meaning is impossible, a symbol can still succeed if its meaning is easy to remember after one explanation.[1](https://web.stanford.edu/dept/SUL/sites/mac/primary/interviews/kare/mac.html)

A good icon therefore does not always behave like a tiny sentence. Sometimes it becomes a new word in a coherent vocabulary.

## Metaphors are chosen for their differences from one another

Documents and applications created another problem.

Kare recalls that the page with a folded corner already existed and worked well for documents. Applications needed to feel more “active”, so she developed a hand holding a pencil against a diamond, making the two categories much easier to distinguish.[1](https://web.stanford.edu/dept/SUL/sites/mac/primary/interviews/kare/mac.html)

The useful question therefore expands from “which image represents an application?” to “which image represents an application **without being confused with the document next to it**?”

That distinction matters in any icon system.

An isolated icon is easy to judge, but users meet collections, and two individually beautiful symbols can create a poor interface when they share the same silhouette, centre of mass or detail pattern and then collapse together at small sizes.

The early Mac's pixel budget already enforced part of that discipline: silhouette carried enormous weight, black masses needed distinct distribution, and a sign had to survive inside a family.

Graphics became syntax.

## Disk, bomb, rabbit: the references do not all come from the same register

The Macintosh visual language mixes several kinds of metaphor.

Some references are nearly functional, with a floppy disk depicting the removable medium, a document resembling a sheet and a trash can receiving deleted material; others are deliberately expressive, from the bomb's unusually literal dark humour for a system error to Happy Mac personifying startup and the rabbit and tortoise communicating different speed settings in the Control Panel.[1](https://web.stanford.edu/dept/SUL/sites/mac/primary/interviews/kare/mac.html)

That variety matters because a coherent icon system does not have to consist of symbols derived from one metaphorical formula.

Coherence can come from other constraints: shared grid, visual weight, contrast, reduction logic and tone.

That may be one reason Kare's symbols feel related despite depicting radically different things. They are not geometric variants of a corporate logo. They share a way of being reduced.

> Illustration: Early Finder screen showing a Macintosh floppy-disk icon. Inside the Finder, the icon is seen with other interface elements. Its success depends on silhouette and scale as much as on the isolated drawing. Credit: [Andy Hertzfeld / Folklore.org](https://folklore.org/Busy_Being_Born%2C_Part_2.html).

## Fonts came from the same problem: drawing for a matrix

Kare also designed early Macintosh bitmap fonts.

In an account on Folklore.org, she recalls that the first system face, provisionally called “Elefont”, was intended as a bold font without ugly jagged diagonals. The names later became Chicago, New York, Geneva, London, Toronto and Venice.[6](https://folklore.org/World_Class_Cities.html)

Proportional type was itself part of the Macintosh visual proposition: every letter no longer had to occupy the same width, so a narrow `i` and a wide `m` could behave more naturally,[6](https://folklore.org/World_Class_Cities.html) while the typographic freedom still had to survive a pixel matrix.

A curve, diagonal or weight difference needed to remain legible at small sizes. In that sense, a character was another tiny functional image.

The proximity between typography and iconography is interesting now because design systems often separate them into distinct libraries: variable font over here, SVG icon package over there.

For Kare they inhabit the same perceptual environment and have to share compatible density, scale and tone on one display.

## MacPaint gradually replaces paper without removing feedback

Once MacPaint became usable, Kare did a great deal of her graphics work inside it.[1](https://web.stanford.edu/dept/SUL/sites/mac/primary/interviews/kare/mac.html) Hertzfeld remembers her becoming one of its earliest expert users, testing capabilities as Bill Atkinson implemented them.[7](https://computerhistory.org/profile/susan-kare/)

The archive includes MacPaint documents made while the team was still finishing the Macintosh during 1983. The application became both a production tool and a product being tested by the artist who was building part of the computer's visual language.[7](https://computerhistory.org/profile/susan-kare/)

> Illustration: Early MacPaint screen during Macintosh development. MacPaint gradually becomes Kare's digital workshop: magnified drawing, actual-size result and tools evolving while the Mac interface itself is still being finished. Credit: [Andy Hertzfeld / Folklore.org](https://folklore.org/Busy_Being_Born%2C_Part_2.html).

That loop would be unusual in a mature product: the drawing program is still being built while its expert user designs symbols for the computer running it, allowing feedback about the tool and requirements from graphic work to meet in almost the same room.

The Mac story contains many short loops between design and engineering. They should not be romanticised; a small team also meant long hours and considerable pressure. But those loops help explain why some visual details do not feel as though they were pasted onto a finished technical architecture at the end.

The bitmap and the tool used to edit it evolved together.

## A single hot pixel creates responsibility

Kare also discusses cursors, where one specific pixel serves as the active point.[1](https://web.stanford.edu/dept/SUL/sites/mac/primary/interviews/kare/mac.html)

The problem is tiny and extremely concrete: an arrow can look visually correct while feeling terrible to use if the system's actual selection point differs from where the user believes they are aiming, giving a graphic decision an operational consequence one pixel at a time.

The relationship survives on displays with millions more pixels. A tiny click target, badly placed optical centre or ambiguous pictogram still turns visual design into functional friction.

High resolution can hide more of those relationships. It never removes them.

Kare worked in an environment where the machine forced them into view.

## What modern icon systems gained

A contemporary icon system obviously has capabilities the original Macintosh did not.

Vector formats scale, grids can be parametric, weight variants can match typography, colour contributes meaning, and interfaces adapt to multiple pixel densities, dark themes, accessibility requirements and many contexts.

Returning to monochrome 32 × 32 as a moral principle would be absurd.

The historical constraint has no virtue by itself: Kare used a strict grid because the product genuinely had that limitation, and turning it into a nostalgic visual filter today would copy the symptom rather than the method.

The useful method is different: **bring the constraints of rendering back into the design tool**.

If an icon has to work at 16 pixels, keep a 16-pixel view visible while designing; if it will live beside twenty others, test it beside twenty others; if light and dark modes matter, inspect both before final export; and if two interpretations are plausible, put the image in front of people before building an elaborate theory about why the intended meaning should have been obvious.

The 32 × 32 editor accomplished that movement with almost comically modest machinery.

There is another useful difference between that workflow and many modern design pipelines. Kare could inspect the *representation* that crossed the boundary into the product. The hexadecimal window was primitive, but it made the handoff legible. Modern pipelines often have more layers: SVG optimisation, component wrappers, font generation, platform-specific rasterisation, caching and accessibility metadata. Nobody needs to operate every layer manually, yet somebody on the team should be able to inspect the transformation when an icon renders incorrectly. The old tool exposed that boundary by necessity; current teams have to expose it deliberately.

This is less romantic than graph paper, and more reusable as a method. A design system stays healthy when its export pipeline can be understood rather than merely trusted.

## What abundance hid: the cost of every extra symbol

Modern tools make production extraordinarily cheap. A library can contain thousands of icons. Variants can be duplicated, aligned and exported in seconds, and generative systems can produce more candidates before the first coffee has had time to become disappointing.

Abundance introduces another problem.

When an icon took hours or days to develop and had to fit inside a tight memory budget, adding one was not a neutral decision.[1](https://web.stanford.edu/dept/SUL/sites/mac/primary/interviews/kare/mac.html) The marginal cost of another SVG now looks close to zero even though its cognitive cost is not.

Every additional pictogram has to be learned, distinguished, translated, documented, made accessible and maintained. A library containing 1,500 beautiful symbols can still create an incoherent application if fifty of them are used without a stable language.

The Macintosh's material scarcity indirectly created editorial scarcity.

We do not need to reproduce its memory limit. We may still benefit from the question the limit forced: **does this visual distinction deserve to exist?**

## Kare's grid was not a style. It was a relationship to the product

The graph-paper notebook has become an almost perfect image of early graphical-interface history. It is also easy to misread.

We can look at it as proof that pixel art is charming and then manufacture retro icons that imitate an era. That misses the useful part.

The paper mattered because it shared an elementary unit with the display, the editor because it kept the magnified drawing and its real use visible together, the hexadecimal window because it connected bitmap and ROM, and informal tests because they pushed the metaphor into somebody else's brain.

At every stage, representation moved closer to the product rather than away from it.

That relationship is what still makes Susan Kare's early Macintosh work useful.

A successful icon emerges where language, perception, tool and machine meet, rather than being poured into an interface after the rest of the product is finished.

In 1983, that place happened to be 32 pixels wide.

## References

1. [Stanford, Susan Kare interview, Working on the Macintosh](https://web.stanford.edu/dept/SUL/sites/mac/primary/interviews/kare/mac.html)
2. [MoMA, Apple Macintosh OS icon sketchbook, 1982](https://www.moma.org/collection/works/188382)
3. [Folklore.org, Steve Icon, Andy Hertzfeld](https://folklore.org/Steve%2C_Icon.html)
4. [Folklore.org, Busy Being Born, Part 2](https://folklore.org/Busy_Being_Born%2C_Part_2.html)
5. [Folklore.org, Swedish Campground](https://folklore.org/Swedish_Campground.html)
6. [Folklore.org, World Class Cities, Susan Kare](https://folklore.org/World_Class_Cities.html)
7. [Computer History Museum, Susan Kare](https://computerhistory.org/profile/susan-kare/)