Why app design hurts app development

[[142621]]

Mobile apps have become so ubiquitous that most people in the tech community assume that developing an app is a simple, straightforward process. However, when you peel back the curtain on app development, you see a grueling journey filled with budget overruns, bloated code and assets, and development delays.

Many of the obstacles mentioned above are unique to mobile app development. Today’s mobile apps often serve as the primary link between users and companies. This means that the number of people involved in mobile app design is very large: designers themselves, product teams, marketers, product managers, and even users (or venture capitalists) who ultimately provide funding for app development - few of whom have a general understanding of how the actual app is implemented at the code level.

This isn’t to say that engineers are the only ones who understand the app development process — it’s just that there’s a huge disconnect between the planning phase of most apps (aka concept and design) and the code deployment phase required to make an app a reality (aka development).

The key tension in the application development process is the cultural and technical differences between the developers who are responsible for deploying the final code and everyone else. In other words, most people in the technology community are part of the problem. I will explain this further below.

Obsessed with visual effects that cannot be achieved with code

When we talk about mobile app design, we usually mean the images rendered in Photoshop or prototyping platforms such as InVision and Pixate. These powerful visualization tools can show the final look and feel of the application.

However, these platforms have no direct connection to the application's codebase, and they can only represent a very idealized final product, but this imagination may not be realized. (For example, a large number of animations and highly movable UIs are visually attractive, but these elements may add months of development time.)

However, development companies often use beautiful visual design as the core reference for the application. (This is very different from web design, where the final HTML/CSS code can usually be used for real-time prototyping.)

I’ve seen this happen many times: when you show a prototype to a client, they have a fixed impression of the product, but weeks or months later they are very disappointed when they compare the final product to the approved design.

This raises a related question…

Design resource allocation contradiction

While prototyping determines the look and functionality of an app and is an important tool for companies to communicate with clients and internal development teams, it is also a (costly) part of the development process and has no direct relationship to the final product.

Once the application has completed the code deployment, the prototype design has no value, that is, a lot of development time and budget are spent on something that will eventually be discarded. In addition, it is also a waste of resources to design some functions that will not appear in the final application.

This disconnect between prototyping and development means that designers can easily come up with animations, UI concepts, and rich media content that are nearly impossible to implement in code.

In this case, the designer’s time and energy are completely wasted. When they find problems with the app, they need to start a new round of design work - at this time, the "final draft" of the prototype has often been approved and the app has entered the development stage.

Design without real data

When prototyping, designers always pick out numbers, names, and images to show how user input will look in the final app. But they often forget that user input can be varied and messy — some of which can cause the app to look “distorted” or completely unusable. (Dropbox’s Josh Puckett described this problem vividly in a previous Medium article.)

Unfortunately, the conflict between data and design can usually only be discovered during the public testing phase of the app, which is already a relatively good situation. The worse case (and more common situation) is that the app has been put on the App Store and users actually start using it before discovering the problem. In either case, designers and developers usually need to go through a new round of long update development process.

We develop applications, not prototypes

One solution that has been suggested to address these challenges is for designers to learn to code. But I agree with Jesse Weaver that this approach is neither feasible nor acceptable. What we really need is a better understanding of the app as a whole - from its programming foundation to the surface UI and art assets, and taking into account how it actually runs on different platforms.

We also need to realize that app development is not a linear process. It is not as simple as handing a designed app directly to the developer. Instead, designers and developers need to work together to create an attractive appearance and ensure that every step of this appearance can be realized.

As more and more companies develop apps as their sole product, it becomes even more important to develop apps in this way.