🎉 Check out DevCenter, our new documentation site for v2.0! (Or keep using this site for earlier versions.)

Switch to DevCenter

Menu Sheet Overlay
Search Sheet

The Design Process

From gathering customer requirements to designing the templates and enabling developers, this section presents the Mobify-recommended structure when designing for AMP.

Phase 1: Discovery

Which templates are required?

In the initial kickoff it is important to discover which templates will be supported. Normally this would come from an analysis of the site’s traffic and conversion statistics. Product pages or category pages with the highest number of pageviews are recommended for AMP in order to maximise its impact on conversion.

What are the customer’s expectations?

Most customers will have a good understanding about what AMP is and how it works. What may be less well known are the UI limitations that AMP templates must adhere to. Making the customer aware of these limitations early may help manage expectations.

Phase 2: Planning

Template ‘gotchas’ and workarounds

Study each supported template on the customer’s PWA and identify areas where AMP’s technical limitations may impact the user experience. Examples of some of the ‘gotchas’ can be found in the common issues and workarounds section.

List AMP components

Identify the PWA components on each supported template where an AMP component can be used to create the same user experience.

Future feature enhancements

If there are components still in the experimental phase which would greatly improve the user experience of the AMP template, it’s important to identify these for future development.

Phase 3: Design

Define the AMP UI

Use findings from the planning phase to define if and how the UI in the AMP templates will differ from its PWA counterpart. For visual purposes it may help to produce separate mockups for the AMP pages, although the same outcome can be achieved through good documentation.

AMP -> PWA pathways

This is important to create a seamless journey for those users wishing to interact beyond the initial page view. Clearly define which interactions will keep the user in the AMP document, which interactions lead to the PWA and what the state of that PWA page will be when it loads.

Phase 4: Enablement

Get buy-in from customer stakeholders

Present the AMP approach to the customer. Designers should be prepared to explain the UI based on understandings of the technical ‘gotchas’ uncovered in the planning phase. It is important for customers to be prepared for the AMP pages to have some visual differences when compared to a PWA experience.

Enable developers

Compose a design intent document which clearly outlines how the AMP templates should look and function in relation to their PWA counterparts. This document should label in detail the AMP components that will be required and where the AMP -> PWA pathways are. You can see examples of these documents in the Resources section


Was this page helpful?