Anders Lassen is founder and CEO of Fuse. a native app tool suite for both designers and developers.
Mobile apps have become so ubiquitous that it’s easy for most people in tech to assume that creating them is a simple, straightforward process. Look behind the curtain of their development, however, and you’ll often find a painful history of cost-overruns, code and asset bloat and development delays.
Many of these obstacles are unique to developing on mobile. Mobile apps today are frequently the main interface between customers and entire companies. This means that the number of stakeholders in mobile app design is large: the designers themselves, the production team, the marketers, their managers, even the customers (or VCs) who ultimately fund development — few of whom generally understand how the actual app will work on a code level.
This doesn’t mean that engineers are the only ones who understand the app-creation process — just that there’s usually a major disconnect between most apps’ planning phase (i.e. concept and design) and the implementation of the actual code needed to create them (i.e. development).
This cultural and technological divide between the developers who implement the final code and just about everyone else is a key point of friction for building apps. In other words, most of us in tech are still part of the problem. Let me explain.
Locking Into A Vision That The Code Can’t Complete
When we talk about mobile app design, we’re generally referring to the app as it’s represented in Photoshop or a prototyping platform such as InVision or Pixate, powerful visualization tools that convey the look and feel of the final app.
However, these platforms have no direct relation to the underlying code, and can only represent a highly aspirational version of the final product, which may not be ultimately feasible. (Heavily animated, highly dynamic UIs, for instance, are visually appealing, but may add months to development.)
But a compelling visual design for an app often becomes the company’s central frame of reference for the app itself. (Contrast this with web-based design, where the final HTML/CSS code can usually be prototyped in real time.)
I’ve seen this happen time and again: Once you put a design in front of a client, they’re locked into that vision, and weeks or months later, are set up for a sharp disappointment, when they compare the design they signed off on with the actual app.
Which brings up a related point …
The Design Resource Allocation Paradox
While a prototype design defines the look and functionality of an app and is a crucial tool for communication with the customer
and inside the development team, it is effectively a (costly) part of the process, rather than the product itself.
Once the app has been implemented in code, the prototype loses its value, and a large part of the development time and budget is spent on something that ultimately gets thrown away. This also includes resources spent on design features that never go into the final app at all.
The disconnect between prototype and development means that it’s easy for a designer to come up with animations, UI concepts and rich media content that are simply not possible to implement through code.
In these cases, the designer’s time and effort is completely wasted, incurring new rounds of design when the problem is discovered — often long after the “final” prototype has already been approved and handed over to development.
The Danger Of Designing Without Real Data
During the prototyping process, designers tend to cherry pick numbers, names and images that best illustrate how the final app will respond to user inputs. In the process, they often forget just how widely varied and frankly messy user inputs can actually be — some of which can cause an app to “look off” or render it completely useless. (Dropbox’s Josh Puckett has a vividly illustrated Medium post on this issue .)
Unfortunately, specific data-versus-design problems are typically spotted only after the app is in active beta testing, if the developer is lucky — or less lucky (as is often the case), only after it’s in the App Store and actual consumers start using it. Either way, a costly, time-consuming update is usually required, a process requiring new rounds from both designers and developers.
Build Apps, Not Prototypes
In the face of such challenges, some suggest that the solution is for designers to learn to code. As with Jesse Weaver. I think that’s neither feasible nor desirable. What’s really required is a better understanding of the app as a whole, from the basics of its programming to the surface sheen of its UI and art assets, within the context of the different platforms it will ultimately run on.
This also requires a realization that app development is not a linear process, and an end to the all-too-common workflow of designing an app and simply handing it over to developers. What’s needed, instead, is an organic process where designers and developers work together to create a vision that’s compelling and exciting — while also ensuring at every step that this vision can actually be brought into reality.
In a time where apps increasingly are the sole product of a company, fostering this approach is more important than ever.