Tarang's Book Highlights

Creative Selection

Ken Kocienda

1. The Demo

In our case, Steve saw something he liked, but he found the demo unnecessarily complicated, so he unpacked it. This deconstruction wasn’t typical, but it was completely in character. Even the discussion Steve used to arrive at his conclusion was spare and minimal. Note how Scott introduced my demo with just enough words to communicate to Steve what was next on the agenda, where he should turn his attention, and who I was.

| Location: 481 | Color: yellow |

Steve believed she’d do better with a product that wasn’t loaded down with every thingamabob the product designers could dream up. He believed that stripping away nonessential 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 their 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? Steve used demo reviews to judge for himself whether features met this basic usability standard.

| Location: 493 | Color: yellow |

We could also take away possible confusion about which keyboard to show in different situations. For example, should the software remember that you used the bigger-keys keyboard in the Notes app and the more-keys keyboard in Mail, and 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.

Notes:

Simple is better

| Location: 501 | Color: yellow |



2. The Crystal Ball

Demos were fundamental to our work at Apple. We used them to highlight the potential, explore the concepts, show the progress, prompt the discussion, and drive the decisions for making our products. I started to understand how demos could play all these roles in creative and technical work when I was surprised by a single brilliant demo during my first few weeks at Apple, a moment that gave me my first real view into how the company made its software.

| Location: 527 | Color: yellow |

Is it possible to understand his accomplishment better, to measure it, to quantify it? It’s tempting to cite Silicon Valley lore and call Richard a “10x programmer,” a super-productive software genius who can add value in multiples of mere mortals.9 Do such people exist? After all, such discontinuities between average and excellent are uncommon in everyday life. The person sitting at the next table in a coffee shop won’t be typing five hundred words per minute on his or her laptop keyboard while you sit at yours typing fifty. The physical world imposes hard limits. This remains true even at elite levels of human performance. No Olympic sprinter will ever cover the 100 meters in less than one second. Do these kinds of limits extend to technology development?

Notes:

Later on in this chapter, the author mentions that in software dev, its the 'wrork smart' part instead of 'work hard' that makes a developer a 10x one. Especially during early stages of prototyping/ideation of a project.

| Location: 788 | Color: yellow |

software demos need to be convincing enough to explore an idea, to communicate a step toward making a product, even though the demo is not the product itself. Like 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 the proper setting, must be realized at the correct level of detail so they contribute to the whole rather than detract from the vision. Richard put this theory into practice.

| Location: 861 | Color: yellow |

In the years since Richard showed me his browser demo, I’ve emulated his approach. When I make a demo, I think about the intended audience, and I make a specific decision about what features to include. I draw a conceptual ring around those key details, and I use a thick imaginary marker to do it. The demo points inside the ring are the focus, and like the lamppost in the movie scene, I depict them with the highest fidelity. I leave outside the ring other less important details that will eventually have to be addressed, but not immediately.

| Location: 870 | Color: yellow |

Over time, Don and I began to understand and absorb the model Richard showed us. Look for ways to make quick progress. Watch for project stalls that might indicate a lack of potential. Cut corners to skip unnecessary effort. Remove distractions to focus attention where it needs to be. Start approximating your end goal as soon as possible. Maximize the impact of your most difficult effort. Combine inspiration, decisiveness, and craft to make demos. We learned all this from Richard. He changed the way we worked.

| Location: 886 | Color: yellow |



3. The Black Slab

We imagined that some parts of the Konqueror code would require an extra amount of programming attention before they would work well on the Mac. We decided to add annotations to the source code, reminders to ourselves to go back later to improve our adaptation of the code in that particular place. Programmers often use such notes. We call them “FIXMEs.” For a big porting job like the one we were about to undertake, we expected to add a lot of FIXMEs. A couple months later, we would be very glad we had made this decision and that we had maintained the discipline to add these annotations whenever we had doubts about a piece of code while we were editing it. Each FIXME was another item on our programming to-do list.

| Location: 1029 | Color: yellow |

Don and Richard endured this build ordeal along with me, and during lunch and coffee breaks we commiserated with each other about how bored we were. We couldn’t fob this work off on junior programmers or interns either. Apple didn’t work like that. Secrecy was one reason, but, more important, Apple didn’t separate research and development from software implementation. We were responsible for coming up with the ideas for our web browser and writing the shipping code that went out to customers too.

