I have recently read this very good article about the never-ending dispute between app designers and app developers on who is responsible for the intended, and for the resulting user experience. I was tempted to just link the article here and go to bed but, when I saw it was from 2010, I decided it was time to give the topic a fresh perspective. After all, so much has changed... (or has it?)

Instead of just arrogantly writing down my own opinions, I thought it would be more interesting and informative to ask some experts for their help, and since it was late, I ended up interviewing two imaginary friends of mine, both of whom happen to be called Pat. 

Here is what my imaginary friend Pat, the app designer has to say about creating user experience:

a simple analogy with building houses instead of apps makes the situation perfectly clear. In the context of houses, architects correspond to app designers, while engineers are the counterpart to app developers. Many engineers have little appreciation for the architects' work, seeing them instead as adversaries who just make their lives difficult. We experience the same lack of appreciation from app developers, who think we spend all day drawing pretty buttons with a paint application and then playing around with all the pretty colours. 

A good architect thinks about the client's needs, taste and budget, both in terms of time and money. They think about the landscape and the climate of region where the house will be built, and about the community of which it will be a part. App designers obviously need a lot of talent and good taste, but just like house architects, we also need to be capable of removing our ego from the equation and thinking about what the user wants. A programmer can create a pretty button with a pretty colour, sure, in their opinion. But to learn what the user wants requires market research and testing of initial designs and later of app prototypes, as well as years of experience.

Moreover, we understand that the user experience doesn't end with the app. The app is just one of many communication paths between our client (a company, an organisation, what have you) and their clients (the app's users). So an app has to fit well into a unified theme that defines the product's identity, and is reflected on the product's design, packaging, the company's website, advertising, social media outlets and so on. The consistency of this theme is important to give the user a sense that all of these communication lines lead to the same source.

You can get a developer to write an app that they find great. You can even get them to write an app that you find great. But the goal is to make an app that your product's users find great and feel at home with.

You're better off putting a designer in charge.

And here are my imaginary friend Pat, the app developer's thoughts on the issue:

a simple analogy with building houses instead of apps makes the situation perfectly clear. In the context of houses, you have architects and engineers, and if we (the developers) are playing the role of the engineers of the app world, you would expect app designers and house architects to complete the analogy into a perfect parallel.

Now, architects spend years of study learning about all sorts of details that go into the construction process and the end-user doesn't even know about. They learn about how the flow of the water inside the pipes is influenced by the length, diameter, number of elbows and material of the pipes. They learn about the weight, cost and durability of dozens of different materials involved. When they draw a blueprint, they are already thinking about the electrical wiring, water pipes, drain pipes, foundation, sunlight exposure, weight distribution, street noise and the list goes on and on.

What we need in the app world is app architects, not designers. They don't have to be expert programmers, but they should have solid knowledge of the OS's and the programming language's capabilities and limitations.

App designs rarely include fundamental things like screen transitions, animations, error messages or even how a particular button should look when it's pressed down. When we're lucky enough that the app's flow design is also provided, it rarely includes how the app should behave when things go wrong, for example when a network request fails. Usually, resources that have to be fetched or created (say, a profile picture) are considered as magically given, and the design doesn't account for the time it takes to get them, or what the user should see when they're not available.

Last but not least, in a real world scenario the amount of time we can spend writing an app is limited, and the design needs to take into account not just what's theoretically possible to code, but what's possible to code within a given number of weeks, and this again is different for each platform and each set of devices, among other factors.

You're better off going straight to a developer.

So where do we go from here?

It is clear to me that neither of them is capable of putting together a good app by themselves. Developers probably think they have a slight edge in the competition because they can at least put an app together, even if it doesn't look great, while designers can only put together a bunch of good looking pictures. In reality this counts for nothing because you can't make money with an app that's purely functional and doesn't deliver good user experience.

So who is coming for the rescue? Who is this amazing being that combines the capabilities of both designers and developers?? The answer will blow your mind: It is -- drum roll... -- a designer and a developer together! -- fanfare!

It's true, the ultimate answer happens to be the simplest one. But this team only gives results when it works as a team, in direct, constant communication. It only works if the developers believe that the designers didn't choose a screen's layout based on a coin flip, but based on market research, study and experience. It only works if the designers believe that the developers didn't criticise the screen's layout because they're lazy, but because the inner workings of the app would cause problems with that layout in some particular situations.

And in order to learn to cooperate, each side has to go out of their comfort zone and try to learn at least the 101 of what the other side does. At ImagineOn the shift in this direction started long before I joined the team, and developers are constantly... let's say encouraged... to pursue at least a shallow understanding of everything that goes into the production of an app (market research, visual design, flow design, common patterns and challenges of each mobile OS and each programming language, back-end systems and more) to go with their individual deeper knowledge of their one or two specialties. In other words: Your move, designers!

But there's still another side to this story. Sure, I am writing partly because I need to vent out of frustration and partly because I want to reopen the discussion, but also a little bit in hope that the message might reach a third interested party: The client. As they say here in Germany, wenn zwei sich streiten, freut sich der Dritte überhaupt gar nicht, which as far as is relevant for this article translates to bad news for business.  Some of the responsibility for the status quo falls upon our dear paying customers as well. As long as designers are given a product and told "make me an app design", and then developers are given a design and told "build me an app", there's not much we can do to fix the situation. The clients too have to seek at least a shallow understanding of the many aspects of app production, or at least consult with people who already have it (I can recommend a great firm...), so that designers and developers are put to work truly together. Developers should already be present during the designing phase, just like designers should remain throughout the entire development process, and the two teams should be in direct communication, without the need to use the client as a go-between and flood their inbox with technical questions the client neither can nor wants to answer. Only then will we be able to yell at each other productively, instead of complaining about each other in secret.