Designing a progressive web app
This article covers the process and the lessons learned when designing a PWA and the things we learned.
NOTE: This article was inspired by a conversation I had with David East, A Firebase Developer Advocate at Google, for our YouTube series “Designer vs. Developer”. You can also listen to a longer version of the conversation by downloading or subscribing to our podcast on Spotify, iTunes or Google Play Music.
A progressive web app (PWA) is a website that has app like features, for example, it can work offline, send you notifications and provides more seamless integration into the native features & behaviors of your phone & desktop. There is a spectrum of PWA UX, with some PWAs focused on content websites that let users browse them when their network connection dies, and others offering an interactive, functional experience such as Spotify.
This blurs the lines of expected user behavior, as people have come to understand why a website doesn’t work when they are on a train and go through a tunnel. A while back my former colleague Sérgio Gomes and I decided that we wanted to design a Progressive Web App. You can see the end result, material.money here.
Our goal was to create a website/app that could show motion on the web, have a seamless user experience and be an example for other designers and developers. We wanted to demonstrate how a designer could use GPS through a website and showcase offline design patterns. We gave ourselves a week to do it, though this turned out to be way too ambitious and it took way longer. We rattled through a list of potential apps, from an RSS reader to a Weather app, but settled on a currency converter app. We thought that “wouldn’t it be great if it would just ‘know’ where you were and show the currency for that country.” Of course, this can be somewhat creepy, more or that later though.
The desired flow
We came up with this idea of a ‘home’ and ‘away’ currencies, so when the user first opened up the app, they would choose their home currency. Then whenever they were in a new country, and they opened the website, it would automatically set the ‘away’ currency to the country you were in. Then if you wanted to adjust the currency for any reason you could. The site would also auto-update with the latest rates and warn a person if the rates were more than a few days old.
User-testing and lessons learned.
Initially, you could only add or edit an amount to the input at the bottom. As we tested the website with users, we found that swapping the ‘home’ and ‘away’ currencies were overly complicated and they wanted to edit any amount.
Also, given the way permissions work on the web, if you want to find out someone’s location, you need to ask for permission. So the browser will prompt the user about their location details. As the app needed to know where they were in order to set the away currency it would try to get their location right away. This was very creepy. From our point of view, we wanted to create a seamless experience, but users don’t really see it that way. Moreover, they are right.
So when designing a progressive web app, if you are going to need phone features, you need to do it in context. Like, accessing the microphone only makes sense the first time a user wants to — say — record a video.
Designing icons
As this website can be ‘installed’ it needs an app icon. The challenge is every platform has its own standard. Android Icons are now rounded; iOS is a box with rounded corners and Windows is a single color. On top of that, you need to deal with other variants of chrome icons for the different contexts in which it can sit: as a favicon, chrome icon, app icon, each with various sizes.
The other challenge is when we design, we are often zoomed really closely and this encourages you to design a lot of details that won’t be seen. So when designing an icon, you need to see it in context, on a shiny screen and in all of the possible formats to judge it effectively. I wrote about designing an app icon in more detail here.
I found that designing a PWA is not a distinct discipline; rather it is still a website, but with added functionality. Because we focused solely on designing the app like experience meant we completely forgot about the responsive design desktop version. So the final product it is better suited to mobile.
Another thing was motion design on the web is very complicated to implement, something that is simple to mock is quite hard to achieve. It mostly involves sleight of hand techniques and needs to be talked through with a developer. Also designing in context, you need to see it in action and observe people using your product. Designing with assumptions is a dangerous game, and some of the UX researchers at Google like to create an assumptions document which they refer to in order to check if they are biased. Lastly, don’t be ‘creepy’, even the best intentions can come across as sinister without giving the person using your product the correct context. Like I have said before, we ask “how might we?” but sometimes it’s important to ask “why should we?”. You can see the end result, material.money here also see all of the code on github.
As a final note, this is the last episode of Designer Vs. Developer for 2018. I would like to thank everyone involved from the Chrome team to Creative Review and you the reader/viewer/listener. Hope you have enjoyed them as much as we have enjoyed making them.
You can learn more about UX design at Web Fundamentals.