Notes:

The silver lining here is that this avoids "Ivory tower" culture amongs senior employees, this Is necessary especially in software where not all senior people know the latest tools that juniors.may be savvy with

| Location: 1062 | Color: yellow |

From this perspective, Edison grossly underestimated. I doubt Edison believed he was proposing a physical law or had any expectations his 1:99 ratio was a universal constant. Even so, his experience taught him something about producing inventions: Hard work was essential.

| Location: 1165 | Color: yellow |

Edison knew the actual story was more about the drudgery. I agree with Edison. Ideas are nothing without the hard work to make them real.

| Location: 1174 | Color: yellow |

Even though Don, Richard, and I struggled with the tedium, we kept plowing through each file and FIXME. Hard work is hard. Inspiration does not pay off without diligence. We collaborated to get through the drudgery. Our knowledge of our craft—code, compilers, software licenses, and debugging—gave us the confidence to forge ahead and to invest and direct the necessary time and effort to make Richard’s demo pay off.

| Location: 1197 | Color: yellow |



4. One Simple Rule

For software developers who take their work seriously, Knuth is the consummate craftsman. Here’s what he has to say about optimization: Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.2 (Emphasis added.)

| Location: 1281 | Color: yellow |

In later years, I would learn more about how Steve prepared for these big-splash product announcements. Three weeks or a month before the keynote itself, Steve would start rehearsing with portions of his slide deck in some venue at Apple, often in Town Hall, the auditorium on the Infinite Loop campus. Slowly, day by day, he would build the show by stepping through it as he wanted to present it at the keynote. This was one of Steve’s great secrets of success as a presenter. He practiced. A lot. He went over and over the material until he had the presentation honed, and he knew it cold.

| Location: 1375 | Color: yellow |

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.

| Location: 1380 | Color: yellow |

After Steve showed the Safari icon, he clicked to the next slide. It had a single word: Why? Steve felt the need to say why Apple had made its own browser, and his explanation led with speed. Some may have thought that touting Safari performance was just marketing, a retrospective cherry-picking of one browser attribute that just happened to turn out well. I knew better. I had been part of the team that had received the speed mandate months earlier, and I had participated in the actions he now described which ensured the speed of our browser. Such connections of words to actions can be meaningful, and in our case they were, since the words led to the actions we used to make our product. This clear connection of words to actions in a product development cycle was new to me.

| Location: 1415 | Color: yellow |

Lombardi waited in front of a portable blackboard as the players sat down. He picked up a piece of chalk and began to speak. “Gentlemen,” he said, “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.”6 He paused and stared, his eyes moving from player to player. The room was silent. “I’m not remotely interested in being just good,”

| Location: 1437 | Color: yellow |

In any complex effort, communicating a well-articulated vision for what you’re trying to do is the starting point for figuring out how to do it. And though coming up with such a vision is difficult, it’s unquestionably more difficult to complete the entire circuit, to come up with an idea, a plan to realize the idea, and then actualize the plan at a high standard, all without getting bogged down, changing direction entirely, or failing outright. Perhaps the most unnerving and fear-inducing source of anxiety is that your ideas, words, and resulting vision might not be any good to start with and wouldn’t yield success even with a faithful follow-through.

| Location: 1475 | Color: yellow |

Back in the early days of our browser project, Steve told us he wanted it to be fast. Don gave us his rule to realize this goal, never make the browser slower, as well as the Page Load Test, the means to accomplish it. Our browser team incorporated the PLT into our daily workflow, and we used the test results to measure and monitor our progress. Around a year later, when we were ready to release Safari, Steve could stand up on stage and, in a straightforward manner, tell the world what we had done. Our speedy browser lay at the end of a long chain linking inspiration to proposal to plan to process to product.

| Location: 1480 | Color: yellow |

It may seem like a stretch to draw a comparison between winning football games in Green Bay and developing web browser software in Cupertino, but a significant part of attaining excellence in any field is closing the gap between the accidental and intentional, to achieve not just a something or even an everything 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.

| Location: 1485 | Color: yellow |

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.

| Location: 1492 | Color: yellow |



5. The Hardest Problem

Sometimes tapping a key would make it reappear, and sometimes not. My insertion point woes were the worst kind of bugs a coder can have, since the bad behavior didn’t always recur if I backed up and took the same steps again. Programmers have a name for such defects. We evoke the uncertainty principle from quantum mechanics and the man, Werner Heisenberg, who developed it. My insertion point glitches were “heisenbugs.” And fixing insertion point heisenbugs was the hardest programming problem I ever tried to solve.

