Abstract
This essay discusses the process of developing mobile applications (apps) following the principles of user experience design (UXD). The inputs to the process are ideas (the basic idea of what the app is and the problem it solves for the user – its “job to be done” – as well as other ideas of how it should look and behave, etc.) The output is an app made publicly available for sale.
The journey taken by the ideas as they slowly become corporeal involves iterative design, coding, and testing cycles that are guided by an obsession with enabling the user’s favourable experience of the app, which, for the purposes of this essay, is synonymous with quality. The aspects of quality by which the UXD process is driven are utility, ease-of-use, responsiveness, intuitiveness, context, and simplicity.
From the end user’s point of view, the UXD process in mobile app development is one of low volume, high variety, high variability and low visibility.
This essay proposes that there is a deficiency, or "gap," in the UXD process, which is the following: although standard UXD principles and methods should consistently produce apps that deliver good user experiences, truly transcendent apps are more likely to come from genius developers working alone. This essay discusses the reasons for this shortcoming and proposes a solution based on processes developed by Pixar for the production of critically acclaimed animated movies.
“The goal is to create an unparalleled seamless experience.”
“We’ve been hard at work since the last I/O evolving our platforms so developers like you can build amazing experiences.”
“We set out to create an experience that’s inspired by people, an experience that gets you closer to the things and people that matter most in your life, one that’s a little bit less like technology and a lot more about you.”
1. Introduction to User Experience Design (UXD)
The German luxury car manufacturer BMW claims that its vehicles deliver the “ultimate driving experience.” To BMW owners and car aficionados, driving is not merely a mode of transportation, but an experience bundled with every journey – an experience carefully enabled by the manufacturer in the myriad of design decisions that combine to produce the look, feel, and performance of the vehicle and the pleasurable, exhilarating feelings that these instil in the driver. Nothing is left to chance: everything from the texture of the steering wheel, to the tuning of the suspension, to the purring obedience of the engine is exquisitely orchestrated.
The idea that products are experienced rather than merely used in a strict utilitarian sense has also risen to prominence in the context of software development, particularly in the mobile application (app) space. Portable computing devices, primarily phones and to a lesser extent tablets, are always on, always connected, and always within arm’s reach. Even more than our wallets, they accompany us everywhere; we are in physical contact with them more often and for longer periods than with any other object, more than any single item of clothing (save, perhaps, our glasses) and, in all likelihood, more than any person, even our spouses and children. They are intensely personal, infinitely adaptable, and indispensable. Indeed, they have become projections of ourselves outside our bodies. We manipulate the apps that run on these devices directly with our fingertips, as if they were actual, three-dimensional objects subject to the laws of Newtonian mechanics, for our brains cannot distinguish between what is under the glass and what is in the real world. For all of these reasons, it has become of paramount importance that software developers – like BMW designers, engineers, and marketers – craft compelling user experiences lest their apps suffer ignominious disregard in the market.
In the context of mobile application development, user experience design (UXD) is the process of making software that is guided by how the user perceives and engages with the app while at the same time addressing the limitations and advantages of the small-screen, multi-touch hardware, the challenges of battery life and computing performance, and the framework of generally accepted idioms for interacting with the operating system. The process is not about designing the user’s experience itself (because that is subjective and impossible to control: the user will always bring her individual culture, history, thoughts, feelings, and expectations to the interaction), but rather about designing the app so as to enable as much as possible her favourable experience of it. The goal of UXD is to enhance customer engagement and loyalty by improving the interaction between the user and the product, that is by thoughtfully designing every possible detail to favour a pleasurable user experience.
Setting aside her individual culture, history, and expectations, the user’s perception of an app may be thought of as a view through a stack of virtual semitransparent panes corresponding to the various visual, audible, and functional aspects of the software (Figure 1). Therefore, the process of UXD is a multidimensional optimization problem that draws upon eclectic fields and is best suited to collaboration between (groups of) people with diverse talents. The overall design is an harmonious synthesis of form and function that relies upon programmers, information architects, interaction and interface designers, sound and graphic designers, behavioural analysts, copy writers, selected beta testers, and users in the wild, among others.
Figure 1. Dimensions of a user’s perception of a mobile app. The closer a pane is to the “top” of the stack, the more the user is consciously aware of it.
From the end user’s point of view, the UXD process in mobile app development is one of low volume, high variety, high variability and low visibility (see Section A1 for a thorough discussion.)
The UXD process is driven primarily by quality. For the purposes of this essay, the dimensions of quality are: utility, ease-of-use, responsiveness, intuitiveness, context, and simplicity (see Section A2 for a thorough discussion and definition of these terms.) This essay discusses UXD generally rather than its application in the development of a specific app.
2. High-level Overview of the UXD Process
The UXD process is best described as a project process in which the process flow is intermittent and the process tasks are diverse and complex; they are also incompletely specified and subject to change. The project has a well-defined start (an idea) and finish (a polished app available for sale) and takes a long time to complete; it may proceed by many iterative improvement cycles in which beta versions of the app are modified by the experiences and feedback of test users. It is characterized by low volume and high variety (see Section A1). A high-level overview of the process is mapped in Figure 2.
Figure 2. High-level overview of the UXD process. Rounded rectangles represent the beginning and end of the process with associated input and output; Circles show operations, and the diamond a decision point.
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.
Figure 3. Proposed revision of the UXD process. This set of operations and decision points replaces “ready?” in Figure 2; everything outside the hatch marks (//) remains the same.
Once a beta version of the app has been developed, it should be demoed to the Braintrust, which should include the executive team. The executive should decide whether sufficient progress towards excellence has been achieved. If not, a decision should be made about subsequent action. Is it better to kill the project outright, or to replace the product manager? If sufficient progress has indeed been made, the Braintrust should furnish the product manager with verbal advice and written notes that he or she should then incorporate into the beta version before deciding whether or not the app is now ready for launch.
5. Conclusion
User experience design is a valuable framework within which to build high quality mobile applications. The process is valid and well tested, though suffers from a tendency to build “towards the middle.” Truly great apps are more likely to come from idiosyncratic lone developers, or from small teams with a strong, opinionated leader. Nevertheless, even these approaches can benefit from end-user feedback and the valuable insight of expert advisors; such a method of working has been honed at Pixar which effectively combines collaboration and the individual creative vision. Moreover, apps should be permitted to fail, for without risk-taking, there is no greatness.
The proposed changes to the UXD process will be difficult to make, particularly for firms with an established way of working. However, they stand a better chance of acceptance and adoption if they are put in place at the beginning of a new app development project and are championed by a visionary director who is inspired to enable a transcendent user experience.
Appendices
A1. Analysis of UXD in the “4 V’s” Framework
This essay presents the case of mobile application production from the perspective of a small team offering development services. The customer, therefore, is the person or firm having the idea for an app and contracting the team to deliver it. This is to distinguish the customer from the end user, or consumer, of the app. It’s also important to recognize that of the “four V’s” two are intrinsic to the process (volume and variety), while two are extrinsic (variability and visibility). The two intrinsic parameters depend only on the nature of the process itself and are insensitive to the distinction between customer and consumer; the two extrinsic ones, on the other hand, depend on the lens through which the process is viewed – that of the customer, or that of the consumer.
The UXD process in mobile app development is one of low volume and high variety. From the perspective of the customer, it is also one of high variability and high visibility. From the consumer’s point of view, however, it is of high variability and low visibility.
Low Volume. Although the principles of UXD are invariant and can be ported without alteration between app development projects, the process cannot be used as a “factory” to stamp out a large number of unique apps. This is because each app has its own particular function, look and feel, and target user. Each will require a unique development process with tailored design, coding, and testing cycles. The UXD process can be systematized only to a limited degree, and while development team members can be functionally specialized, the process depends upon interdisciplinary collaboration.
High Variety. In principle, the UXD process can be applied to the development of an infinite array of unique apps embodying a wide variety of jobs to be done. The process is flexible, complex, and very sensitive to customer needs.
High Variability. Both the consumer’s demand for the app and the customer’s demands of the app development process are likely to be highly variable.
On the consumer side, the app may face a huge spike in demand by going viral (as happened to the social games Draw Something and Letterpress), or by being tethered to a large international event, such as the Olympic Games. However, because the process of developing an app is decoupled from the process of purchasing and downloading it, and because the marginal costs of making and distributing an identical copy to the consumer are very close to zero and managed in many cases by other firms, the UXD process is only indirectly tethered to consumer demand. Both heavy and light demand may prompt the production of new versions, particularly as feedback arrives from users in the wild, though this is not strictly necessary.
On the customer side, the team offering UXD services may experience unpredictable cycles between very high and very low utilization as customer demand for the development of new apps (or new versions of existing apps) varies. Moreover, during a single development process, the customer’s demands may vary dramatically as she argues for inclusion of new features, or for changes in look-and-feel, etc.
Visibility. The consumer of an app will be completely unaware of the process by which her experience of it has been enhanced, that is, the UXD process will have low visibility. To her, it will simply be a great app. The product itself is standardized (each copy of the app is identical) and there may be a long time lag between production and consumption. Apps are simply downloaded from online stores and there is little or no human-to-human contact between the customer and the developer.
The customer, on the other hand, is a key stakeholder in the UXD process. The original idea for the app in all likelihood originated with her and she has been intimately involved with the process at almost every step, from developing strategy, to conceiving of the
A2. Drivers of the UXD Process
The drivers of the UXD process are manifold, but this essay focuses on six, which are utility, ease of use, responsiveness, intuitiveness, context, and simplicity.
Utility – how efficiently and comprehensively does the app allow the user to accomplish the job to be done? Does the app disclose new functionality to that the user appreciates and may not have expected?
Ease of use – how many steps does it take to perform common tasks? How obvious is it to make these steps?
Responsiveness – does the app consistently present an agile interface that reacts quickly to the user? How much lag accompanies user touch events like dragging, or scrolling? How quickly are calculations performed, and do these degrade the performance of the user interface? How well does the interface perform in the face of spotty and/or weak internet connectivity?
Intuitiveness – how well does the app conform to commonly accepted idioms for interaction? Does it support pinch to zoom, or swipe to delete, or tap-and-hold to disclose additional information, for example? If the app develops its own idioms, are these presented in a meaningful way that is obvious and easy to learn?
Context – are there meaningful animations as well as visual and audio cues that inform the user as to what will happen/has happened when she taps a button? Is there always enough information presented so that the user knows where she is in the app’s navigational hierarchy?
Simplicity – does the app focus relentlessly on a single job to be done and on eliminating visual and functional distractions?
All of these drivers are functional in nature, that is they encourage the design process to optimize how the app behaves, not how it looks. This is not to minimize the crucial importance of good graphical design, but rather to narrow the focus of this essay. In addition to an assumed high bar for visual appearance, I also assume bug-free performance, that is, the app consistently gives the correct and intended response to any user input.