The Progressive Web App User Story
By Ryan Compton and Anthony Topper
The Various Lenses
This story is part of a series of posts.
- Introduction
- The User Story — this story
- The Prototyping Story
- The Research Story
Our goal: explore progressive Web applications from the user’s perspective.
This post explores what users are currently using the “Add to Home screen” feature. Then outlines the phases the user goes through when first getting introduced to PWAs. Our exploration also brings forth some assumptions made from experience with PWAs.
User Elements of a PWA
Let’s first define the elements of a PWA we’ll discuss that our users interact with:
Banners
A bottom-of-screen slide-up banner that gives attention to the user that their previously visited site has an option to be added to their home screen. Basically encouraging the user to create a bookmark.
Installation
Clicking the add button within the banner, or using the “Add to Home screen” option within the browser’s settings, installs the PWA. Once tapped an icon for the app is on their home screen. PWA “installation” removes the platform’s app store from the process.
Splash Screen
Once tapping the app icon from their home screen, a splash screen can show an icon, a background color, and the app name defined within the Web app manifest. This is a quick experience for the user that indicates a loading phase and doesn’t have them waiting for the first paint of the app.
App Shell
“App shell” is a term meant to encompass a set of HTML, CSS and JavaScript powering the user interface. An app shell along with the option to remove the browser interface can transform a home-screen bookmark into a native-like experience. As well, an app shell loads static resources faster and makes accommodations for dynamic content. This also strongly encourages end-to-end consistency within your mobile Web experience, providing further usability improvements.
An explanation for crafting some of these elements into a prototype can be found within our post, Progressive Web Applications & Prototyping.
Who are the PWA Users?
Basically, everyone that uses your mobile website.
However, to understand and enhance our user’s experience using progressive Web apps we should ask, who is going to be experiencing the progressive features?
First we speculated that users were:
- Tech-savvy
- Preferred an app-like experience.
- Curious
- Aren’t too negatively interrupted by a bottom-of-screen slide-up banner.
Then we used Google Surveys to conduct a study to learn about some key user preferences related to PWAs.
We were curious about users that were aware of the feature but never used it, so we first asked those users whether they prefer an app or using their Web browser on a mobile device. We find the sample to be slightly skewed toward an app preference.
Which then lead us to ask why they don’t use this feature if they prefer a more native app experience. The numbers are not one-to-one because users could have multiple reasons.
Out of the relevant responses, we found that the main reasons why were:
- Didn’t see the need or benefit.
- Didn’t know how to properly use Add to Home screen.
This data begs follow-up questions, what does it take to get a user to make the switch from native apps to PWAs, or from standard mobile websites to PWAs? As this group is implying they are accomplishing their goal already through other means, these seem like important questions.
Native Banners Versus PWA Banners
One of the features connected between PWAs and Google Chrome is the “Add to Home screen” banner. This is a call to action for the user to “bookmark” a Web page on their mobile device’s home screen.
The banner is triggered by the browser, in Chrome on Android, when the site has a manifest.json file. A good question posed by Alex Russell is ‘Why Are App Install Banners Still A Thing?’ and while exploring this he makes note that even though there isn’t much understanding to how users handle these banners coming from an industry point of view, Google reports having users convert 5–6x more often from Add to Home screen banners compared to native app install banners. We can conclude from this that users see something notable in a PWA banner as opposed to a typical native app banner.
One explanation is PWAs are simpler to install, nearly instantaneous once you press the button. But how would a user know about the install process before ever encountering such a banner? Results that prove the concept by connecting the dots with “what else could it be other than what we intended?” should evoke some skepticism.
Another possible explanation is the PWA banners slide-up from the bottom, whereas native app banners often appear at the top. This difference could have affected conversions in some way. Perhaps sliding up from the bottom feels less intrusive under many circumstances.
These factors could be why Google has now added native app install banners to Chrome’s Web app manifest, so users can be shown native app banners in a similar way to PWA app banners. And they can install native apps quicker this way than previously, at least on Android anyway.
Phases of the User Story
Now to the meat of this post, trying to bring forth the questions that come up when examining the user experience on a PWA prototype we built. To maximize the possible misinterpretations or confusion a potential user can have, this is from the specific lens of a novice user. This user hasn’t heard of PWAs or Add to Home screen and their only experience with the home screen has been through native apps. While this is a limiting assumption, it is an important use-case to investigate because it is when you are relying completely on the experience to convey the meaning.
Let’s get going with an overview of the user journey:
Visiting the Site — 1st Phase
The user arrives at your site. Native banners often appear to the user during their first visit. PWA banners, however, currently need more visits as they are intended to not annoy the user.
Banner is Displayed — 2nd Phase
Once the user makes a return visit, provided it occurred within a certain window of time, the user will trigger the banner to fire. Think of PWA banners as waiting until you know the user is more interested.
After prototyping a PWA we experimented with firing the banner. Once fired, the user has the choice of adding the app to their home screen, clicking the “x” on the top right, or ignoring it all together.
The banner is actually rather unexplanatory. In regards to new users converting here, there are some significant questions the user may have:
- Is this banner part of the site?
- Will users just consider the banner to be invasive?
- What happens if I click ‘Add’?
- Should I trust this banner?
Anything the design can do to ease these questions is a pursuit worth taking.
In comparison to native app banners, PWA banners can learn a thing or two. Look at the LinkedIn app banner:
The banner has a button represented as a symbol to save space, the banner has a description specifically calling out you are getting a “mobile app”. It also offers a sense of ease by saying, “Get it now”. Additionally the banner is on brand for LinkedIn, thus making it clear that it is intended to be presented by LinkedIn.
This raises a few questions about PWA banners:
- Should PWA banners be smaller, more wordy, and more clear about the process?
- How does this interruption interfere with the user experience?
- What is the type of user that will see this banner and be curious?
- What is the type of user that would see this banner as a distraction from why they are on the site?
- What details of the banner can be controlled to help the user experience?
- Do users actually understand this?
Icon is Added to Home Screen — 3rd Phase
Assuming our user taps the “Add” button it brings them to a moment that kind of gets ignored in the documentation. The user is messaged that the app was added to the home screen, but they are left staring at the same web page. One concern with this phase of the user story is that, why would an unknowing user move away from the site they came to accomplish a task at, only to then deviate from this to explore what some uniforming popup just told them? It appears this is on Google’s mind as well, as with the release of Android Oreo, comes an additional step in the Add to home screen install process that gets the user more involved.
A traditional native app banner takes the user to an app store page, but a PWA’s banner doesn’t take the user anywhere. Only when the user goes to their device’s home screen does the OS lead them to where the icon has been added. It also depends on the device too, not all Android devices made it clear where the icon was added.
One thing that is notable here is the difference in effort taken on the user’s end to install the app as once they see this popup, the process is done, they now have the app added to their home screen. But there is always concern when removing the user from the process, do they actually understand what is going on?
Questions:
- How many users go directly to the home screen after adding to home screen? Reverse that, how many users stay on the page after adding to home screen?
- What is the reason users go to home screen after adding the app to home screen?
- Does a user understand installing a progressive Web application? Do they need to?
Taps the Home Screen Icon — 4th Phase
Once the user finds the new icon we assume that eventually the user wants to go back to the page they added, so they tap on the icon. Now when the web page … I mean application opens we can make it so they get to see a splash screen.
What’s being done here is fulfilling an expectation of the user. The native app experience sometimes has users seeing a loading screen before the app draws its first UI. This is essentially the same as it prepares the user for the UI to appear.
This should make you question:
- Does the user feel confused by this?
- Do they believe an app was installed without their permission?
- Does the user feel tricked that the icon isn’t just a bookmark to the Web page?
Once the user experiences this they will probably get a handle on what’s going on, but thinking of the worst cases, this could scare users off if they believe your site tricked them into installing an app. It could also just aggravate the user because this isn’t what they expected.
Questions:
- Is the splash screen useful to the user experience?
- Does the splash screen set loading time expectations for user?
- Does the splash screen make this app seem more like a native experience to the user?
User Uses the PWA — 5th Phase
Once loaded, the PWA displays the same screen they were seeing when they clicked “Add to home screen”. There are more assumptions to check here.
Question:
- Is the user aware of any difference between the PWA in full screen vs within the browser?
Recents Screen
On Android, and similarly in iOS if meta tags are in place, a PWA is available as its own entry in the recents screen, when you click the overview button.
Like a native app, the user can switch between different apps through the OS and now has the Web app as a separate item from the browser.
Additional Details
There are pieces we haven’t touched much yet; pieces that need to be mentioned. The first being you can remove the browser search bar. The immediate benefit in this is the increased amount of screen space for the app which should be a benefit for the user, hopefully.
There are other design choices that were made with this prototype app inside its manifest. This app had the display property within the manifest.json file set to “standalone”, Mozilla describes this as:
The application will look and feel like a standalone application. This can include the application having a different window, its own icon in the application launcher, etc. In this mode, the user agent will exclude UI elements for controlling navigation, but can include other UI elements such as a status bar.
This design decision affects the user story as it says within the description “exclude UI elements for controlling navigation”, so this limits the user’s ability to navigate through means they may expect and thus relies on the experience to include navigation controls (noted as an issue within this post under Recommendation 10). There are other options that give the user more control, so it is up to the designer to understand their specific user stories to know how to decide.
Orientation controls are another feature that can be built into your PWA configuration. However, we decided not to dive into exploring this.
More questions:
- How much does the lack of a search bar change the user experience?
- Does the lack of a search bar make the user believe this is more like a native app experience even though they are seeing the same content and content layout as the mobile website?
- How does the user explore when compared to a traditional mobile Web experience? How about when compared to a native application?
Conclusions
Questions remain unanswered. Some of them have an answer that is grounded in intuition and expert knowledge. For example, it is expected that the user who agrees to have the app added to their home screen would logically then proceed to the home screen to re-engage and explore. But we still would encourage you to test your assumptions when possible. Hopefully this user story helps frame the practical question, how do you optimize getting new users to your PWA who don’t have experience with PWAs?
Some designers deal with this issue by directly informing users through prescriptive on-boarding. This brings up the invasiveness argument again because it deviates away from why users came to the site in the first place. We’re not sure there is a clear solution just yet. Chrome’s requirements of visiting the page twice within at least 5 minutes between each visit is a great first step, but assumptions are present again. Maybe your home page isn’t the best place for a “Add to Home screen” banner?
There are ways to capture the banner firing event and select more precisely when the banner gets shown to the user.
Keep in mind that some PWA features are new and they will continue to evolve over time. As can be seen in Maximiliano Firtman’s post, Android Oreo takes a bite out of Progressive Web Apps.
Next up, The Prototyping Story for PWAs.
About the Authors
Anthony Topper
Tony has been designing and developing on the Web for over 20 years. He started out as a “webmaster”, aka full-stack developer and designer. Over the years he has touched nearly every aspect of producing for the Web, from sysadmin and database design to user-experience research and visual design. He’s now a design leader at eBay.
Ryan Compton
Ryan is a PhD student studying large-scale computer supported cooperative work. He originated within the field of psychology which lead to exploring computer science by working on citizen science and crowdsourcing technologies. He now focuses on utilizing quantitative methods to understand and improve human social and collaborative systems.