| Location: 1609 | Color: yellow |



6. The Keyboard Derby

Williams asked Steve where he “fit in the American family of thinkers and inventors.” At first, Steve attempted to brush off the question, but when Williams pressed him, Steve said: “I think if you do something and it turns out pretty good, then you should go do something else wonderful, not dwell on it for too long. Just figure out what’s next.”1

| Location: 1741 | Color: yellow |

Even when demos went well, there was always a steady flow of feedback, suggestions for changes, impressions on how the software might behave differently. Everyone spoke up. Demos were an open forum for exchanging ideas about how an interaction might look or function better. When demos went poorly, as sometimes happened, there was the same stream of comments and constructive criticism. There was never any finger-pointing; however, there was an expectation that new demos would include a response to the feedback from previous demos. This was the one essential demo expectation: progress.

| Location: 1866 | Color: yellow |

everyone on the software team was gathered in the main Purple team conference room, which was called Between. Across the hall, there were two other rooms: A Rock and A Hard Place.

| Location: 1993 | Color: yellow |

Exactly how we collaborated mattered, and for us on the Purple project, it reduced to a basic idea: We showed demos to each other. Every major feature on the iPhone started as a demo, and for a demo to be useful to us, it had to be concrete and specific. We needed concrete and specific demos to guide our work, since even an unsophisticated idea is hard to discuss constructively without an artifact to illustrate it.

| Location: 2042 | Color: yellow |

At Apple, we built our work on this basic fact. Demos made us react, and the reactions were essential. Direct feedback on one demo provided the impetus to transform it into the next. Demos were the catalyst for creative decisions, and we found that the sooner we started making creative decisions—whether we should have big keys with easy-to-tap targets or small keys coupled with software assistance—the more time there was to refine and improve those decisions, to backtrack if needed, to forge ahead if possible. Concrete and specific demos were the handholds and footholds that helped boost us up from the bottom of the conceptual valley so we could scale the heights of worthwhile work. Making a succession of demos was the core of the process of taking an idea from the intangible to the tangible.

| Location: 2066 | Color: yellow |

Making demos is hard. It involves overcoming apprehensions about committing time and effort to an idea that you aren’t sure is right. At Apple, we then had to expose that idea and demo to the scrutiny of sharp-eyed colleagues who were never afraid to level pointed criticism. The psychological hurdle only grows taller with the knowledge that most demos—almost all of them—fail in the absolute, dead-end sense of the word.

| Location: 2072 | Color: yellow |

Although we had little collective experience with touchscreen software keyboards before Henri told us to start working on them, that lack of grounding didn’t matter to us. Starting from our hallway meeting, we picked a point over the technological horizon and, together, we set out toward it, unsure if we were headed in exactly the right direction. It was hard to orient ourselves—the touchscreen text entry landscape didn’t exist yet. Yet that’s what innovation opportunities look like. The field was wide open, so, when any of us had a new concept for a keyboard, we made a demo to communicate what we were thinking. Literally, we had to demonstrate our idea. We couldn’t get away with telling. We were required to show. We combined some inspiration, craft, taste, and decisiveness, and we shared our results.

| Location: 2085 | Color: yellow |



7. QWERTY

People who love tech gadgets want new products that do cool new things. This creates the customer demand that gives product developers like me incentive to add new features. Yet none of us wants these products and features to be confusing, to lead us astray, to drive us down a software dead end and dump us there. We’ve all owned devices that had too many ill-considered, overlapping, and inscrutable features, making the products nearly impossible to understand or use. Apple’s whole identity was bound up in not having this problem. Over time, I came to the conclusion that designing an excellent user experience was as much about preventing negative experiences as facilitating positive ones.

| Location: 2203 | Color: yellow |

Great products make people happy almost all the time and do the opposite rarely, if at all.

| Location: 2209 | Color: yellow |

In the introduction to this book, I described empathy as trying to see the world from other people’s perspectives and creating work that fits into their lives and adapts to their needs. Empathy is a crucial part of making great products.

| Location: 2429 | Color: yellow |

