Loved how this book described the general design process at Apple. Leave people responsible for their own projects. Heuristics are more important than algorithms. Better to develop a refined taste than let data decide everything.
#Things to consider
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- We rarely had brainstorming sessions. I recall only a few times in my entire Apple career when I stood around to rough out big plans at a whiteboard.
- Over time, I came to the conclusion that designing an excellent user experience was as much about preventing negative experiences as facilitating positive ones.
- Great products make people happy almost all the time and do the opposite rarely, if at all.
- He showed that it was possible to make technical headway by skipping past the problems he couldn’t solve in favor of those he could.
- 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.
- 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. We were always mindful of making steady progress.