Creative Selection is an account of how Apple builds product using proof-of-concepts and fast feedback loops via frequent demos. The techniques Kocienda describes are also not unique to Apple. Amazon does something similar and calls it "Working Backwards". Creative Selection is still a good reminder that success takes a lot of trial and error, and a steadfast eye on the goal and customer experience. Here are a few tips from the book: - Empower individuals by delegating responsibilities without micromanaging them. Apple calls this "Directly Responsible Individual" and they're responsible for decisions/delivering the assigned feature/product. Amazon has a similar role they refer to as "Single Threaded Leader" - Early on in the lifecycle focus on building prototypes and demo these to verify they solve the problem. If possible, evaluate existing landscape to find prior/existing solutions. Fred Brooks has a chapter in The Mythical Man-Month called "Plan to throw one away" that recommends a similar approach. The final product is often a distillation and polished version of the prototypes. A key point Kocienda makes is the prototypes should work and not be static mocks. This is to make sure they'll work as expected in real life. The demos help identify potential problems - slow/sluggish-ness, differences in usage, etc. I can't seem to find the story now, but I recall reading the maker of a phone once carried a block of wood with him in his pocket to make sure the form factor worked as expected. In the book he illustrates this with a few examples of this: - While developing Safari separate teams tried Konqueror (KDE) and Mozilla as the base engines for the new browser, to see what could be made to work. KDE ended up winning. During the prootyping phase the team also took shortcuts, such as prioritizing features, hacks such as building a shim to get an E2E demo working. The hacks were for the non-critical parts. - When working on the spell correction Kocienda tried different algorithms and played around with different UIs. - Setup tight (and strong) feedback cycles to ensure anything that's superfluous gets taken out. - Frequent demos to get feedback and polish edges.
Next , Richard resolved to produce a result on the shortest possible schedule . He downloaded an open source project that held genuine promise , the Konqueror code from KDE , a browser that might well serve as the basis for our long - term effort . In getting this code running on a Mac , he decided to make the closest possible approximation of a real browser that was feasible on his short schedule . He identified three features — loading web pages , clicking links , and going back to previous pages . He reasoned these alone would be sufficiently compelling proofs of concept . He then made his shortcuts , and these simplifying choices defined a set of nongoals : Perfect font rendering would be cast aside , as would full integration with the Mac’s native graphics system , same for using only the minimum source code from KDE . He reasoned that these shortcuts , while significant , would not substantially detract from the impact of seeing a browser surf web pages . He resolved to draw together these strands into a single demo that would show the potential of Konqueror . Then , finally , he worked through the technical details , which led him to develop his software shim , since that was the only thing standing between him and the realization of his plan . His thought process amplified his technical acumen .
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.
Over time, I came to the conclusion that designing an excellent user experience was as much about preventing negative experiences as facilitating positive ones.
Charged Buttons: The actual geometry for the back button in the top navigation bar is too small to tap comfortably, so the button is charged, which means the active area the software recognizes for tapping is larger than the visual area for the button.
keeping our development groups small fostered feelings of personal empowerment and a sense of team cohesion.
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.