As a creative and technical practitioner, I couldn’t open myself to an infinite regress of ideas at every step of accomplishing a task. It’s important to keep making progress and to keep sight of priorities. That doesn’t give product designers the license to ignore philosophy. Rather, in my case, I recognized I’m not a philosopher myself; I’m closer to a carpenter. As a maker of products, I always turned less to the theoretical and more to the applied.

| Location: 2449 | Color: yellow |

Taste is developing a refined sense of judgment and finding the balance that produces a pleasing and integrated whole.

| Location: 2454 | Color: yellow |

I want to mention one characteristic that may seem to be missing from my overall notion of taste—a concern for beauty. My omission of beauty is not a mistake. Making software and products appear beautiful, in the sense of being visually attractive, only goes so far. Steve Jobs once said, “Design is how it works.”

| Location: 2504 | Color: yellow |

as part of a 2003 New York Times interview discussing the iPod, Steve drove his point home: Most people make the mistake of thinking design is what it [a product] looks like. People think it’s this veneer—that the designers are handed this box and told, “Make it look good!” That’s not what we think design is. It’s not just what it looks like and feels like. Design is how it works.7 His message is clear, and I agree with it. Shallow beauty in products doesn’t serve people.

| Location: 2507 | Color: yellow |



8. Convergence

8 Convergence

Notes:

This chapter is quite fun and techical. About the autocorrect approach etc. ReReadable in isolation as well

| Location: 2555 | Color: yellow |

Asking for assistance presented a problem of a different sort. I found out the names of some people at Apple who had experience building dictionaries and creating algorithms for text entry, but they weren’t disclosed on the Purple project, and there was no way to get them clued in on the big smartphone secret. Back in these times, Steve Jobs himself was still playing some role in who got to sign the Purple NDA, and there was no formal system to request disclosures for new people. For good or for bad, that’s not how the Purple project rolled. So, I wound up in the odd situation where I got approval to ask for help, as long as I didn’t tell the people I was asking exactly why I was asking or what I planned to do with their answers.

Notes:

The downside of secrecy

| Location: 2668 | Color: yellow |

No. Convergence isn’t magic. It’s a workaday high-tech development practice. Netscape’s engineers did bug convergence. It’s also what Don and I were doing during our last few days at Eazel, right up until the morning they fired the majority of the staff. Everybody in professional software development does convergence. So, converging a bug list toward zero can’t be the elusive ingredient necessary for making excellent products. The appeal of the iPhone wasn’t the result of piling up a bunch of features early on in our project development schedule, opening the requisite number of bugs to track the implementation of those features, and then converging, fixing them one by one as the schedule led us to ship date.

| Location: 2843 | Color: yellow |

Douglas Bowman, a designer with a résumé that includes stints at Twitter and Wired. He also started at Google in 2006, becoming one of its early visual design leaders.* Here’s how he justified his departure from the web search firm almost three years later: Without a person at (or near) the helm who thoroughly understands the principles and elements of Design, a company eventually runs out of reasons for design decisions . . . Without conviction, doubt creeps in. Instincts fail . . . When a company is filled with engineers, it turns to engineering to solve problems. Reduce each decision to a simple logic problem. Remove all subjectivity and just look at the data. Data in your favor? Ok, launch it. Data shows negative effects? Back to the drawing board. And that data eventually becomes a crutch for every decision . . . Yes, it’s true that a team at Google couldn’t decide between two blues, so they’re testing 41 shades between each blue to see which one performs better.3

| Location: 2851 | Color: yellow |

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. There aren’t any refined-like responses, and there’s no recognition of the need to balance out the choices. Google factored out taste from its design process. At Apple, we never would have dreamed of doing that, and we never staged any A/B tests for any of the 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 were always willing to reconsider previous decisions. We took more time with bigger questions, but never too much.

| Location: 2867 | Color: yellow |

Maintaining headway toward a goal was a key part of the way Apple did software development. It’s fair to say we were always in a convergence period of a sort, even though we didn’t think of it in that way. Yet our forward movement always had a destination. We were constantly converging toward the next demo. The concrete and specific demos I described in chapter 6 were catalysts for creative decisions. They forced us to make judgments about what was good, what needed changes or improvements, and what should be deleted. We habitually converged on demos, then we allowed demo feedback to cause a fresh divergence, one that we immediately sought to close for the follow-on demo. The next demo was never far away, and often it was quite close.

| Location: 2876 | Color: yellow |

