Creative Selection: Inside Apple's Design Process During the Golden Age of Steve Jobs

I was excited about diving in this weekend into Creative Selection by Ken Kocienda, a new book providing a detailed look inside the design process at Apple. And Creative Selection did not disappoint. While much has been written about Steve Jobs and Apple, I found Creative Selection particularly insightful because it provided a vignette into the development of the first iPhone, and in particular, one of it's most critical features - the keyboard - from the perspective of Ken Kocienda, the software engineer ultimately responsible for developing it. Ken goes through the many challenges and subsequent iterations to address those challenges with building the first keyboard to be presented only on a glass display. And in doing so, it showcased how Apple's design and development process was different from traditional Silicon Valley companies in subtle yet incredibly important ways.Ken distills the Apple development approach that ultimately made them successful to seven elements: inspiration, collaboration, craft, diligence, decisiveness, taste, and empathy. And he walks through what each of these elements means to him with detailed stories exemplifying each.But I wanted to share some personal observations I took away from the book on how Apple built products in such a fundamentally different way.Ken describes the process by which they would prepare product demos for their own team and then for various leaders, use that demo as the primary avenue for feedback, and then continue to iterate to the next demo, followed by more rounds of demo feedback, and so on. He calls this process creative selection. While at the surface this may sound like a typical product review process that many companies have, there was so much that was different about it.First, demos were done early and often, even at the prototype stage. These were not just reviews at the end of the process to get final approval, but instead they were done to show early progress, determine viability of the project, and make fundamental design decisions. The goal was to produce an initial prototype to demo as quickly as possible and then continually refine the prototype through subsequent feedback sessions. These demo sessions with senior leaders happened on a weekly basis, not months apart.And in contrast to so many classic reviews where leaders are largely concerned with ensuring projects are on time, that there are no unaddressed bottlenecks, and that the team is executing on the right strategy, leaders at Apple in fact played the role of arbiters of taste. Ken defines taste as developing a refined sense of judgment and finding the balance that produces a pleasing and integrated whole. And in these reviews, leaders would often be making calls on the spot on design decisions for the product. Ken retells the story of many reviews with Scott Forstall, who was head of iPhone software, and Steve Jobs himself who would make critical decisions to remove UI elements, to pick amongst a few design directions that the team was presenting, and to cancel efforts entirely, all based on the context and feedback they got from the presenting team, their own first-hand experience with the demo, and their ultimate sense of taste. This feedback was highly respected by the team and didn't feel like classic executive swoop-ins because of how deeply involved the senior leaders were on a weekly basis with engaging in-depth with the product during these demos.The nature of these meetings also looked so different from traditional exec meeting topics with discussions around market opportunity, competitors, resourcing, etc. They were instead fundamentally about the design and user experience. And each leader would play with the product themselves just as a user would to really connect with the product experience.Equally important to their process was extreme product dogfooding, which they called living on the product. They understood that even after making initial product decisions in these demo reviews, they needed to continue to experience the product on a daily basis to ensure the experience was actually satisfying. And in doing so, they would continually come up with feedback from amongst the team who was living on the product, and incorporate that feedback into the product. Ken shares how each change he made to the keyboard auto-correction capabilities would be rolled out to the small team of iPhone software engineers and how the feedback directly from those individuals shaped his future iterations. I do regularly see a disconnect in product quality emerge when the product, design, and engineering teams aren't using their own product on a daily basis.And finally, the teams tasked with owning critical software components were very small empowered teams of individuals. Each component would have a DRI - a directly responsible individual - who was ultimately on the line for producing that component. And there was a fundamental belief that small teams did the best work, because they were empowered to do so. Ken was the DRI for the iPhone keyboard and worked directly and closely with an associated designer. Glaringly absent from these teams were in fact product managers. The responsibility instead was divided amongst the engineers, designers, a program manager for project management support, and the senior leader. By empowering these very small teams they had the ability and motivation to do their very best work.I would encourage you to check out the book for yourself as it was a fascinating glimpse into the design process of one of the world's most innovative product companies: Creative Selection by Ken Kocienda.

Nicely done Mr. Kocienda, nicely done, and I don't just mean this book, the excellent software as well.I read this almost in one sitting, it reads like a thriller novel for programmers.Every professional programmer should read this, at times it really describes how it is to work in and within the bounds of a software organization.I didn't like the simplification which were used to describe techical situations, but that's only because I wanted to hear more about what Mr. Kocienda and his colleagues did next.Great piece.

I enjoyed this book since it goes into Apple's history, but I think the author is reading way too much into the process. I don't think that this "creative selection" process is actually what made Apple products great. Apple was successful because Steve Jobs and Scott Forstall knew how to lead.Giving demos (aka "Creative Selection") seems like a simple trust building exercise. It could have been any number of things, I assume it just so happened to fit Steve's management style (after all he started off by giving demos at computer expos) so that's what he decided to do since that's what he knew best. I don't think you need to read into it more than that. Like, sure, it's a great way to give/receive feedback, demos are quite fun. But it also could have been like, I dunno, something else too. And that probably would have been fine as well.

Creative Selection, Inside Apple’s Design Process During the Golden Age of Steve Jobs, by Ken Kocienda is well written and a thoroughly enjoyable read regarding Apple’s constant reiterative demo process, where Apple creates concrete and specific demos so peers can make judgements/comments/criticisms/improvements based off actual ‘physical’ samples. Substantial work is put into each demo, similar to the way ideas are pitched at Amazon in detailed memo form, rather than simple power point presentations. Unlike Amazon memos that are polished, complete plans, Apple demos are down and dirty focusing on the specific area/item being demoed, with the background staged (potentially a Hollywood-type façade) to engross to the viewer into experiencing the demo portion as if the viewer is using the complete product. The comprehensive due diligence/research involved in creating the demo (or memo for Amazon), helps to continually refine the idea.Concrete, specific demos allow peers to discuss the item being created in explicit detail, and offer distinct criticisms and suggestions. Ken Kocienda presents an interesting illustration of the importance of having a specific ‘physical’ item to discuss and critique. He uses puppies as an example. Think of a cute puppy in your mind and imagine as many details about your puppy as you can. I’ll think of one as well, I bet my puppy is cuter than yours. Under this scenario, we both have imagined cute puppies, but there is no way to distinguish which one is cuter. We can argue as we each describe our puppy, but we cannot resolve which is cuter without concrete and specific examples. However, if we have physical pictures of each puppy, we can easily discuss their actual merits. This example is relatively silly, but it demonstrates the importance of concrete examples. Without them the theoretical argument is virtually impossible, with them the discussion is efficient and relatively simple.The production of the demos at Apple forces the creator to get a true understanding of the underlying issues with his creation. The comments/criticisms received from peers utilizing the physical demo (rather than discussing theoretical images) are integrated into the following demo version. Each demo, building on all prior work. The best ideas survive, while the weaker ideas go extinct. From these constant, reiterative improvements, magical, one-of a kind generational products have been created.