More on this book
Community
Kindle Notes & Highlights
by
Ken Kocienda
Read between
July 5 - July 13, 2020
The point is that concrete and specific examples make the difference between a discussion that is difficult, perhaps impossible, to have and one that feels like child’s play.
Demos made us react, and the reactions were essential. Direct feedback on one demo provided the impetus to transform it into the next.
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.
Whiteboard discussions feel like work, but often they’re not, since it’s too difficult to talk productively about ideas in the abstract.
We had to work like this, because the team didn’t accept anything unless it was concrete and specific, a demo showing what we meant.
work. I had to constantly ask myself whether what seemed like a good solution to me was actually a good solution. I didn’t know. Typing on a small sheet of glass was new.
Obviously, he had none of the emotional connection I had to my keyboard. While I had been working hard on it, for Phil it was brand new, and he was indifferent to it.
It didn’t matter. Even though Richard’s actual keyboarding was riddled with errors, it was close enough to what he wanted that the software could fix all his mistakes.
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.
Yet when it comes to making products, philosophical discourse is the wrong tool for the job when practical decisions are needed.
Taste is developing a refined sense of judgment and finding the balance that produces a pleasing and integrated whole.
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.
Design is how it works.
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
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.
We always made quick choices about small details, but we were always willing to reconsider previous decisions.
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.
We didn’t shuffle around printed specifications or unchanging paper mock-ups for weeks on end, waiting for an epiphany that would jump us directly from an early-stage concept to a complete product design, hoping we could somehow flip the ratio of inspiration to perspiration Thomas Edison spoke about, the relationship between the time it takes to get an idea and the amount of hard work it takes to transform that idea into something real. I learned my lesson on this count, and in my Apple career, never again did I spend a week of my time to make anything like that fifty-step Building the Lizard
...more
We managed to steer clear of all such pitfalls. If I were to take a stab at explaining the why, I would say that our clarity of purpose kept us on track, in much the same way that Vince Lombardi won football games and Steve Jobs pushed us to make a speedy first version of Safari.
Since our focus on making great products never wavered—if for no other reason than that’s what Steve demanded—perhaps concentrating keenly on what to do helped us to block out what not to do.
Liberal arts elements and state-of-the-art technology must combine, and the end result can be judged only holistically, by evaluating how the product fits the person.
The Mac and the mouse helped to establish the Apple tradition of using new technology to solve age-old interaction problems, and this approach served as inspiration for many years to come.
Indeed, Imran always knew exactly what he wanted, and he was perfectly clear when it came to communicating his design goals for the products we were developing.
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.
Similar possibilities to simplify almost always exist in real product development, and at Apple, we went looking for them.
As Apple product developers, we were always happy to improve our user experiences by lightening the load of our software.
Scott Herz found the threshold that made targets comfortable for people to tap. Imran wanted smoothness in the user interface because it helped to connect the pixels on the screen to people’s real-world experiences. Scott Forstall told me to eliminate the keyboard suggestion bar to lighten the mental load on people.
It’s curious how lawyerly descriptions of the iPhone fail to communicate any of the good feelings we, on the Purple development team, tried so hard to put in. But, of course, patents are not written to put smiles on people’s faces.
We arrived at our final decisions only with judgment and time. Heuristics are like this. They’re subjective.
Algorithms and heuristics must coordinate to make a great high-tech product. Fast web page loads, correct insertion point movement, efficient code, lovely animations, intuitive gestures, and well-considered built-in behaviors are all essential in a product like the iPhone. Our goal was comfortable technology and computer-enabled liberal arts, a combination of both.
This is what working at the intersection is all about. These examples should clarify why we always made so many demos. The photo-swiping example, in particular, should explain why you can’t “engineer” a product in one phase and then slap on “look and feel” in another.
Our goal was to orchestrate a progression of algorithms and heuristics to create great products that would put smiles on people’s faces and would function well without fuss. Design is, after all, how it works.
he had been looking forward to the announcement for two and a half years.
while he knew my work, he didn’t know who I was. In the aftermath of the biggest Apple keynote ever, I walked up to The Man himself, and he looked right past me. That was disappointing.
Repeat, then repeat again. Doing this over and over again set our projects on the slow path to accumulating positive change. This is how we started with an idea and finished with software for a product.
We tried to be tasteful and collaborative and diligent and mindful of craft and the rest in all the things we did, all the time. Everything counts. No detail is too small.
ingredients, but it took committed people to breathe life into these concepts and transform them into a culture.
There was a pragmatic management philosophy at play here, which started from Steve on down.
The communication paths among our few team members became well traveled, and these tracks became like ruts in a road, easing the journey to our desired destinations. We always tried to reach those destinations as quickly as we could, with a minimum of dithering and delay.
This last point speaks to the first important lesson I learned about product development at Apple, the revelation that results could be achieved more quickly than I had previously thought.
From the moment Don and I saw Richard’s crystal ball version of Konqueror, we were willing to invest ourselves in the Apple-style get-it-done product development culture. We weren’t alone either. The other people who found their way to Cupertino around the same time I did got the chance to participate on some outstanding projects, and when we recognized the opportunity, we banded together through our work, and we just kept going.
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 products possible.
meaning that the quality of the result is mostly in the quality of the doing.
This shouldn’t be surprising, given that it’s a matter of people, their tools, and what they choose to do with them.
He pronounced himself satisfied, and I was once again impressed by his ability to surrender his own idea when presented with a different one that worked.
The biggest lesson I learned as I wrote this book is how a group of people and the culture they create are one and the same.
As I write, I still feel a strong bond to Apple, its products, and the people I worked with in more recent years, but it was time for me to move on.
It was a pleasure to look at that code—and spend a few hours with it—one last time before I departed.
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.
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.
