PWA as a UX Challenge: takeaways from the Mobile Trends Conference 2019

The Mobile Trends Conference 2019, which has just ended, shows how dynamically the approach to mobile is changing in Poland.

Discussions centered around voice interfaces, m-commerce, reaching out to Generation Z and other challenges energized the audience at Krakow’s Stara Zajezdnia (Old Depot).

An unsung hero for this event was the PWA (Progressive Web App). Although PWAs did not have their own block in the program, they appeared as the main topic of three presentations: one by Google’s Jenny Gove, one by e-point’s own Michał Szklarski, and one by me. In fact, this article will cover points made in my presentation.

PWAs have made multiple appearances in the e-point blog. This time, let’s approach it from a slightly different angle: as a challenge to UX designers, particularly those working on seemingly non-application sales and service portal designs, e.g. for banks or insurers.

Why PWA?

Progressive Web Apps, in a nutshell, are Internet pages that behave like native applications. They are better than mobile-responsive websites because they:

• Are faster.
• Offer greater stability.
• Have more offline options.
• Make better use of native device functions, such as the camera, geolocation, alerts and notifications, and gesture navigation.
• Can be installed on the home screen of a device
• Are now available in the Google Play store. (This is a relatively recent development.)

In many ways, PWAs are also better than native applications. PWA installation is simpler and doesn’t necessarily require an app store. PWAs do not require updates, take up less memory, and do not demand a different version for every operating system variant. Moreover, being websites, they are indexed by Google and presented in search results.

Will PWAs replace applications?

Naturally, PWAs are not a universal solution, and I doubt they’ll replace classic applications anytime soon. Also, they’re not feasible for some use cases, such as in banking applications or mobile games.

Nevertheless, it needs to be borne in mind that mobile users have grown fairly picky. On average, they have 60-80 applications, but they regularly use only half of them – if that. Plus, 51% of mobile users install less than one application each month [source: Statista] and 77% never return to an application 72 hours after they installed it.

Today’s most important apps are those used for social media and for communication; it is these tools that account for the increasingly longer times users spend on their mobile devices. We can debate whether e-commerce and information services fare well in the category of mobile applications. However, it should be remembered that installing an application constitutes an additional barrier to some users; likewise, building and maintaining solutions dedicated to various operating systems may prove an inviable option.

Despite all of the above, it’s tempting to design application-like portal solutions for financial and banking companies. The sheer number of service and sales processes or interactive tools (such as calculators or configurators) makes packaging everything up in a native application seem highly intuitive. But will that app ever be downloaded onto users’ devices?

For these reasons, PWAs have become very appealing to us and to our customers.

The baseline PWA Checklist

We started developing our first sales and service PWA after an analysis of Google’s PWA Checklist. This checklist presents baseline and exemplary PWA requirements, which allows developers to quickly verify how far a given website is from meeting the standard.

This would seem an ideal situation – simply implement all Google’s PWA guidelines and we get a service that will engage and delight users, taking them deep into the brand. This will ultimately lead to more time spent with the offer and to higher sales.

Unfortunately, if we consider the baseline PWA requirements, we see that most of them are technological. Applying secure HTTPS protocol, ensuring responsiveness and fast operation (even in slow networks), and enabling offline loading and various installation options clearly affects user experience. So where does the UX design angle come in?

A UX Checklist for PWAs

The only requirement from the baseline Google checklist that is not strictly technological says Page transitions don't feel like they block on the network and even after reading their explanatory note (in this case, Snappy as you tap around – a truly great song title) it is difficult to state clearly the key design purposes.

The exemplary checklist, on the other hand, features an entire section devoted to user experience, but again it lists user experience guidelines relating to technology rather than to design. Nevertheless, reading this checklist helps us understand how PWA implementation should affect users’ experience according to Google.

It also meant that, as a UX team, we had to define some areas that had to be tackled first if we were to meet our goal of designing a sales and service PWA that’s more user-engaging than the best native application. They did not directly relate to the technological requirements set by Google, but they’d help us get to the heart of the application nature of this design. They were:

• Information architecture
• Content
• Interactions and transitions
• RWD and the mobile-first approach

Let’s consider each one of these key areas separately.

Information architecture

Mobile applications are user-friendly because their information architecture is repetitive and transparent in two ways:

In the macro scale, e.g. we can always expect a similar number of pockets in particular application areas.

In the micro scale, e.g. views with similar functions look and behave in a similar way.

