More on this book
Community
Kindle Notes & Highlights
by
Ken Kocienda
Read between
April 20 - June 29, 2020
If a programmer told Scott about an in-the-works software change to the touchscreen system that would make it possible to reliably differentiate between quick swiping gestures and slower panning gestures, Scott could visualize a user feature like swiping on an item in a list, say an email message, to delete it.
This was part of Steve’s mission for Apple, the most significant strand of Apple’s product development DNA: to meld technology and the liberal arts, to take the latest software and hardware advances, mix them with elements of design and culture, and produce features and products that people found useful and meaningful in their everyday lives.
the way to get admission to these high-level meetings at Apple had much less to do with your place on the org chart and much more to do with your ability to make the products better.
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. I, in turn, used the minimum number of words necessary to direct Steve’s attention further, so he knew exactly what to look at. After that, Steve looked carefully at the software and asked me succinct questions to see if the work could be made simpler.
This push for simplicity had a purpose. Even though he was a high-tech CEO, Steve could put himself in the shoes of customers, people who cared nothing for the ins and outs of the software industry. He never wanted Apple software to overload people, especially when they might already be stretched by the bustle of their everyday lives.
Steve figured that the best way to answer difficult questions like these was to avoid the need to ask them.
He surrounded himself with people like Scott, Greg, Henri, and Bas at least in part because they could make good decisions without long deliberation.
His thought process amplified his technical acumen.
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. I pay them as little attention as possible. Like the inside of the hat shop, I omit them from the demo if I can get away with it. I take
...more
Hard work is hard. Inspiration does not pay off without diligence.
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.
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.
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.”
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.
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.
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. It couldn’t be an even trade-off either. Great products make people happy almost all the time and do the opposite rarely, if at all.
At Apple, we sought to be as empathetic as possible in both the initial and the ongoing experiences with a product, but we realized we couldn’t try everything during our design and development phase. We needed to whittle down the unbounded possibilities for how a product might look and behave, and to do this, we used our design and technological taste.
Just because you can always keep pushing the boundaries, does not mean that you should. Pacing is important and requires good judgement.
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.
Taste is developing a refined sense of judgment and finding the balance that produces a pleasing and integrated whole.
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.
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
people. Product design should strive for a depth, for a beauty rooted in what a product does, not merely in how it looks and feels. Form should follow function, even though this might seem like a strange notion for pixels on a screen, but it’s not if you believe the appearance of a product should tell you what it is and how to use it. Objects should explain themselves.
They introduced me to concepts like Markov chains, conditional random fields, Bayesian inferences, and dynamic programming.
Look into this
During the keyboard derby, we learned that the visual of the key appearing under your finger when you tapped was the keyboard’s way of telling you what it saw. It was exactly the kind of feedback that can connect people and software. The letter pop-ups on the keyboard created a dialogue between the device and the typist, with the pop-ups playing the role of a backchannel, much like the head nods and “uh-huh” and “mm-hmm” utterances we sprinkle through conversations while we listen to other people speak. The stream of pop-ups let a person know the keyboard was following along, that it was
...more
Importance of feedback from the product
the autocorrection algorithm became this: Arrange typed keys in a set of tumblers with their neighboring keys. Spin the tumblers to check every letter combination. Note the dictionary words found by spinning the tumblers. Calculate the pattern skew for every found word. Multiply the usage frequency value for each found word with the reciprocal of its pattern skew. From all the found words, suggest the one with the greatest multiplied total of usage frequency and pattern skew.1
The autocorrect algorithm - this is amazing.
We needed scores of these finely tuned allowances and affordances throughout our software to make our touchscreen operating system intuitive and easy to use.
Link to Design of everyday things
In this kind of test, commonly referred to in the high-tech industry as an A/B test, the choices are already laid out. In this Google pick-a-blue experiment, the result was always going to be one of those forty-one options. While the A/B test might be a good way to find the single most clickable shade of blue, the dynamic range between best and worst isn’t that much. More important, the opportunity cost of running all the trials meant there was less time available for everyone on the development team to dream up a design that people might like two, or three, or ten times more. A/B tests might
...more
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.
I’ve given a name to this continuing progression of demo feedback next demo: creative selection.
We didn’t establish large, cutting-edge software research departments sequestered from, and with a tenuous connection to, the designers and engineers responsible for creating and shipping the real products.
authority and fail to ever reach universally recognized final decisions. You could design for looks, or for fashion, or for some abstract ideal instead of designing for how a product works.
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.
We always started small, with some inspiration. We made demos. We mixed in feedback. We listened to guidance from smart colleagues. We blended in variations. We honed our vision. We followed the initial demo with another and 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.
Creative selection process
Remember, Steve Jobs didn’t say products should thwart the user; he said products should “come to the user.”
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.
As Apple product developers, we were always happy to improve our user experiences by lightening the load of our software.*
Determining comfort levels, pursuing smoothness, and reducing mental load are examples of the kinds of ergonomic, perceptual, and psychological effects we often aimed for, and in each case, honing and tuning technology to a high level became the means to achieve people-centered results.
We always made demos to evaluate the possibilities. I would often sit down with an HI designer like Bas or Imran to make preliminary decisions about gestures and animations, then we would review our preliminary choices in larger groups, then the whole team would live on the results over time. We used the same scheme to develop heuristics for the whole system.
Algorithms and heuristics must coordinate to make a great high-tech product.
which fed into animation code to move the photo display to a specific geometric position to center the next photo (an algorithm) starting from a certain speed, given how fast you swiped (another algorithm),
I never thought about this. Keeping up the illusion of responsiveness is in the details. This would be so weird if i swiped fast but the animation was slow.
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. It was often difficult to decide where an algorithm should end and a heuristic should take over.
This is why dev and design needs to be tight
1. Inspiration, which means thinking big ideas and imagining about what might be possible,
2. Collaboration, which means working together well with other people and seeking to combine your complementary strengths,
3. Craft, which means applying skill to achieve high-quality results and always striving to do better,
4. Diligence, which means doing the necessary grunt work and never resorting to shortcuts or half measures,
5. Decisiveness, which means making tough choices and refusing to delay or procrastinate,
6. Taste, which means developing a refined sense of judgment and finding the balance that produces a pleasing and integrated whole,
7. 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,