We were continuously producing fresh rounds of software like this, to test our latest ideas and assumptions. As a whole, a succession of demos, feedback, and follow-up demos created a progression of variation and selection that shaped our products over time. It’s a Darwinian process, and not surprisingly, Charles Darwin himself was unequivocal about the potential and power of adding up incremental modifications down a line of generations.

| Location: 2883 | Color: yellow |

Working in software meant we could move fast. We could make changes whenever we wanted, and we did. We created new demos that were concretely and specifically targeted to be better than the previous one.

Notes:

This is what makes software so great. Super fast iteration can quickly produce magical things

| Location: 2899 | Color: yellow |

We gave each other feedback, both as initial impressions and after living on the software to test the viability of the ideas and quality of the associated implementations. We gathered up action items for the next iteration, and then we forged ahead toward the next demo. I’ve given a name to this continuing progression of demo -> feedback -> next demo: creative selection.

| Location: 2902 | Color: yellow |

we didn’t have a formal name for what we were doing while we were doing it. We were always so focused on the next demo, the next review session, the next time we were scheduled to show progress to Steve. Our iterative working method was like the air—something all around us all the time, something we were always aware of on some level, something it didn’t make sense to question. Yet we took our approach for granted more than we should have.

| Location: 2907 | Color: yellow |

Consequently, our success was as much about what we didn’t do as what we did. Mostly we avoided falling into any of the typical product development traps common in Silicon Valley and that, I expect, occur often in other kinds of creative organizations and businesses. For example, we didn’t take two-hour coffee breaks or hold daylong offsite confabs to talk about projects without examples to ground the discussion—we didn’t have lengthy discussions about whose imaginary puppy was cuter.

| Location: 2911 | Color: yellow |

We didn’t have an imbalance between influence and involvement, where a senior leader might try to mimic the commanding role of Steve Jobs without the corresponding level of personal engagement. Detached high-level managers making all the key decisions is such a widespread affliction that it has its own internet meme, the Seagull Manager. It describes a top executive who is rarely around but flies in occasionally and unexpectedly from who knows where, lands on your beach, squawks noisily, flaps its wings all over the place, launches itself back into the air, circles overhead, drops a big poop on everyone, and then flies away, leaving the rest of the team to clean up the mess, figure out what it all meant, and wonder what to do about the inevitable follow-up visit.5

| Location: 2921 | Color: yellow |



9. The Intersection

“The Intersection,” the title of this chapter, was an idea that helped us. It speaks to the way Apple valued expertise in both technology and liberal arts. We used this notion to guide our efforts as we developed and lived on our gadgets, so that they turned out to be more than an agglomeration of the latest CPUs, sensors, and software manufactured at scale. We hoped to make our products meaningful and useful to people. Unlike the unspoken idea of creative selection, we did talk about “working at the intersection” among ourselves. There was even a formal Apple University† course on the topic—a moderated half-day session to discuss melding technology and liberal arts, the reasons it might be difficult to work at this intersection, and why it was essential to keep trying, since the effort lay at the core of the Apple notion of a great product.

| Location: 2969 | Color: yellow |

Steve Jobs told everyone what he thought about this topic himself, on stage, during the keynote presentation to announce the original iPad: The reason that 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.2

| Location: 2979 | Color: yellow |

Scott Herz, one of my Purple teammates, soon gave us the answer. He wrote an app and circulated it around the Purple team. There wasn’t much to it. The app launched showing a very large Start button. After tapping that button, the screen would go blank for a moment, then a box would appear somewhere on the display. The goal was to tap the box. After you tapped, whether you succeeded or failed, and after another momentary blank, another box would appear somewhere else. Only this next box would be a different size, maybe larger, maybe smaller. Tap the box. Tap the box. Tap the box. Honestly, it was fun. Like a game. After twenty or so boxes and taps, the “game” would end, and the app would show you your score: how many boxes you hit and how many you missed. Behind the scenes, the software tracked the sizes of the boxes and their location.

| Location: 3027 | Color: yellow |

Within a few days, we had quite a bit of information about tap-target sizes and accuracy. The results of Scott’s game showed that if we placed a box on the screen that was fifty-seven pixels square, then we could put it at any location—high, low, left, or right. If we did that, then everybody could tap the box comfortably, with near 100 percent accuracy.

| Location: 3035 | Color: yellow |

