Progressive web application (PWA) projects have particular needs from the perspective of a business analyst (BA). They allow you to focus on a couple of core features, which are the reason PWAs exist and are crucial to leverage all its benefits.
What role does a business analyst play?
During software development projects, the BA is responsible for supporting both the client and team in efficient communication. They help sharpen the vision, define goals, create documentation, and in general, make work quicker and smoother. If you’re interested in the details, take a look at my previous post on the role of a business analyst in a software development project.
In PWA projects, a BA usually has three main groups of tasks:
Defining the vision
When you start building a new front end based on PWAs, you have to define the vision. It should be the first topic discussed when starting cooperation. If the client can’t define it or has a problem with providing detailed requirements, the BA has to organize a scoping session.
A PWA scoping session is a workshop that usually takes one or two days. The team meets with the client in order to collect the information needed to:
- Choose the approach to the design.
- Gather the business requirements and elaborate on them.
- Precisely define the unique selling points (USP).
- Establish the IT architecture along with key processes.
At Divante, to specify the project scope, we usually use MoSCoW methodology. It’s an approach that focuses on defining what is a must-have, should have, could have, and will not have. It allows the team to precisely establish priorities and the scope of the project. Features with the lowest could have priority aren’t omitted. They’re listed in the roadmap for further development of the project.
Support for user experience design
There are two approaches you can take when engaging a BA with PWAs. One is starting with the BA working solo and having them create requirements that are foundations for the user experience (UX) designer. The second one, which I strongly recommend, is starting the project as a cooperation between the BA and UX designer.
Based on my experience, working with the designer from the very beginning helps the whole team save time and start development quicker. It’s also an optimal scenario for the client. They’re aware of what’s happening in the project from the visual side in the early stages. This keeps us from cumbersome corrections later. It also prevents backtracking and changes to the initial requirements after presenting the design to the client, which can be an expensive and time-consuming process.
Creating documentation for PWAs
The next step for a BA is to prepare the documentation that will allow the client and project manager to monitor the scope of the project. Documentation will also be required for the programmers to build a solution along with testers to check it. In the case of PWA projects, where we focus on the front end, such documentation is built around user stories and acceptance criteria. It should include information about:
- How content management system (CMS) components work.
- Attributes, including what will be displayed and where.
- The source of data, such as a third-party service or a specific back-end platform. For example, eCommerce, product information management, CMS, etc.
- All components’ view states.
- If the feature is strictly front end, a detailed description about how it works, where is the data fetched from, and where it needs to be sent.
Crucial elements of PWAs for a BA
When creating documentation and working with a UX designer, a BA always has to remember the crucial features and requirements of the PWA website. It has to:
Work on all browsers and devices, especially iOS and Android.
When defining the requirements, it’s not enough to agree with the client that the website should work on mobile and desktop devices, and on all available browsers. We must remember that those browsers have multiple versions.
The common issues with PWAs working on older devices are problems with the incorrect display of the component or lack of it, long loading time, etc. Very few people stick to the old versions of browsers, but the customer must be aware of this threat to avoid surprises later on at the acceptance test stage.
If the client has any doubts, they should track the users’ browsers with an analytics tool and use this data to pick a list of the supported versions.
Be responsive.
A PWA has to allow for quick and intuitive browsing. It needs to automatically adjust to the size of each screen regardless of the device. This is very important in the design phase. The UX designer has to propose a layout and components that guarantee:
- Intuitive and quick transitions between individual sections on the page.
- Reusable and easy to scale components.
It’s a common mistake that clients focus just on the desktop views and forget to adapt the design to smaller ones. Menus are usually a good example here. On devices with large screens, 90% of menus are lists of several higher-order categories displayed in one line. When the mouse hovers over them, they reveal lists of sub elements. While it looks good on a widescreen, it’s cumbersome on a mobile device where we can fit just two or three elements in a row.
What about the rest of the higher-level categories? Make a slider? Move them to another line? Well, the best solution is to create the so-called burger menu. For example, an icon that, when clicked, will display a list of categories and sub elements in a dedicated view. 
There are many similar elements that cause problems on different screen sizes. That’s why the UX designer has to cooperate with the BA really closely. They have to consult about those issues at an early stage and avoid problems during the implementation.
Be secure.
When we’re talking about the security of a PWA, it’s extremely important to use the HTTPS protocol that allows for the installation of an SSL certificate.
But security isn’t only affected by the secure SSL protocol and certificates. When creating requirements, we must also remember about the General Data Protection Regulation (GDPR) policy and sensitive data, such as card details. In eCommerce stores, especially in the USA, it’s a common practice to remember payment card details in the account and use them when they are shopping the next time. Is it easy? Of course. Security? Extremely important. In PWA projects, we must pay attention to this type of data.
Speed up the loading time.
A PWA website needs to run and load quickly, and in most cases, it does. Unfortunately, there’s one particular case when it doesn’t, and it’s a crucial thing to remember in the context of the BA and the design process. The data from the displayed page is stored in the browser's cache, so when it’s displayed again, it takes a fraction of a second. The first display, however, takes a bit more time because all the data has to be downloaded and saved in the browser.
No worries because it's a fraction of a second. But it’s important in the context of the website design and requirements. The more dynamic the content of the website, the richer the content of the website, and the more "goodies" on the page, the more difficult it is to load quicker.
When we make the displayed content dependent on the user choice, don’t be surprised that the page loads one or two seconds slower than another whose content is independent. In my opinion, the most important element during the analysis is to find a balance between advanced elements on the website and its performance.
Have a friendly URL address.
Thanks to a friendly URL, users know what content to expect.
Take a look at the addresses below:
- www.example.com/blog/my-article-title
- www.example.com/blog?id=123456789
Which one tells you what you’ll see when you click it? It's also crucial in business analysis and then in implementing the solution. We must remember about URL address transparency and search engine optimization (SEO) compliance.
An interesting case may be a page with applied filters. It’s a good practice to display them in the address. Usually, it looks like this: - www.example.com/blog/?jql=article%3Dtitle%20and%20category%3Dhealth(...)
Most of the time, you could replace it with something like this: - www.example.com/blog/article/category=health
Offline operation, push notifications, and a shortcut.
Offline mode is a unique and important part of PWA apps that can be used, for example, when a user on a train enters a tunnel. The website must be designed in a way to get by with the data stored in the browser. It allows the user to continue their task even if they lose their internet connection.
When it comes to push notifications, customers are often unaware that they can use this marketing channel to display push notifications on device screens as in native applications. The role of the BA is to make sure the client is aware of these possibilities.
Nevertheless, push notifications are usually treated as a could have feature. Most customers already have other marketing automation tools. In those cases, the BA takes care of the integration requirements and the high-level scope of this integration. The technical details are specified by the architect or technical leader.
And finally, a PWA allows for a custom shortcut that the user can pin to their home screen. It’s a default option for every PWA page, so it doesn't have to be covered by a dedicated requirement.
Should you involve a BA in your PWA project?
With a PWA, it’s crucial to get those features right. It can have a significant impact on SEO, and bad implementation can ruin the benefits of the technology. Taking this into consideration, a BA is an important team member that helps to successfully deliver the project.
The presence of a BA improves communication with the client, speeds up the process of working on the project, and affects the satisfaction of both sides. In short, it gives you someone who can look at the project as a whole and enables other project members to focus on the technical sphere.
Published February 17, 2022
