Once the idea for an app is in place, the first step towards developing it into a real product is to articulate the strategy that will inform all subsequent stages of its design. What are the goals of this app and how do they mesh with the overarching objectives of the publishing organization? How will success be measured? And etc. The next phase is discovery, that is, research into the needs, preferences, and usage patterns of the target user. This may be accomplished with a combination of video recording, surveys, and interviews. Testers of the app may also be asked to keep a diary of their expectations and perceptions for the next step, analysis. At this point, the developing team should shape qualitative and quantitative data from the discovery phase into a portrait of the typical user and activate this persona to inform design. The design phase may also rely on mood boards, paper mock-ups, and non- or semi-functional wireframe prototypes that allow rapid solicitation of feedback from all stakeholders. The design can then be brought to life in production code. A functional beta version of the app can then be cycled back into the discovery phase any number of times to hone the user experience before finally being made available for sale.
The question of whether or not the app is ready for sale depends upon how closely the current, working version conforms to the typical user’s expectations of it, i.e., a consideration based on quality. Thus, this “go or no-go” decision point is the key driver of the entire process. (See Section A2 for more details on quality drivers.) In economic terms, the development team must also ask whether the marginal benefits to the user’s experience outweigh the marginal costs of funnelling the app through another improvement cycle (including the opportunity cost of not immediately making the app available for sale.) Other considerations may also come into play at this point, like timeliness (spurred by a real-world event, like the World Cup or Olympics) and the relative positions of competing apps, though these are beyond the scope of this post.
3. The Gap
Apps built carefully by the UXD process should deliver good user experiences. That is, they should be of good quality. By Slack’s definition, this means that they should consistently conform to consumer expectations. And how could they not, given that the consumer was so intimately involved in developing them?
But what about truly great experiences? What about delight? Is the collaborative UXD process more or less likely to deliver an experience that exceeds the user’s expectations than a genius auteur working alone?
Loren Brichter, creator of the famed Boggle-like puzzle game, Letterpress, wrote a wholesale replacement for UIKit, the Apple-provided programming framework that is “needed to construct and manage an application’s user interface for iOS.” His reasons were to produce absolutely unique letter tile animations, novel touch interactions, and delightfully unexpected game-play. Nobody in his right mind should do this; it is toodifficult, too time-consuming, too costly, and too risky, especially for a programmer working alone. Moreover, it does not align with the UXD process: had beta testers been presented with a version of Letterpress that relied on the standard UIKit instead of Brichter’s replacement, they would, in all likelihood, have been perfectly content with the more traditional look-and-fee of the app. This is because people are generally happy with the familiar. App developers cannot expect their users to imagine the future; instead they must lead them there.
Steve Jobs was famous for saying, “It's really hard to design products by focus groups. A lot of times, people don't know what they want until you show it to them.” This is especially true in technology where everything comes “from the future.” Had Stanley Kubrick followed UXD principles, he could never have made 2001: A Space Odyssey, which was decades ahead of its time, and undoubtedly one of the best, most fascinating, and most enduring movies ever produced.
The gap in the UXD process is that it favours the middle over the great; because it is a collaborative effort that solicits input from a large number of stakeholders, including end users, it cannot fully embrace the singular, directorial vision required to produce a truly unique, transcendent experience.
4. Non-competitive Benchmarking and Addressing the Gap
To most developers steeped in the UXD way, the gap will not be obvious. Many who read this essay will disagree that it is even valid, or, if valid, not important. I believe that they are wrong. I also believe that the solution will not come from UXD itself because its advantages are so great and manifold as to obscure this weakness, which is subtle.
For a possible solution, we must look instead to another industry altogether, an industry where, as in apps, experiences are manufactured de novo – the animated movie industry. If I were to be given a six-month sabbatical tenable at an institution of my choosing, I would spend it at Pixar Animation Studios.
Pixar has been wildly successful. In 1995, it invented the genre of the feature-length computer-animated movie with the release of Toy Story. Since then, its 14 films have earned over $8.5 billion worldwide. It has garnered 27 Academy Awards, 7 Golden Globes, and 11 Grammys. What interests me about Pixar isn’t so much the movies themselves, but the process by which the movies are made, a process that, much like UXD, is deeply collaborative and highly iterative and yet at the same time manages to produce transcendent products that are universally loved by critics and movie-goers alike. How does Pixar consistently deliver critical and box-office smashes and what can app development learn from its processes?
While there are similarities between Pixar’s process and that of UXD, there are important distinctions, too. The most obvious is that, unlike UXD, which asks regular users for feedback, Pixar never solicits opinions of its work in progress from outside the firm. Instead, during the production of a Pixar movie, the director periodically screens development “reels” to what has become formally known as the company’s Braintrust. The Braintrust is an evolving group of “proven problem solvers” – experienced directors and storytellers – who work “magnificently together to dissect scenes that [are] falling flat.” In a candid and non-judgmental way, the Braintrust advises the director on what is and is not working in the film, both in the face-to-face meetings and by way of copious written notes. The goal is to “push towards excellence and root out mediocrity.”
Pixar movies are championed by a deeply motivated director who takes personal ownership of the film. He or she is ultimately responsible for, and free to make, the final cut. Typically, directors are not appointed, but rather rise up organically from within the company. “With few exceptions,” writes Ed Catmull, Pixar’s President, “our directors make movies that they have conceived of and are burning to make.” Thus, Pixar’s films, although collaboratively produced, retain the stamp of a strong, unique creative vision. For example, The Incredibles, directed by Brad Bird, is a very different film, not only in story, but also in visual style, pacing, and humour from Finding Nemo, directed by Andrew Stanton.
The relationship between the director and the Braintrust is one of candour, trust, and respect. However, the director retains ultimate control over the movie and is not required to take the advice given. Thus, Pixar movies benefit from both the collective wisdom ofa best-in-world advisory team and the powerful idiosyncratic visions of their directors. As a final counterbalance, the company’s executive is empowered to replace the director if the movie consistently fails to meet expectations over several iterations (which it has occasionally exercised) or to cancel the production altogether.
A possible way to close the gap presented by UXD, therefore, is to put the process more firmly in the personal control of a capable and motivated director (or, in this context, product manager) with a strong vision for how the app should behave. This is not to throw away the collaborative aspects outlined in Section 2, but to de-emphasize them to the degree that creative risks can be taken in the direction of greatness. That is to say, the app should be allowed to fail. Moreover, without eschewing user feedback altogether, the product manager should take the majority of his or her advice from a close and trusted team of established experts akin to Pixar’s Braintrust. This new “hook” into the UXD process should come at the “Ready?” decision point shown in Figure 2. A revised, expanded version of “Ready?” is presented in Figure 3.
