How a transparent creative process built the iPhone keyboard
How a transparent creative process turned fifteen Apple engineers into the team that built the iPhone keyboard—and invented autocorrect along the way.
When most people hear the word process, they think of something rigid — checklists, approvals, bureaucracy.
At first, it feels like the opposite of creativity. Creativity, after all, is supposed to be spontaneous and free.
But the best creative breakthroughs hide a process beneath them — a structure that channels imagination into form. The only difference is that creative processes are rarely visible. In fact, the mess gets hidden, the iterations are erased, and the final product looks inevitable.
That illusion feeds a dangerous myth: that process kills creativity. In reality, a process designed to produce consistent results — and to make the work visible — accelerates creativity. A transparent creative process is more than a record. It’s a way to channel interdependence — to make one engineer’s iteration visible to the next, so each new attempt builds on what the team has already learned.
And the idea is four hundred years old.
🎧 This Topic on the Lighthouse Leadership Podcast
Real stories. Hard lessons. No fluff.
Galileo created transparency
Centuries before anyone used the word innovation, Galileo confronted this same tension between imagination and reality. As biographer Laura Fermi puts it,
“Galileo invented experiments, considered them a necessary regular practice, and came to regard them as the criterion in discriminating between the unlimited possibilities of human imagination and the realities of the physical world.”
However, Galileo didn’t just dream; he built a process to test dreams against the world. His experiments made discovery transparent — visible, measurable, and repeatable. We now call it the scientific method.
One famous demonstration involved dropping unequal weights of the same material from the Leaning Tower of Pisa to prove they would strike the ground at the same time. The experiment settled an intellectual debate with observable proof.
Then, in 1971, astronaut David Scott repeated Galileo’s insight on the surface of the moon. He dropped a hammer and a falcon feather simultaneously. They hit the lunar surface together, just as Galileo had predicted.
He showed that creativity without transparency is fantasy, but creativity with transparency becomes science.
We meet our next story in 2005.
The keyboard derby: a transparent creative process
Fifteen engineers from Apple’s User Interface department sat in a conference room called “Between” in October 2005. Across the hall were rooms named “A Rock” and “A Hard Place.” The names were whimsical, but the stakes were serious. Project Purple, Apple’s secret iPhone effort, was in trouble. If the team could not solve one problem, the project would be cancelled.[2]
Steve Jobs had envisioned a smartphone “without the stupid keyboard.” Physical keys, he said in the 2007 keynote unveiling the product, were “the problem.” He wanted a touchscreen keyboard that appeared only when needed. The challenge: no one had ever built one that worked.
Henri Lamiraux, Apple’s newly-promoted Director of Software Engineering, gathered the entire user-interface department and gave a single directive.
“Starting from now, you are all keyboard engineers.”
From that moment, every other project paused from a UI perspective. The backlog was clear: make typing on glass work.
For an entire month, the team produced nothing but keyboards. Every other day they gathered to show prototypes, test them, and refine ideas. They called it the Keyboard Derby. It was a race of ideas conducted in the open: everyone could see what others had tried, what failed, and what was improving. The rhythm of near-daily demonstrations forced progress and made the work audible. Transparency had become the process.
An engineer named Ken Kocienda would win the race — but only after six completely different keyboards, an experience he documented in a book called Creative Selection.
Twenty years later, the keyboard derby got a footnote. Julien Dorra, who teaches a tech design history course in Paris, asked Ken on Bluesky if he’d ever seen the blob keyboard come back to life.
“Hi! I’m teaching a tech design history class here in Paris where your keyboard is one of the key innovation stories. I’m making the class more hands-on with props, demos. Crazy idea: I want to build a Blob Keyboard simulator so they can feel the design iterations.”
“Try this.”
And then Julien actually built it. Try it — it works:
Try the 2005 “Blob Keyboard” prototype. Tap for middle letter; swipe left/right for side letters.
You probably found that prototype tricky to use. Ken did too. But the real value of this early concept wasn’t its performance. It was what he learned from the feedback he received while demonstrating it to his peers.
Some engineers had simply put a QWERTY keyboard on the screen, but the keys were so small that accurate typing was nearly impossible. Ken’s “blob keyboard” explored a different tradeoff. The keys were larger and easier to hit, but each one contained multiple letters. Selecting an individual letter required a gesture. The result was accurate tap targets, but a mentally taxing interaction. You had to locate the letters in an unfamiliar arrangement and then remember the gesture to select the right one.
That feedback mattered. It showed Ken there was value in larger keys, but gesture-based selection was too slow and too cognitively expensive. His eventual solution would return to a traditional QWERTY layout. To make small keys usable, he’d pair them with an entirely new concept: autocorrect.
About a month later, in the same conference room called Between, Ken Kocienda sat beside his boss’s boss, Scott Forstall, in front of an early iPhone prototype called the Wallaby. The device, tethered by a thick cable to a blue and white Apple G3 desktop computer, was essentially a multitouch display connected to a bare logic board.
Forstall spent more than an hour testing fourteen keyboards. Each had the same flaws: the keys were too small or too slow to use accurately.
Ken’s keyboard was last. He had demonstrated five or six prior designs to his coworkers, making improvements each time. This was the first demo for Scott.
Kocienda’s “Bubble Keyboard” looked different from the others. The keys were larger, but each one contained multiple letters. He tapped nonsense letters — as zxc op rt rt space yui as space nm yul space nm as nm qwe — and looked up.
The screen read: Scott is my name.
“How did it know what I meant?”
Kocienda explained that the system used two dictionaries: a static one of common words and a dynamic one that learned a user’s personal vocabulary. “The purpose was to help you type words in your own voice,” he answered. “To give you what you meant instead of what you did.”[6]
Ken had invented autocorrect to make a tiny touchscreen QWERTY keyboard usable.
But that invention didn’t happen in isolation. It happened because the leadership team set one clear priority, and because the team adopted a cadence of frequent demonstrations that produced constant feedback. Clarity and rhythm made progress visible.
Thus ended the Keyboard Derby. Kocienda’s prototype became the foundation of the iPhone keyboard, and he spent the next year refining it, demonstrating progress at every step.[7]
Apple’s was a transparent creative process — not mystical, but visible at every step. That transparency yielded two things at once. The leadership team could see, immediately, that there was no working keyboard — and they could see the criticality. The team could see, day after day, how every engineer’s prototype was shaping every other engineer’s next attempt. Urgency from the top; iteration across the middle.
With the culture of demonstrations, they made five things transparent:
- Backlog — Make the keyboard work. Nothing else.
- Priority — Every other UI project paused.
- Progress — Every engineer demoed every other day.
- Method — Build, show, learn, repeat.
- Rhythm — Steady and relentless. The work was audible.
This is what a transparent creative process looks like. It does not kill imagination; it channels it. The iPhone keyboard was not born from a single spark of genius but from the sound of a team learning in public.
When people imagine creativity at Apple, they often picture a lone designer — Jony Ive or Steve Jobs himself — sketching a perfect idea. That’s a myth. Apple’s creativity was transparent and team-based.
The interdependence was real — fifteen people couldn’t have produced this in parallel without it. What transparency added was the channel: a way for each engineer’s work to inform every other engineer’s next attempt.
The iPhone in particular was a large team of teams. To maintain secrecy, very few engineers could see the entire product that was being developed, and many were genuinely surprised by features unveiled at the January 2007 keynote. Yet within each sub-team, the work itself was transparent. People could see their backlog, their priority, their progress, their method, and their rhythm.
That rhythm didn’t strangle creativity. It sharpened it.
- [1]Laura Fermi and Gilberto Bernardini, Galileo and the Scientific Revolution (Basic Books, 1961), p. 4. ↩
- [2]Ken Kocienda, Creative Selection: Inside Apple’s Design Process during the Golden Age of Steve Jobs, First Picador Edition (Picador, St. Martin’s Press, 2019), pp. 140–152. ↩
- [3]Julien Dorra and Ken Kocienda, Bluesky exchange about the blob keyboard, March 30, 2025. bsky.app/profile/kocienda.bsky.social/post/3llmuxfgud22i. ↩
- [4]Ken Kocienda, “Wallaby prototype photo,” Bluesky, March 30, 2025. ↩
- [5]Ken Kocienda et al., iPhone Keyboard, U.S. Patent 7,694,231 B2, filed July 24, 2006, issued April 6, 2010, Fig. 12G. ppubs.uspto.gov/api/pdf/downloadPdf/7694231. ↩
- [6]“Duckin’ Autocorrect: The Inventor of iPhone’s Autocorrect Explains How It Works,” The Wall Street Journal, 2022, 07:51. youtube.com/watch?v=Ncj3QAKvBBo. See also: “The Man Behind Autocorrect — Part One,” directed by Jerry Cuomo, 2024, 19:25. youtube.com/watch?v=9MVIrLUenm4. ↩
- [7]Ken Kocienda, Creative Selection, pp. 140–152 (same source as note 2; cited again for the specific timeline detail). ↩