When we think about Apple, the first things that usually come to mind are minimalist design, the iPhone, the MacBook, or maybe Steve Jobs.

But what has always been more interesting to me is what happens behind these products — the small decisions, technical discussions, failures, experiments, and endless iterations.

Creative Selection, written by Ken Kocienda, takes you into exactly this hidden side of Apple.

Kocienda, who worked as a software engineer at Apple for many years, shares his firsthand experience building products such as Safari and the iPhone keyboard, as well as working with Steve Jobs.

For me, this book is less about programming and more about how to build a great product — and how a team can go through dozens of ideas and possible solutions to eventually arrive at something that feels simple and obvious.

What is Apple’s culture like from the inside?

One of the things that caught my attention early in the book was Kocienda’s description of a meeting room called Diplomacy.

It wasn’t particularly impressive: old furniture, dirty whiteboards, and an environment that felt more like an ordinary, slightly worn-out room than a place where billion-dollar product decisions were being made.

But that contrast says something important:

The focus is on the product, not on the environment where the product is being made.

Kocienda describes seven qualities that were deeply embedded in Apple’s product development culture. I think they’re especially relevant for anyone working in design and product development:

Inspiration, Collaboration, Craft, Diligence, Decisiveness, Taste, and Empathy.

Together, these qualities form what I think is the central idea of the book:

Creative Selection.

So, what exactly is Creative Selection?

The idea is actually pretty simple.

Instead of trying to come up with the “final idea” from the beginning, you build different versions, try them out, critique them, keep what works, and build the next version.

In other words, a product isn’t created in a single moment.

It’s gradually selected.

The process is a lot like natural selection. Each new version grows out of the previous one. At every stage, some ideas are removed while better ones are strengthened.

This idea felt very familiar to me as a product designer.

A lot of the time, the best solution isn’t the first thing that comes to mind. You have to build a few versions, put them next to each other, look at them, test them, and let the product show you which direction works better.

When Steve Jobs asks: “Which one would you choose?”

One of the most interesting examples in the book is the design of the iPad keyboard.

The team was considering two approaches: smaller and more numerous keys, similar to a laptop keyboard, or fewer, larger keys.

During one of the meetings, Steve Jobs looked at Kocienda and essentially asked him to make the decision.

Not to present more options.

Not to say, “We need to investigate this further.”

Just:

Which one would you choose?

This part reminded me of one of the most important aspects of working on a product: ownership.

Sometimes, as designers or product team members, we get so caught up in collecting opinions and comparing options that we forget that eventually, someone has to make the decision.

Being decisive doesn’t mean you’ll always make the right choice.

It means being willing to take responsibility for making the choice.

Safari: When everything started with a black rectangle

One of the most fascinating parts of the book for me is the story of how Safari came to life.

Apple initially had two technical paths to consider.

One was Mozilla, a huge project with around 1.5 million lines of code.

The other was Konqueror, which had roughly 120,000 lines of code and was much smaller and more lightweight.

The problem was that Konqueror had been built for Linux.

Instead of immediately dismissing it, Richard Williamson decided to build a shim — a software layer that could make the Mac believe that the Konqueror code could run on it.

And the result was surprising.

The initial demo worked in just two days.

But this was still far from being a finished product.

The first time Safari successfully loaded the Yahoo homepage, almost all the team could see was a black rectangle.

From the outside, it might have looked like a failure.

But for the team, that black rectangle proved something important:

The path they had chosen could actually work.

And that’s when the hard part really began.

Inspiration isn’t enough without persistence

Kocienda refers to Edison’s famous idea of “1% inspiration and 99% perspiration” and gives a different perspective through the Safari project.

There were roughly 16 hours of initial inspiration and ideation compared with around 1,200 hours of engineering and refinement.

For me, this was one of the biggest takeaways from the book.

We tend to romanticize the moment of inspiration. But a huge part of the final quality of a product comes from hours of work that nobody ever sees.

Fixing a detail.

Testing again.

Removing a feature.

Optimizing something.

Investigating a bug.

And repeating the whole process.

The final product might look simple, but simplicity is usually the result of a lot of work, not less work.

The iPhone keyboard: When glass had to feel like a button

One of Apple’s biggest software challenges was probably the iPhone keyboard.

There were no physical buttons anymore. Users had to type on a glass screen — a surface that couldn’t provide the physical feedback of pressing a real key.

Even inside Apple, this was considered a highly risky project.

The solution wasn’t simply a better autocorrect algorithm. The team had to understand human behavior and model it in software.

That’s why several techniques worked together.

Autocorrect helped predict what the user intended to type, even when their finger didn’t land exactly on the right key.

Behavior modeling allowed the system to consider what the user was trying to do, rather than looking only at the exact location of the touch.

And finally, there was visual feedback — the familiar bubble that appears when you tap a key and gives you immediate confirmation that the system has registered your input.

For me, this was a great example of Empathy.

Empathy in design isn’t just about knowing what users want.

Sometimes you need to understand what the user is feeling in that exact moment, and how the system can give them confidence that it understood them correctly.

“The product must not get slower”

One of the strict rules Steve Jobs had for Safari was that the product shouldn’t get slower.

Whenever a new feature introduced a performance cost, the team had to optimize something else to compensate for it.

This way of thinking feels very relevant to product design too.

We’re constantly adding things:

A new feature.

A new animation.

A new state.

A new message.

A new option.

But the important question is:

What does every new thing we add break?

Sometimes a product gets better not because of what we add, but because of what we remove.

Kocienda also explains that Apple didn’t obsess over every part of the system equally. The team focused heavily on the small percentage of the product that users could actually feel.

That was another important lesson for me:

Everything doesn’t have to be perfect. The things users actually experience need to be.

When more code isn’t the solution

Another interesting part of the book is about a difficult problem in the text editing and email system.

The team was dealing with mysterious, unpredictable behaviors — the kind of bugs often referred to as Heisenbugs.

Eventually, the solution didn’t come from writing more code.

Kocienda worked with his colleagues, including Darin and Terry, and approached the problem from a different angle. They eventually developed a new structure called VisiblePosition.

Instead of patching the complicated behavior of the existing system, they changed the mental model they were using to understand the problem.

This was probably one of the most useful lessons in the entire book for me:

When a system becomes too complicated, the answer isn’t always more code.

Sometimes you need to step back.

Reorganize the information.

Change the mental model.

And redefine the problem in a simpler and more visible way.

The same thing happens in design.

When a UI becomes too complicated, adding another component or another exception usually doesn’t solve the real problem.

Sometimes you need to go back and ask:

Why did we build the system this way in the first place?

What I took away from Creative Selection

For me, Creative Selection ultimately isn’t a book about Apple or Steve Jobs.

It’s more about a way of thinking.

A mindset that says a great product doesn’t come from one brilliant idea appearing out of nowhere. It comes from a combination of inspiration, building, testing, failing, critiquing, removing, and building again.

And maybe more importantly, great products happen where technology meets the humanities.

Where Craft makes us care about the details.

Taste helps us understand which choice actually feels right.

Empathy makes us see the world through the user’s eyes.

Collaboration helps us solve problems that we couldn’t solve alone.

And Diligence keeps us going after we’ve already found the first working solution.

The biggest thing I took away from this book is that product quality usually isn’t created through big, dramatic decisions.

It’s created in the details.

In the things users might never consciously notice, but would immediately feel if they were missing.

A pixel.
An interaction.
A word.
A millisecond.

And maybe that’s what great product design is really about:

Taking a complex decision and making it feel simple and natural to the person using the product.