As a front-end developer, I always look to push the boundaries. I think good developers do this without giving it much thought. However, as much as we’d love to optimize the technical performance of sites and applications, we still have to come to terms with the limitations of frameworks, hardware, and networks. I’ll spare the details of what inspired this particular topic. Suffice it to say, it agitated me enough to the point of addressing it. The issue has to do with UX flows in which technical concerns are not considered, and subsequently, never discussed. In general, when the various disciplines that work together (UX, DB, back-end, front-end) to build web interfaces confine themselves inside their own silos, it is almost certain the end result is going to be a sub-optimal product. If this sounds a bit too obvious, I’m glad. It should.

There are numerous reasons why collaborative environments yield the best of all products, but I wanted to concentrate on the balance of UX interaction cost as it compares to the technical cost of a specific interface. UX interaction cost refers to the full mental and physical effort that a user must employ during the interaction with a site for the purpose of reaching an intended goal, things such as,

• reading
• scrolling
• looking around in order to find relevant information
• comprehending information presented to you
• clicking or touching (without making mistakes)
• typing
• page loads and waiting times
• attention switches
• memory load ­– the information that users must remember in order to complete their task.

On the other hand, by “technical cost” I mean aspects of an application’s performance that is either an inherent limitation of the device being used to access it, or limitations related to the application’s ecosystem, things such as,

• full weight of page(s)
• client connection speeds keeping up with user interactions
• small screen limitations
• excessive HTTP Requests
• latency
• number and kinds of database queries required
• legacy front-end framework or library limitations
• other back-end factors

Generally speaking, the most efficient application interfaces are those with the lowest possible interaction cost and lowest possible technical cost. The worst are those with highest interaction cost and highest technical cost. Of course, there is no such thing as a meaningful web page with 0 interaction cost and 0 technical cost as that would be an empty static white page. Conversely, it would be challenging to develop a web page with maximum interaction cost and maximum technical cost – one would have to intentionally screw things up to result in something like that. Most web pages fall somewhere in the middle. However, it matters immensely where in that matrix of interaction and technical cost your specific interface ends up. This is where the balance between how pages are designed and how they are implemented matters greatly, and if designs do not take the technical cost into consideration, there is always going to be the risk of having your application end up in the wrong side of this matrix.

Perhaps the point I’m laboring to make is not clear enough just yet. Let’s try out a thought experiment. Suppose we have the world’s greatest UX designer at our disposal. We’ll call him Matt. Now, Matt is brilliant when it comes to interaction design. He makes sure that the interaction cost is as close to 0 as possible for what he aims for the user to achieve. However, Matt has no idea how web pages work from the technical end of things. He has no idea what databases are. He doesn’t know about requests, responses, latency or any other technical aspect of what it takes to build web applications. Now, suppose Matt designs for us the perfect user interface in which he has not taken any technical limitation into consideration. Can we suppose that Matt has actually designed an efficient interface that is going help the user get from point A to point B as quickly as possible? It’s entirely possible for Matt to have accidentally stumbled onto an average user experience overall without having any technical know-how. But what would happen if Matt designed a certain feature to work a certain way, which required the application to make synchronous requests to the back-end every second? Hopefully by now it’s abundantly clear that Matt’s efforts, as great as his design skills might be, is not going to cut it. It’s unrealistic to think that Matt can actually design an interface that is truly efficient, one that works well overall, not just on its aesthetics, without either knowing about the technical limitations and costs or collaborating with knowledgeable developers and engineers who could help drive the UX design to its full potential and maximum efficiency. It’s as absurd as a world without UX designers in which network technicians handle the designing, and they just wing it.

Unfortunately, many development groups fail to realize that UX design cannot be done inside silos. If developers are kept out of the design process, it is unreasonable to expect a great overall user experience. Technology will evolve. Things will get faster and more optimal. Developers and engineers will continue to optimize the applications they build. More efficient technologies will emerge to help solve today’s limitations. However, we have to come to terms with real-world technical limitations of the present. In many cases, the success of web application initiatives will depend on first understanding these limitations, and then designing and building user experiences that take those limitations into consideration. Failure to do so will at best lead to a sub-optimal performing application that repels users like the plague. What happens when teams build applications that have a high UX interaction cost and a high technical cost? They lose.