UX is Inseparable From Software Engineering*
*…unless you have endless resources and time
The saddest part of any UX practitioner’s career is when a product based on the designs becomes reality, but looks and behaves nothing like imagined. It happens surprisingly often in any kind of environment — I have observed this phenomenon in enterprises as well as startups. In my opinion, this problem normally stems from one of two possible root causes, or in the worst cases from a mixture of both.
- The development team does not possess the required capabilities or experience. It is a surprisingly frequent occurrence in IT, but this scenario is not the focus of this article.
- The UX design is disconnected from development.
The second case is always harmful for any digital product, except in the unlikely event that you have endless resources and time. If that is generally the case for your projects, just close this article and take a moment to feel grateful.
I assume most of you are still with me.
There is a strong argument for excluding software engineers from the UX design phase of a project, at least at the beginning. Worrying too much about technical constraints can limit blue-sky thinking and tie down imagination. For real innovation to happen, you need to bravely challenge existing paradigms. Cooper urges designers in his famous book ‘About Face’to first treat the UI as “magic” that simplifies the life of users and only start worrying about technical feasibility after.
I agree that it is good practice to spend some time with free ideation — we call these Dreamer Workshops — at the beginning of the project to get the creative juices flowing. Let’s hear all the crazy ideas, we might find some gold among them. But admit it: most of the time our goal is not to deliver something groundbreaking that changes the world, we are “just” trying to create a great product that people will love. We take good existing solutions and ideas and improve upon them, stitching them together and modifying them to fit our goals. Users expect some originality but crave utility and usability much more — creating huge surprises is better left to the entertainment industry.
Dreams inspire us, but usually we have to wake up from them.
You have deadlines, finite resources and budget constraints which limit your possibilities. You need to create the best product within these limitations. If you don’t take existing boundaries into account, you will be disappointed with the results and you will frustrate your team by setting unattainable goals. You want to create a design that challenges people while still being firmly rooted in technical and financial realities.
Software is built by engineers, which makes them your most important allies, especially when trying to create the best possible experience within the project’s constraints. They are not there to limit you with their constant worrying, they are rather your guides in the swamp of technology, helping you avoid sinking.
Personally, I find discussing ideas with our software architects one of the most exciting part of my job. They make an effort to be user-centered and I make an effort to understand the technical challenges they are facing.
Performance is the Foundation of User Experience
I strongly believe that the unsung heroes of great user experience are stability and great performance. As a result, UX practitioners have to care about it. Usability tests always confirm this belief: no one cares about how great a menu structure is as long as something loads for ages or crashes for no apparent reason. This affects mobile software even more profoundly as users are “spoiled” by the few truly polished apps that they use on a daily basis (Facebook, WhatsApp etc). The “performance bar” on mobile applications is much higher than on desktop or on the web.
To ensure that our apps excel in performance, I often have lengthy talks with our Chief Solution Architect, Balazs Kovacs to find harmony between UX and technology. These talks gave us the idea to create a workshop where we share the most important principles ensuring great performance for mobile apps. We call this factor the “UX Performance”: the part of software performance that is directly perceivable for the end-users. You will find the slides of the workshop below, but I will briefly summarize our approach. Great app performance must be ensured in two places: on the client application and on the backend — let’s look into those!
Mobile Client Performance
On the client side, performance usually consists of two major elements:
1. UI performance: this is the most perceivable part of speedy software. The smoothness of the animations (frame per second), the perceived speed of screen changes and the general responsiveness (how fast the system reacts to interactions). Native development (Objective-C/Swift on iOS, Java on Android) delivers the best results in this regard, thanks to the lack of additional layers above the system SDK. Cross platform solutions all introduce trade-offs which inevitably lead to performance loss. Making this initial technology choice has paramount importance for people sitting in the business and design chairs. To aid them in making the decision, our CEO András recently published a very candid article about the pros and cons of cross platform solutions based on our experiences.
2. Masking loading: loading is inevitable, as most complex applications work with dynamic data. The role of UX on the client application side is to plan these occurrences carefully in order to minimize the annoyance they cause. There are various techniques that either decrease the perceived time of loading or even better, orchestrate loading in a way that the users don’t need to wait. The former utilises basic psychological principles “tricking” users into believing that loading is faster while the latter enables users to engage different functions in the app while loading happens. Client-side caching is another widely used technique to avoid unnecessary data re-loading. Designing when and what the app loads is a shared responsibility of the UX and the engineering team. As such, it is a textbook example of the areas where active collaboration is essential.
Mobile Backend Performance
The backend is the least visible piece of the performance Puzzle and is therefore often overlooked. To avoid unpleasant surprises, always keep in mind a simple rule of thumb: data that is not there cannot be displayed. Not knowing the exact capabilities of the backend (e.g. available data, data format and the required time to process and send it) can ruin a design. Users hate to wait, and they hate errors even more. While you can mask loading times to some extent with clever UX, you can’t fully hide a weak infrastructure or a flimsy backend architecture.
A great backend has three requirements: proper hardware, right geolocation, and efficient software. If any of the three are missing, they will cause performance problems. While the first two are generally needed for any good online service, a decent backend software for mobile apps has different requirements than what we are used to on the web. The emergence and stupendous success of some large online platforms that provide generic open APIs created the false notion among many developers that creating ageneric API in itself is a virtue. These services (e.g. Facebook, Twitter) need to stay generic as a plethora of different third-party applications connect to them with wildly different use cases and applications. They trade off performance for compatibility and versatility. Most mobile applications never grow into huge platforms serving thousands of external applications. In order to succeed, they first need to turn into good products with great performance. It is okay to dream big, but creating a backend architecture for your long-term vision that is years away is almost always counterproductive for your initial success. Planning should be rooted in the short and mid-term requirements, not in dreams — evolution will happen step by step. This is why mobile applications benefit greatly from mobile specific APIs which transfer the minimum amount of data possible, and preferably group that data by the screens of the application.
It would be great (or boring?) if every project started with a blank slate. Instead, we often build upon existing backend infrastructures, often consisting of multiple separate services which were created without any consideration for mobiles. Unfortunately, the performance is always defined by the weakest link in the chain; the server that provides the required data the slowest will ultimately limit loading times. To counter this effect, amobile specific middleware can be inserted between the mobile client and the various backend services. A middleware ensures that resource-intensive calculations are done on powerful servers instead of feeble mobile devices and it also enables pre-caching, effectively pre-digesting data and serving it in the most suitable format for the mobile client.
If It Concerns the Product, It Concerns the Designer
If the above written sounds like something that is better left to engineers, you need to reconsider the role of designers in a product development team.
Designers should always think in great outcomes, which means that all factors influencing the experience must be a concern for them.
This is especially true with the emergence of non-visual UIs and machine learning. In a few years you might be designing invisible recommendation engine and thus be even more dependent on the knowledge of developers. Collaboration between UX practitioners and engineers is already vital for creating exceptional digital products and it will be even more so in the future.
Now go and befriend a software engineer — they don’t bite.
