
By Ken Kocienda
ISBN: 9781250194466
Date read: 2026-05-23
How strongly I recommend it: 9/10
The iPhone keyboard engineer explains why showing real work beats describing ideas every time.
✅Design is *how* a product works
✅Steve believed we do better with a product that wasn't loaded down with everything above the product designers could dream up. He believed that stripping away non-essential features made products easier for people to learn from the start and easier to use over time. He wanted products and their software to speak for themselves. He realized that, in most cases, nobody would be standing over the shoulder of a person who is having a first experience with software, carefully describing every nuance of every feature. Sure, in a place like an Apple retail store, staff are always on hand to answer questions, but wouldn't it be better if software was clear and intuitive right off the bat?
✅Steves demo reviews the judge for himself whether a feature has met this basic usability standard. When he gave me the specific feedback to remove one of the two keyboards from my iPad demo, it had a cascade effect towards greater simplicity and meant we could also take out the bounce zoom animation. We could also take away the zoom button. We could also take away possible confusion about which keyboard to show in different situations. For example, should the software remember that you use the bigger keyboard in the Notes app and the more keys keyboard in Mail? Should these keyboard choices be restored in some situations but not in others? These questions became moot, and that's good because they don't necessarily have easy answers. Steve figured that the best way to answer difficult questions like these was to avoid the need to ask them.
✅I chuckle to myself over how much time I've spent thinking about this iPad demo and how much Steve taught me in one meeting when he spoke just four sentences
✅Software demos need to be convincing enough to explore an idea and communicate a step towards making a product, even though the demo is not the product itself. The movie demos should be specifically choreographed so it's clear what must be included and what can be left out. Those things that aren't the main focus of a demo but are required to create a proper setting must be realized at the correct level of detail so they contribute to the whole rather than detract from the vision.
✅I think if you do something and it turns out pretty good, then you should go do something else wonderful and not dwell on it for too long. Just figure out what's next.
✅We couldn't get away with telling our demos. We had to demonstrate our idea. We were required to show.
✅Over time, I came to the conclusion that designing an excellent user experience was as much about preventing negative experiences as facilitating positive ones.
✅Taste is developing a refined sense of judgement and finding the balance that produces a pleasing and integrated whole.
✅I’d like to end with a note to readers at the beginning of their careers. You might be telling yourself that you want a career in product development. You may have plans to do great things in some other field. Either way, I have some advice: Get busy. Decide what it means to do great work, and then try to make it happen. Success is never assured, and the effort might not be easy, but if you love what you’re doing, it won’t seem so hard.
With that, Steve slid his iPhone back into the front pocket of his jeans, straightened himself in his chair, and then turned slowly to face me. His eyes met mine. Over the years, many people have commented on Steve's special ability to tell you something, whatever it was, no matter how implausible, and make you believe it. This "reality distortion field," the RDF, had become legendary; yet in the moment Steve fixed his eyes on me, I felt an opposite force, RDF with the polarity reversed, like flipping on a light switch. Steve had turned on a no-nonsense zone around himself, one that banished all flummery and neutralized all pretence. His look was obviously unfriendly or threatening, but surely he knew his unblinking gaze can intimidate people in my position, and it certainly had that effect on me. I saw his look as a signal that he wasn't going to let me pull the wool over his eyes. He was now ready to see my demo.
Scott reached out to prototype iPad without picking it up from the table. He clicked the home button, and when the screen woke up, he slid his finger to unlock it. Steve was still looking at me, continuing the demo introduction from where Scott left off. I said, "Right? There are two designs:
- One has more keys like a laptop keyboard
- The other has bigger keys like a scaled-up iPhone
We're thinking of offering both. Try the zoom key to switch between them."
Steve moved his eyes all over the iPad screen, rotating his head slowly in small figure-eights in what I took to be an attempt to get a view of every corner of the display, both straight on and in peripheral vision. After several long moments of study, he reached out to tap the zoom key, triggering the beautifully crafted animation that Bas had made to switch the keyboard to my bigger keys design. No reaction, no hint of what he was thinking. Steve was like an expert high-stakes poker player checking his whole cards for the first time after receiving them from the dealer.
Now that the screen looked different, Steve started his study all over again. He took his time, taking a solid 30 seconds to absorb every detail on the screen. When satisfied, he tapped the zoom button again, returning to the iPad more keys layout. Now it looked exactly like it did at the start of the demo. Steve studied again, still betraying no sign of what he thought or felt. He tapped the zoom key one more time, changing to the bigger keys layout again. He took in this view briefly to confirm to himself that he had now seen the two designs, everything there was on offer. He turned to look straight at me. "We only need one of these, right? Not what I was expecting." I think I may have swallowed hard.
Steve was still looking at me, and so, with a half shrug, I said, "Yeah, I guess so." Steve sized me up a little and then asked, "Which one do you think we should use?" A simple question, clearly directed at me and only me. Steve didn't shift in his chair or motion towards anyone else in the room. It was my demo, and he wanted me to answer, and then something happened, standing there with Steve Jobs staring at me, waiting for me to respond to his question. I realized that I knew what to say, that I had an opinion. Well, I've been using these demos for the past few days, and I started to like the keyboard layout with the bigger keys. I think I could learn to touch type on it, and I think other people could too. Auto-correction has been a big help.
Steve continued looking at me as he thought about my answer. He never moved his eyes to anyone or anything else; he was completely present there. He was seriously considering my idea about the next big Apple product; it was thrilling. He thought for a few seconds about what I had just said and what he had seen on the iPad, then he announced the demo verdict: "Okay, we'll go with the bigger keys."
When creating a browser for Mac OS X, they decided to go with the open source Mozilla (Netscape) to get that working on their software. It was taking them six weeks to just do a demo since the codebase was huge and there were a ton of bugs. Then, they hire Richard who gets a solid demo done in two days. He is the culmination of a 10x programmer. He did this because he focused attention on where it needs to be (opening the browser, going to a webpage, and going back to a previous page), started approximating the end goal as soon as possible and maximized the impact of the most difficult effort. He combined inspiration, decisiveness, and craft to make demos.
Up on stage in Moscone, Steve rehearsed in a way that was new to me, and once I saw his technique, it seemed so right to me that I’ve used it myself for my own presentation rehearsals ever since. When Steve spoke to a slide, he went fully into his keynote persona. His tone of voice, his stance, his gestures, everything was exactly as if he were presenting to a packed house. For as long as everything proceeded to his satisfaction, he kept going. As needed, he stopped, stepped out of character, reduced the volume of his voice, and asked executives seated in the front row, like Phil Schiller, the company’s senior vice president of Worldwide Marketing, what they thought of some turn of phrase or whether they believed ideas flowed together smoothly. Feedback received, Steve would pause quite deliberately for a second or two, go back into character, and resume his keynote persona. If a phrase still didn’t run right, he would pause, back up, and try again. Sometimes he did this three or four times, each time with an absolutely clear separation between attempts, like takes on a movie set. He never truly bungled a line—his presentation was already polished by this point—but he was committed to making every slide and every phrase better if he could.
Gentlemen, we have a great deal of ground to cover. We’re going to do things a lot differently than they’ve been done here before. We’re going to relentlessly chase perfection, knowing full well we will not catch it, because perfection is not attainable. But we are going to relentlessly chase it because, in the process, we will catch excellence.
I’m not remotely interested in being just good. Gentlemen, this is the most important play we have. It’s the play we must make go. It’s the play we will make go. It’s the play that we will run again, and again, and again.
You wouldn’t think that there was so much to say about a single running play, but Lombardi talked about the PowerSweep, and only the PowerSweep for eight hours
It may seem like a stretch to draw a comparison between winning football games in Green Bay and developing web browser software in Cupertino. A significant part of attaining excellence in any field is closing the gap between the accidental and the intentional. To achieve not just something, or even anything, but a specific and well-chosen thing, to take words and turn them into a vision and then use the vision to spur the actions that create the results.
When I look back from our technology work to the coaching of Vince Lombardi, I see in his approach to football the same pursuit of clarity and perfection that we sought in our effort to make products at Apple. With his single-minded emphasis on the Power Sweep, and with the success the Packers enjoyed as a result, Vince Lombardi was the Steve Jobs of football coaches. Lombardi connected his words and his team’s actions in football by focusing on one simple play, while at Apple, with our single-minded emphasis on never making the browser slower, we connected our words and actions in software by focusing on one simple rule: make the browser faster.
After the success of Safari, I didn't end up getting any promotions. I applied to the manager position but didn't get it. I almost left for Google, who would offer me a higher salary, but instead decided to stay. My morals were aligned with Apple's. This points to the more general lesson that I took from my web kit editing work: people matter more than programming.
If Scott hadn't found the right words to say to me in the wake of the Safari management change, I might have gone off to Google, and I might have never signed up for the web kit editing project at all. If Don, Darren, and I had been unable to continue the work together because of my feelings over the same management change, or if I had been too prideful to make productive use of the advice I got from Darren and Trey, I might have remained stuck. My web kit work processing project might have failed. As a programmer and self-professed geek possessed of typical geek programmer communication skills, it was a revelation to me that both the setting and the solution to my hardest technical problem turned as much on the social side of my job as it did on the software side.
Taste is *developing a refined sense of judgement and finding the balance that produces a pleasing and integrated whole*
First, there’s developing judgement, the feeling you have when you instantly know something is good or bad. A lack of specific thoughts isn’t a big deal when picking fruit to put on top of breakfast cereal, but such gaps are an issue in creative work. Persist too long in making choices without justifying them, and an entire creative effort might wander aimlessly. Developing the judgment to avoid this pitfall centers on the *refined-like response, *evaluating in an active way and finding the self confidence to form opinions with your gut you can also justify with your head. It’s not always easy to come to grips with objects or ideas and think about them until it’s possible to express why you like them or not, yet taking part in a healthy and productive creative process requires such reflective engagement.
The Apple employees would frequently give demos to each other to give feedback. People would try Ken’s keyboard to improve it and Ken would try demos of other people’s software. There was still a lot of secrecy between the different features and the hardware of the iPhone. Ken had no idea how the hardware worked or how they dealt with the phone carriers since it was red taped.
There was drama where Ken would get mad at a teammate and yell and them, but the drama was uncommon. Usually we kept the **rate of our progress above the level of our stress. **
Bug squashing might help to make a decent product, but it’s no the secret for making a great one.
Before I get to our design process, I’d like to discuss what not to do when it comes to design.
Google decided to test 41 shades of blue to decide which would be best for getting people to click a link. This was time intensive and didn’t allow them to think of something that could be 2x, 5x, or even 10x better.
A/B tests might be useful in finding a color that will get people to click a link more often, but it can’t produce a product that feels like a pleasing and integrated whole. They factored out taste in the design process.
At Apple we never would have dreamed of doing that, and we never staged A/B tests for any software on the iPhone. When it came to choosing a color, we picked one. We used our good taste—and our knowledge of how to make software accessible to people with visual difficulties related to color perception—and we moved on.
Or did we? Well, yes and no. We always made quick choices about small details, but we’re always willing to reconsider previous decisions. We took more time with bigger questions, but never too much. We were always mindful of making steady progress.
Continuation of demos: demo→feedback→next demo: *creative selection*
We managed to steer clear of all pitfalls. If I were to take a stab at explaining why, I would say that our clarity of purpose kept us on track, in much the same way Cince Lombardi won football games and Steve Jobs pushed us to make a speedy first version of Safari. Perhaps concentrating keenly on what to do helped us to blocked out what *not* to do.
We always started small, with some inspiration. We made demos. Mixed in feedback. We listens to guidance from smart colleagues. We blended in variations. We honed our vision. We followed the initial demo with another then another. We improved our demos in incremental steps. We evolved our work by slowly converging on better versions of the vision. Round after round of creative selection moved us step by step from the spark of an idea to a finished product.
Employees would refer to always working at the intersection of technology and liberal arts as “The Intersection”. The reason Apple is able to create products like the iPad is because we’ve always tried to be at the intersection of technology and liberal arts, to be able to get the best of both, to make extremely advanced products from a technology point of view, but also have them be intuitive, easy to use, fun to use, so that they really fit the users. The users don’t have to come to them, they come to the user.
It went beyond fonts, colors, and the visual design elements you might think of when you hear the word art in liberal arts. The effort extended to all the senses. I wanted the iPhone keyboard click to evoke the clack of a typewriter key striking a page and ultimately achieved this by striking my pencil on the edge of my desk. I’ve been inspired by a story I heard of how Ben Burtt, the sound designer for the first Star Wars movie, made the sound effect for blaster shots by recording hammer strikes on a guy wire for an antenna tower.
To find the right size for the Home Screen icons, they created a game that you would tap a box, it would disappear, then another box that was bigger or smaller would appear. They also got good data from it too.
Imran, an English man with a high level of charisma said swiping on the Home Screen should feel like moving paper across a table. Part of the paper does stay in one spot, the entire paper moves along with it.
They also had Ken remove the extra suggestions bar because it increased cognitive load. It was adding an extra place to look and removing it increased typing speed. The human brain can only remember 7 things at once.
The back button on the original iPhone was a certain size, but it was smaller than its active area. I could tab right next to the back button and it would still go back. We could implement this for SoulStack.
Make your product so intuitive your child knows how to use it.
Tapping within the keyboard rectangle always resulted in key activation. I decided that if a typist tapped on the keyboard, the goal was to type, so I always gave a result. In the case of a miss, I activated the geometrically closest key to the tap.
We used the word “heuristics” to describe aspects of software development that tip toward the liberal arts. Its counterpart, “algorithms,” was its alter ego on the technical side. Heuristics and algorithms are like two sides on the same coin. Both are specific procedures for making software do what it does: taking input, applying an operation, and producing output. Yet each had a different purpose.
Algorithms produce quantifiable results, where progress is defined by measurements moving in a predetermined direction. An example is the performance of Safari or pressing the spacebar and it making a space without bugs.
Heuristics also have a value or measurement associated with them—the duration to an animation or the red-green-blue values for an onscreen color, but there isn’t a similar “arrow of improvement” that always points the same way. Unlike evaluating algorithms , heuristics are harder to nail down. For instance, how quickly should a scrolling list glide to a stop after you’ve flicked it? How long should it take for an app icon to animate up from its place on the Home Screen to fill the entire display?We always made demos to evaluate the possibilities.
Why do some products, like the iPhone, turn out as well as they do? It comes in theee parts.
1. The demo-making creative selection process. Adding it to the concept of working at the intersection. When we got an idea, we cobbled together a fist cut of the algorithms and heuristics we would need to illustrate it. Then we pulled together the supporting resources—code, graphics, animations, sounds, icons—to produce a demo. Doing this over and over again set our projects on the slow path to accumulating positive change.
2. The seven essential elements (Inspiration which means thinking big ideas and imagining about what might be possible, collaboration, craft, diligence; decisiveness, taste (refined sense of judgement), empathy
3. After creative selection and the seven essential elements, we needed one more intersection to make great work: a combination of people and commitment. Creative selection and the seven essential elements were our most important product development ingredients, but it took committed people to breathe life into these concepts and transform them into a culture. Culture formation works best when it’s small.
In summary: A small group of passionate, talented, imaginative, ingenious, ever curious people built a work culture based on applying their inspiration and collaboration with diligence, craft, decisiveness, taste, and empathy and; through a lengthy progression of demo feedback sessions repeatedly tuned and optimized heuristics and algorithms, persisted through doubts and setbacks, selected the most promising bits of progress at every step, all with the goal of creating the best practices possible.