In sales and service portals, tailoring the presentation to each particular piece of information is extremely important. The presentation of banking account pages may vary greatly from a standard account to a foreign currency account, not to mention those for mortgages, loans, or other products. Occasionally, products or services require additional subpages, which complicates the macro-scale information architecture. (This can be compared to when Spotify albums are presented differently based on their music genre.) This variance is justified in terms of communication, but it makes it harder for the user to learn the portal and thus creates a barrier to usage.

It is worth going the extra mile here and, at an early stage in the design process, grabbing a whole cross-section of products from various categories with the goal of establishing a strong pattern for presenting detailed information. Flagship products – which usually get a lot of focus in the design process – will not suffer, and this extra work will facilitate the user’s experience with the portal and with exploring its options.

Content

Most popular mobile applications have very limited text content. Even if we skip extreme cases like Snapchat, it can be seen that one screen usually contains less than a two hundred characters.

On the other hand, our clients’ standard product and distribution webpages can hold hundreds or even thousands of words.

In this case, it’s not exaggerating to say that text content becomes a battleground between user needs ("looking for particular information"), marketing expectations (communicating promotion information), and legal requirements (adding one more disclaimer, just in case).

Obviously, the rule of thumb cut as much as you can still holds true. In fact, it is even more true than usual because it follows the principle of plain language, which both we and our customers strive to implement in all solutions.

We aspired to a solution that could somehow anticipate what the user is looking for and help them find it. Only subsequent interactions, depending on what attracted the user’s attention, led to displaying particular data via swipes or other actions. We took the concept of a conversation with an advisor as our content model: stating core information and leaving the details for follow-up interactions.

Interactions and transitions

When asked what they liked in mobile applications, users frequently replied the coolness. There are many things behind this idea, e.g. how the application responds to user actions. No one uses applications just to admire micro-interactions and transitions between screens, yet the process itself can be enjoyable and can improve user experience.

When trying to deliver a positive impression, remember that speedy operation and compliance with various operating systems and browsers are just as important as aforementioned coolness. That is why we decided to make a set of interactions and transitions which were not just cute frills but that actually facilitated service usage and ensure the snappiness of Google’s PWA Checklist.

Many of these micro-interactions was intended to make surfing the sea of content easier. Even the simplest swipe has a strong impact on ease of use, e.g. allowing users to move seamlessly between various promotions or products. Thus, the overriding principle for designers was use the least to achieve the most.

RWD and the mobile-first approach

One of the greatest surprises in designing PWA portals was how challenging it was to transform PWAs into desktop views. We were not newcomers to the RWD and mobile-first approach. However, it appeared that the logic of a smartphone application and a desktop portal were like chalk and cheese – completely different.

Splitting information into the smallest possible chunks is a major challenge in designing a solution that looks good (and works!) on a smartphone. The simple transferral of the same mobile-friendly content to a desktop view produces a feeling of emptiness. This can appear highly aesthetic, but is actually difficult for users to process and understand.

Horror vacui – the fear of empty space – is not the only issue here. Different devices do not mean merely different screen sizes. We use the touch screen by touching it. Opening and closing modals and swiping through items is very intuitive. Most PCs require the use of a mouse or touchpad, which makes this kind of portal interaction unnatural: users are accustomed to scrolling. Even on touchscreen laptops, swipes and other mobile gestures feel too extended and uncomfortable.

In short, the rules for moving between mobile and desktop views are more complex than normal. We strove for full consistency of content presented in both channels, which necessitated different tactics for transforming structural portal components; this depended on their role in building communication and their function for the user.

Finally, a vital aspect needs to be highlighted which is not connected to the PWA itself. Mobile and desktop are two usage contexts and account for different current user needs which we, as designers, must cater to. PWAs may be an opportunity to think deeply about how and when mobile and desktop contexts can complement each other and when they should be used independently.

PWA and UX Design is still evolving

The greatest challenge in our work was to define which mobile application features were worth transferring to the world of sales and service portals. We found out that, at a deeper level, a successful PWA project was much more than just meeting Google checklist guidelines. It triggered some reflection over what the application nature we wanted to achieve in our designs actually stood for.

Currently, e-point is working on several PWA projects in the portal and e-commerce areas. Soon, we will be able to tell you more about them and how new solutions translate into user satisfaction. We’ll also show how PWAs can support achieving business goals. However, based on usability surveys and interviews with our customers, it’s already quite clear that the extra effort put into PWA implementations is worth it.