George A. Miller of Harvard University in 1956.6 Miller wanted to quantify the constraints on our short-term mental capacities. He found we can hold only around seven items in our working memories at once. That’s it. Trying to handle more than sevenish things in our minds simultaneously requires us to start making chunks or, as Miller puts it, to create “groups of items that go together.” For example, I have no trouble remembering these seven colors in order: red, white, blue, cyan, yellow, magenta, black, since the first three are the colors of the American flag and the last four are the colors commonly used in offset lithography. I can chunk them together easily because of my nationality and my knowledge of printing processes. Even for random data, it’s easier to recall these nine numbers, 984–313–552, than these, 847620475, just because of the visual prechunking cues provided by the dashes. However, if we can’t free up slots in our mind by making chunks when a lot of information is coming at us, we become overloaded, and once our working memory is filled, we begin to make more errors and less accurate judgments. Our ability to function falls off fast. My experience making products has taught me that this limit is real.

| Location: 3109 | Color: yellow |

Interacting with technology, especially when it’s new or tricky, creates the same kind of burden as my listing quiz. We soon hit our mental boundaries, and it doesn’t take much to knock our minds off course when we’re navigating in a sea of complexity. We can easily get lost in software features, and if that happens, we don’t have enough intellectual capacity to find solid ground and focus on what we’re actually trying to do.

| Location: 3118 | Color: yellow |

To make products more approachable, designers must lighten the load on people trying to use the things they make. Even small simplifications make a difference. The good news is that I think it’s almost always possible to streamline tasks to make them less taxing.

| Location: 3122 | Color: yellow |

When I demoed two potential iPad keyboard layouts—the more-keys layout designed by Bas and the bigger-keys option I made—Steve Jobs realized we could eliminate the choice, reduce the number of things iPad users might try to juggle in their minds while typing text, and so make the product easier to use.

| Location: 3131 | Color: yellow |

Why do some products, like the iPhone, turn out as well as they do? I’m now ready to offer my complete answer. It comes in three parts.

| Location: 3305 | Color: yellow |

The first part is the demo-making creative selection process. Adding it to the concept of working at the intersection, I can enhance my description of how we created variations as we developed a product.

| Location: 3307 | Color: yellow |

The second part of my answer goes back to the introduction, where I first mentioned the seven essential elements of the Apple development approach. By now I hope you can see how essential they were and how they provided us with the raw material for creative selection. Here’s the full list of the seven essential elements again, and this time, I’ve supplemented them with specific examples drawn from my stories: Inspiration, which means thinking big ideas and imagining about what might be possible, as when Imran saw how smooth finger tracking would be the key to people connecting to iPhone experiences through touch Collaboration, which means working together well with other people and seeking to combine your complementary strengths, as when Darin and Trey helped me make the insertion point move correctly in WebKit word processing Craft, which means applying skill to achieve high-quality results and always striving to do better, as when the Safari team made the web browser faster and faster by running the Page Load Test, trying to understand what this test program told us about our software, and using these findings to optimizing our code Diligence, which means doing the necessary grunt work and never resorting to shortcuts or half measures, as when we persisted through the tedium of fixing cross-references to get Safari to build in the lead-up to the Black Slab Encounter Decisiveness, which means making tough choices and refusing to delay or procrastinate, as when Steve Jobs made me pick the better keyboard layout for the iPad on the spot while he waited rather than just offering the two different designs Bas and I developed Taste, which means developing a refined sense of judgment and finding the balance that produces a pleasing and integrated whole, as when we made the choice to offer a QWERTY keyboard layout for the iPhone Empathy, which means trying to see the world from other people’s perspectives and creating work that fits into their lives and adapts to their needs, as when Scott Herz made a game to find the best size for touch targets so it was comfortable to tap the iPhone display and accommodated people with varying levels of dexterity

| Location: 3315 | Color: yellow |

This brings me to the third part of my answer. 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.

| Location: 3349 | Color: yellow |



Epilogue

As we look for new solutions to new problems, I suggest we turn to the tools I’ve described—the essential elements, creative selection, and a culture built around them. Naturally, it’s possible to use any set of tools to do excellent or shoddy work, or to employ them to achieve worthy aims or trivial ones. We should choose wisely, because the iPhone demonstrates the societal impact a successful product can have, both good and bad.

| Location: 3554 | Color: yellow |

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.

| Location: 3557 | Color: yellow |