Top Developer Mistakes When Building an iOS App: Missing Common UI and User Interaction Gotchas

This article is the second in a series called Top Developer Mistakes When Building an iOS App. The first article posted last week can be found here: On Digging Holes and App Development.

Even though it is the app designer’s job to anticipate and plan for User Interface and User Interaction challenges, the app’s developer has to double check this work and account for the more technical elements of the design.

For example, apps previously were not allowed to display two view controllers modally. Even a solid iOS designer might not be aware of that and might have included a user flow where one modal view controller could be displayed on top of another. The Developer has to catch things like this early in the design process, so that the Designer has the time to devise a proper solution.

What typically happens is that the Developer doesn’t see the plan until after the Designer has “finished” and probably moved on to the next project. The Developer is, then, forced to make decisions that the Designer was responsible for making. In the absence of a proper design plan, the Developer just does the easiest thing to implement instead of what’s best for the User’s needs. The Client is confused about why the app flow doesn’t match the agreed-to designs and the Designer is upset that their designs weren’t implemented to their specifications. The Developer is frustrated because the Designer doesn’t understand the technical constraint that caused the change in the first place and the custom work that would be required to make the app work exactly as the Designer specified it. Communication breaks down and everyone feels misunderstood and unheard.

When this happens once or twice during a project, it is usually no big deal. In fact, I have never had a project where the designs were so perfectly thought through that the Developer didn’t have to make a small tweak here and there. Things generally run smoothly when there are only a few of these issues and the team communicates. But if this happens 10, 20, or 50 times during a project – even if each of the changes are relatively small – things inevitably start to go poorly. Even if the team has very strong relationships to leverage, the reality is that the Designer didn’t anticipate enough gotchas and the Developer is wasting valuable resources trying to fix them.

So while the Designer has to be competent, the Developer has a duty to confirm that the designs he accepts won’t cause unnecessary re-work later in the process.