emerge

Companies that create exceptional customer experiences (CX) stand out from the competition. Great customer experiences create value for both customers and the business. It’s a focus on building a win/win relationship. 

Empathy mapping can be an invaluable tool to help you focus on the right things: Shifting your teams into a customer-centric mindset, identifying what it will take to meet the needs of your target audience, and creating solutions with higher value and stronger impact.  

Today your digital products and services are central to the customer experience. Websites are increasingly becoming more than an entry point. They are a critical tool for delivering on a business’ brand promise. Mobile apps in some cases are the product(s).  In other scenarios, mobile apps may be an extension of an existing product or service, offering increased value (experience) of engaging with that organization. It could be a digital product or service focused on sales enablement, product delivery, customer service, etc… 

To accomplish this, you need to understand your audience. This understanding is an essential foundation for creating, delivering, and managing the customer experience. It  may very well determine if your product or service is successful. 


What is Empathy?

Before we dive into the details of what Empathy Mapping is let’s talk about what empathy means. 

Empathy is the experience of understanding another person’s condition from their perspective. You place yourself in their shoes and feel what they are feeling. 

The ability to develop empathy is at the very foundation of design thinking, and the disciplines focused on customer experience (a.k.a. User Experience) design. It is essential for developing a deeper understanding of your audiences, and how you can create the best solutions to meet their needs.  

When you create or work to improve a digital product, it is essential to remember that being empathetic requires us to withhold from making assumptions, to discard biases, and actively engage with your audiences.   When we do this, we are able to cultivate an understanding of someone else’s situation and how they’re feeling. We are able to then respond appropriately to their unique situation. 


How Empathy Mapping Helps

Empathy Mapping is a collaborative process used to visualize and articulate what an organization knows about a particular audience.  It externalizes knowledge about a specific audience in order to create a shared understanding of their needs, what they are thinking, feeling, seeing, hearing and doing. 

It is effective in guiding teams into a customer-centric mindset. It also facilitates a focused development of more impactful solutions, and aids in decision making. 

The empathy-mapping process helps distill and categorize your knowledge of the audience into one place. 

It can be used to:

  • Categorize and make sense of qualitative research such as research notes, survey answers, user-interview transcripts, etc. 

  • Discover gaps in your current knowledge and identify the types of research needed to address it. A sparse empathy map indicates that more research needs to be done.

  • Create personas by aligning and grouping empathy maps covering individual users.


7 Elements of an Empathy Map Canvas 

There are several formats of Empathy Maps. The Empathy Map Canvas is a great format for product teams, as it delves deeper into the context of the target audience and their situation. This version was produced by Dave Gray in collaboration with Alex Osterwalder, designer of the business model canvas. 

To download the template click here. 

This version goes beyond the traditional format that is split into 4 quadrants to help to articulate and communicate key information the rest of the team can benefit from. This format also prompts a deeper conversation that helps build a common language and understanding

Here are the 7 quadrants that make up the Empathy Map Canvas and questions. Each area helps to create a deeper understanding to illustrate the target audience persona. 

  1. Who are we empathizing with?
    • Who is the person we want to understand?
    • What is the situation they are in?
    • What is their role in the situation?
  2. What do they need to do?
    • What do they need to do differently?
    • What job(s) do they want or need to get done?
    • What decisions(s) do they need to make?
    • How will we know they were successful? 
  3. What do they see?
    • What do they see in the marketplace?
    • What do they see in their immediate environment?
    • What do they see others saying and doing?
    • What are they watching and reading?
  4. What do they say?
    • What have we heard them say?
    • What can we imagine them saying?
  5. What do they do?
    • What do they do today?
    • What behavior have we observed?
    • What can we imagine them doing?
  6. What do they hear? 
    • What are they hearing others say?
    • What are they hearing from friends?
    • What are they hearing from colleagues?
    • What are they hearing second hand?
  7. What do they think and feel?
    • Pains – What are their fears, frustrations, and anxieties?
    • Gains – What are their wants, needs, hopes, and dreams?

The process is as valuable as the visualization of your empathy map. It provides invaluable texture to your target audience personas and how to think about their entire user journey.  


How to Create an Empathy Map That Improves Your Customer Experience

1) Don’t empathize with just your ideal audience

One of the most common mistakes when developing audience personas is  only focusing on the ideal customer/user. While this individual is important, they rarely capture the full depth and nuance of your target market, the different contexts and varying situations that they’re living. 

Think back to the last time you were on an airplane. What was the context of your situation? Were you traveling for work? Was it to go on vacation? Maybe it was to get home before your son or daughter was born. Maybe it was to see a loved one for the last time. Now imagine how that might have felt if the gate agent was rude? Or you had a connection to make and your flight was two hours delayed? What would you be thinking, feeling, and doing in that moment?

We are all impacted by the context of a situation in very different ways at different times in our lives. As we create experiences, it’s important that we don’t look at just the ideal scenarios but design solutions, experiences, products, and services with a broader, deeper understanding. The job your product might require it. 


2) Unlock insights from new and existing research  

An impactful empathy map is based on real data. You can create your empathy map from user interviews, observational studies, and qualitative surveys. The use of empathy mapping is most common at the beginning of a project within the UX design process. The insights that can come from this exercise can help to inform your strategy, define product or service requirements, prioritize opportunities to address the needs of audiences, and deliver the most value. 

A second often-missed opportunity is  conducting the empathy mapping exercise for your existing digital product or service. It can  unlock new insights, opportunities, and challenges that determine your roadmap going forward. Empathy maps can also be a great way to get a deeper understanding of what an organization thinks they know vs. what they don’t know about an audience. When applied in this way, you can conduct a gap analysis to highlight where additional research and conversations with customers could be invaluable. 

3) Encourage cross-functional team participation 

You and your team  may be responsible for creating the product (solution) but who’s responsible for selling, delivering, and supporting it? Empathy mapping is a great tool for bringing teams together. This cross-functional collaboration helps to reveal  team members’ thinking, and their understanding of a persona. Another big benefit of this approach is that it often pulls together insights that can get siloed within a specific stage of the customer journey and the teams that support them at that point. By incorporating a cross-functional approach you are able to obtain a 360-degree view of each persona.  

Each team participant should write their responses on post-it notes and stick them to the map as well. The discussions that evolve from people sharing and talking through their sticky notes as they place them on the Empathy Map is an invaluable part of this process.  This creates a collaborative space where people ask questions, and identify patterns, and you can start grouping of similar attributes. This assists in improving the process, and the results of mapping. At the end of an empathy mapping session, ask them what new insights they learned that will help them during product development or what assumptions they have about the users they’d like to validate. 


Create Better Digital Products and Services

Whether your digital solution is customer facing or internal, empathy mapping can help to align your team, remove biases, unearth a deeper understanding of what drives user behavior, identify new opportunities, and provide a lens to prioritize your efforts. This insight allows you to focus and work  towards having the highest level of impact in the research, planning, experience design and technologies you invest into.

We all want to be understood, to be valued, and to make a positive impact. One of the biggest challenges people face today when delivering digital products and services, whether you’re a product manager, user experience designer, or an engineer, is the lack of a common language. This is compounded by the fact that when we do have a common language, we may not have a shared understanding of the language.  

The need for a common language and understanding is only amplified as businesses evolve to adopt, integrate, and leverage digital products and services as a crucial component of their success. 

If everyone is speaking a different language or has a different understanding of what is being said, how do you effectively communicate? This challenge is present in every organization at every level. Imagine you are trying to create a digital product to solve a well-defined problem but all the members of your team speak a different language. How will this disconnect impact your team? They may feel frustrated, confused, disengaged, or even question their trust in the team. It can manifest itself in comments like:

  • They have no idea what they’re talking about.
  • Do they know what they’re doing. 
  • We keep going over this. We need a reset to move forward.
  • Are they competent? 
  • It’s not working out. 

Do any of these sound familiar? In many cases, these are symptoms of a simple yet well-disguised issue. This issue is the lack of a common language and/or a shared understanding of the language being used. Every industry, organization, and many business units have their own terminology and acronyms. It is crucial to bridge the gap between the disciplines of leadership, product management, UX/UI design, and engineering.


Understanding How to Increase the Competence of Your Team 

Understanding a common language gives us a shorthand, a way of working, communicating, and achieving remarkable things together. It enables your business to move faster, to be more effective, and to build better products. In other words, you are increasing the competence of everyone. 

You can see this illustrated by looking at (examining) the four stages of the competence learning model. 

Hierarchy of Competency


Unconscious Incompetence

A summation of the first stage is that we don’t know what we don’t know. Being unaware of the importance in this case that a common language and understanding is a necessary and useful skill to support your success. 


Conscious Incompetence

Moving to the second stage requires you to recognize the value of the skill/knowledge, that you don’t yet have, understand, or know how to do. 


Conscious Competence

In the third stage, you understand or know how to do something. However, demonstrating the skill or knowledge requires concentration. 


Unconscious Competence

The fourth stage is when you have had so much practice with a skill that it has become “second nature” and can be performed easily. As a result, the skill/knowledge can be leveraged effortlessly, and possibly taught to others.

To build competence, we create steps, processes, and systems to help us accomplish remarkable things. We’re introduced to this way of learning at home, in school, and every day in the workplace. 

When embarking on digital transformation, creating a new digital product, or scaling an existing service offering, your team’s conscious competence is directly impacted by the common language and understanding you have across the multidisciplinary teams that will be essential to your success.

This article is for the people who are leading, managing, and delivering digital products and services. Providing you a glossary of some of the most common product development terminology, and a deeper understanding of what they mean to support people building their competence, communication, and collaboration. 


A Glossary of the Top 33 Digital Product Development Terms to Build a Shared  Understanding

This list is based on more than 150 terms we identified. We then narrowed it down to the core Business, Design and Technology terminology listed alphabetically to support the multiple disciplines working to create great digital products and services. 


A/B Testing:  

A/B testing is the practice of comparing two versions of an element of content, user experience architecture or functionality, — websites, apps, marketing emails, etc.— in order to see which version performs better. The two versions (A and B) are presented to users at random or within control groups based on user criteria or market segmentation in order to gauge effectiveness.


Accessibility:

Accessibility refers to the inclusive practice of removing barriers that prevent people with physical limitations from accessing web, mobile and other types of digital products. These limitations might affect vision (including color blindness), hearing, physical movement, speech, cognition and other neurological functions (including susceptibility to seizures caused by flickering or flashing effects).

Accessibility is not to be confused with usability, which is the extent to which a digital product (such as a website, mobile app, software as a service, etc) can be used by a user to achieve a specified goal(s), effectively, efficiently and satisfactory within a specified use case.  

To learn more about this topic check out:


Agile Methodology:

Agile is a project, software development, and workflow methodology that focuses on continuous iteration. The agile methodology advocates for adaptive planning, evolutionary design and development, early delivery, and continual improvement, and it encourages rapid and flexible response to change. Digital product requirements and solutions evolve through the collaborative effort of self-organizing and cross-functional teams and the end user (a.k.a customer or employee). 

The term agile was popularized by the Manifesto for Agile Software Development, incorporated a broad range of software development frameworks, including Scrum and Kanban. 


API (Application Programming Interface):

API is the interface used to access the features or data of an operating system, application, or other service. It’s the intermediary that allows two applications to talk to each other.  In other words, an API is the messenger that delivers your request to the provider that you’re requesting it from and then delivers the response back to you. In modern service-oriented architecture, APIs are also used for components of the same system to communicate with each other.

An API defines functionalities that are independent of their respective implementations, which allows those implementations and definitions to vary without compromising each other. Therefore, a good API makes it easier to develop a program by providing the building blocks.

Examples of APIs include Google Maps API (allows developers to embed Google maps on web pages), Twitter APIs (allows developers to access core Twitter data), and Amazon Product Advertising API (allows developers to access Amazon’s product database and advertise Amazon products on a website).


Brand Guidelines:

Brand Guidelines are documentation of the strategic information about the brand’s purpose, personality, and promise. Examples of elements in brand guidelines include customer experience design principles, identify (logo and icon) usage, typefaces, color palette, imagery (photography or illustration) styles, interaction and gesture samples, etc. Brand Guidelines may also include written standards include consumer-facing messaging samples such as headlines and positioning blurbs, keywords and phrases, terminology, micro-copy guidelines, spellings, and terms to avoid. The Brand Guidelines provide specific instructions and specifications for the application of these standards in various channels and mediums. 


Conversion:

Conversion is defined as an action that a person can complete, which is measurable. Depending on the organization’s goals, a conversion can be a variety of actions breaking down customer (user) engagement touchpoints from becoming aware of a business’ offering, requesting a demo, subscribing, delivery of access to a product/service, completion of onboarding, etc.  


Customer Experience (a.k.a User Experience):

Customer Experience is the sum of a person’s experience when engaging with a brand, business and using their product or service. It encompasses their perceptions, emotions, attitudes, actions and the memories associated with each stage of the customer lifecycle.   

The practice of Customer Experience Design (a.k.a UX Design) is the discipline of designing products/services with the focus on the quality and thoughtfulness of the entire user experience. Every touchpoint within the customer’s interaction with a product/service is designed to deliver experiences based on the brand’s promise.


Data (Transactional + Consumption): 

Data in the context of creating and delivering digital products and services should be defined based upon two types, transactional and consumption. Transactional data includes financial and logistical information related to customer inquiry, conversion rate, on-boarding time, number of active users, number of hours worked, and application availability (uptime), etc. Consumption data is focused on behavior, examining how the product or service is being used, identifying patterns, and contextually related outcomes based dimensions of time, location, attitude, etc.


Data-as-a-Service:

Data-as-a-service (DaaS) is a strategy to break down silos and enable access to business-critical data upstream and downstream throughout an organization. While this is also commonly looked at as a function of Cloud Computing which is only one manner in which this can be provided. DaaS focuses on protecting data integrity, eliminating redundancy and reduces associated expenditures.


Empathy Map:

An Empathy Map is a collaborative visualization used to articulate what an organization knows about a particular type of user. It externalizes knowledge about users in order to create a shared understanding of user needs, examining what they are thinking, feeling, seeing, hearing and doing. It is often used to shift teams into a user-centric mindset as well to focus on developing more effective solutions and aid in decision making.


Friction (a.k.a. Pain Point): 

Friction is the interactions that inhibit people from intuitively and painlessly achieving their goals across their entire customer journey. Negative friction can be also thought of as pain points, barriers, or as symptoms of a larger problem. Common examples of negative friction would be high bounce rates, reduced conversions, frustration to the point of abandoning a task and customer attrition. Positive friction is the intentional design of a barrier to promote a specific behavior. Common examples of positive friction would be to prevent users from making bad decisions, can help to build skills and increase memory retention. 


Functional Requirements: 

Requirements define the specific behavior and governing rules between specific inputs and the resulting outputs (manual or automatic) from interacting with a digital product or triggering an automated process. In many cases functional requirements are confused with features. Features do not address the specific business, design and technical details to be considered. Functional requirements encompassing all the necessary information required to deliver the intended outcome. 


Hybrid Apps:

Hybrid apps are applications that are built to work across different device platforms (i.e. Apple’s  iOS and Google’s Android) but share a common codebase (as opposed to Native Apps, which have distinct codebases unique to their device platform). This is accomplished by using cross-device code frameworks and tools that compile a shared codebase into distinct apps for each device platform.


Information Architecture:

Information architecture lays the foundation for how your digital experience will organize and display information. It addresses the website, app or IoT structure, the paths through which users will navigate, the way information will be formatted, and the hierarchy and labeling of each component.


KPI (Key Performance Indicator) 

KPI’s are actionable metrics that enable an organization and business function to keep its strategy on track. They  enable proactive management, providing key information necessary to decision makers to work towards achieving desired business results. 

Examples of some common KPIs are Attrition Rate / Churn Rate, CAC (Customer Acquisition Cost), CLV (Customer Lifetime Value), TCO (Total Cost of Ownership), AOV (Average Order Value) to name a few. 


MVP (Minimal Viable Product): 

MVP has many definitions. You can find it defined as the smallest possible experiment to test a specific hypothesis, all the way up to the tangible realization of a product vision.

MVP is a concept from Lean Startup that stresses the impact of learning in new product development. Eric Ries defined an MVP as that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.

Another way to define MVP (minimum viable product) is as the smallest possible product that has three critical characteristics: people choose to use it or buy it; people can figure out how to use it; and we can deliver it when we need it with the resources available – also known as valuable, usable and feasible.


Native Apps:

Native apps are built specifically to a device platform like Apple’s iOS (coded in Objective C or Swift) or Google’s Android (coded in Java or Kotlin). Native mobile apps provide fast performance, a high degree of reliability and access to a devices’ various features. A native app has a unique codebase for each device platform that it targets.


Plan (Planning): 

Plans are made up of tactics that define exactly what we’re going to do, when we’re going to execute them, and what will follow. A plan focuses on deploying the appropriate capabilities, processes, tools, and resources at the right time. Essentially, in following this plan and taking these steps, success will be attained moving forward.


Product Strategy:

Product Strategy defines the value you will create in a succinct and tangible way; where to focus, why, and what it will take to achieve that value. This empowers your team to focus on the right things and determine how to facilitate the delivery of a great product or service. 

Having a strategic foundation provides clarity.  It promotes a shared understanding that organizations, business units, and teams must have in place to pursue, and ultimately achieve their goal.  Depending on your business goals your strategy may be focused on a single product or it could guide a suite of products that become a cross-connected platform. 

To learn more about this topic check out:


Proof of Concept (POC):

A Proof of Concept (POC) is the pilot project or experiment, which demonstrates an idea, product, service, process, design concept or integration point (i.e. software to hardware) to ascertain its feasibility. A proof of concept is usually small and may or may not be complete. Typically a proof of concept would be smaller than a minimal viable product.


Prototype / Prototyping:

A prototype is an early interaction, model, or release of a product built to test a concept or process. There are many methods of prototyping and when and how it can be applied to the product development lifecycle. This can include: 

  • Paper Prototyping (Sketching) is the process to record the main ideas (usually on paper).
  • Low-Fidelity prototypes – rough representations of concepts that help to validate those concepts early on in the design process. In a nutshell, this is a raw presentation of our ideas. Low-fidelity prototyping is usually used by design teams to emphasize interactions and thoughts.
  • Rapid Prototyping is a mid-fidelity technique based on user research. Rapid prototyping helps the product team to think about what needs to be done to reach the end goal. It goes through a series of quick iterations and feedback sessions that could potentially solve the problem. 
  • High-Fidelity Prototyping (Interactive prototyping), unlike low-fidelity prototyping, high-fidelity prototyping requires more time, specialized skills and resources. A high-fidelity prototype is a computer-based interactive representation of the design in its closest resemblance to the final version in terms of details and functionality. 
  • Functional Prototyping is a prototype developed using the code standard of the platform and/or device you’re building for. It can be seen in the browser or can be loaded to a specific iOS or Android device. 


Responsiveness:

Responsive refers to a method of designing and developing digital experiences that automatically arranges and fluidly scales the information architecture, content and accessible functionality to adapt to different screen resolutions that are linked to the device type and user scenario. 


Roadmap:

A product roadmap is a shared source of truth that outlines the vision, direction, priorities, and progress of a product over time. It’s a plan of action that aligns the organization around short- and long-term goals for the product or project, and how they will be achieved.


Service Blueprint:

A Service Blueprint is a technique used for innovation and diagnosing problems impacting both operational efficiency and the customer experience. Some of the things a service blueprint will help surface are the steps customers go through, touchpoints, people, systems, policies, observational facts, metrics, questions/unknowns, critical moment, opportunities, etc.  It can help each team within a business visually see where they fit in supporting the customer experience and understand the interdependencies across the organization fulfilled operationally.


User Flows:

User flows illustrate the way users interact, in a step-by-step manner, with a digital product, a process, or to accomplish specific tasks.  User Flows also include decision-making points and alternative paths in the flow based upon their responses to key points. 

User flows art commonly created based upon user scenarios and provide a level another level of fidelity to a moment within the User Journey. 


User Interface (UI):

A user interface includes all the parts of a website, mobile app, or custom application, etc. that the user can interact with. 

User interface design is the process of creating an experience that is easy to access, understand, and use to facilitate the intended behavior or action. UI brings together concepts from interaction design, visual design, and information architecture. 

The user interface for digital products commonly takes into consideration accessibility, language (text, tone, microcopy), iconography, imagery, typography, color, etc. In addition, it will also commonly include user interface pattern definitions to address gestures, responsiveness, error handling, micro interactions, transitions, etc. Today this can also extend to voice-controlled products. 


User Journey:

The User (also called Customer) Journey illustrates the customer’s relationship with a brand or product over time and through each interaction phase. The journey typically starts with an awareness phase and evolves through various stages of a relationship with the brand. 


User Stories:

A user story looks at creating a solution from the end-user’s perspective. This allows all project stakeholders to collaborate on defining the user’s needs that are necessary to achieve the desired product goals. 

Each user story is written in simple language, as plainly as possible, which means every feature represents clear value to the user. A great user story outlines an achievable goal, sensitive to user context, and sets the bar for success for the whole project team.

To learn more about this topic check out:


User Testing:

User Testing is a method for getting rapid customer feedback most any customer or employee experience, including new concepts, user flows, processes, etc. across your websites, mobile apps, prototypes, and real-world experiences. The intent is to help create better solutions and remove cognitive bias that impedes results. 

With continuous user feedback, you can:

  • Identify pain points in your customer experience
  • Understand what your customers or employees are thinking and feeling
  • Validate business and user experience decisions before committing resources
  • Inform stakeholders to make better decisions and product improvements


Value Drivers:

Value Drivers are the attributes that increase the value of a business, product or service to a defined target market. The greatest benefits of value drivers are how they inform your business model, provides a competitive advantage to a business, and supports critical decision making.

Value drivers can come in many forms. As an example, Amazon focuses on three primary value drives, 1) Lowest Cost, 2) Largest Selection, 3) Speed of Delivery. How they deliver on these values drivers is the unique makeup of the organization, ability to maintain focus and relevance. 


Vision:

The vision is the long-term overarching goal the company or business unit is aiming to achieve and the reason for creating the product(s). It provides your team with a collective purpose, acting as the product’s true north, facilitating alignment, and effective collaboration. 

The importance of vision cannot be overemphasized. You need to provide people with clarity of the big picture goals and how the product will help fulfill that vision. People also want to know how their contributions will make a difference, whether on the product team or working across the organization.


Waterfall Methodology:

The Waterfall methodology is also known as the Liner Sequential Life Cycle Model. It follows a sequential order, breaking down the digital product lifecycle (i.e. ideation, research, prototype, design, develop, test, release, support) into activities whereby each phase depends on the deliverables of the previous one and corresponds to a specialization of tasks. A product team only moves through each phase of the product development lifecycle if the previous step is completed successfully. It’s common based upon the nature of the waterfall methodology that the outcome of the project needs to be clearly envisioned from the beginning.


Wireframe(s):

Wireframing is an important tool for product design and development. Wireframes are the “blueprint for design.” They’re supposed to connect the underlying conceptual structure (or information architecture) to the surface (or visual design) of a website or mobile app. More specifically, they’re visual representations of an interface, used to communicate the following details to get everyone on the same page:

  • Structure – How will the pieces of this site/app be put together?
  • Content – What will be displayed on the site? 
  • Informational hierarchy – How is this information organized and displayed?
  • Functionality – How will this interface work?
  • Behavior – How does it interact with the user? And how does it behave?

Wireframes are not intended to represent the visual design, graphic elements, or convey the brand or identity.


Your Team Competence and Success   

Today product teams need to move fast, make critical decisions quickly, and deliver great digital products and services. We need everyone to have conscious competence and we need to provide them the path. It doesn’t matter if you’re focused on customer experience or operations, the power of a common language and understanding is essential.

Use this glossary as a foundation for your team, discuss the terminology, customize it to your organization, and co-create with your peers across teams and with your leaders. This process will give you a new tool to help your teams be more effective, increase their engagement, and build trust.  

A product owner launching an enterprise application has a multitude of device platforms to consider. There are native phone apps for iOS and Android, a responsive web application, and potentially even Mac, Windows, and Linux desktop applications. This increases the level of effort to build and support so many applications, which can be cost prohibitive to businesses. One common workaround is to prioritize certain device platforms (such as iOS over Android), which can lead to user experience fragmentation. Fortunately, a new tool has been added to the digital product toolbelt that promises to help with enterprise mobile app strategy: Progressive Web Applications (PWAs).

Rich web applications (powered by React, Angular, and other JS frameworks) have become the norm on the web over the last few years. As they become more powerful, the differences in functionality and quality of UX between those web applications and native mobile apps are shrinking. Take Twitter for example: browsing their website on a mobile device looks and feels very similar to the experience on their mobile app. This is where the progressive web application (PWA) standards close the gap, allowing web applications to appear to the end-user like a native mobile app.

The key features of PWAs today are:

  • Can be installed on the home screen with an app icon
  • Run full screen without browser chrome
  • Fast load time
  • Local files and storage
  • Offline usage
  • App switching works just like native apps
  • Push notifications (not available on iOS)
  • Background sync (only available in Chrome)
  • API access (camera, geolocation, audio, video, etc)
  • Can be deployed to Google Play store and Microsoft Store for Windows 10 (not available on iOS)

A well-executed progressive web app will seamlessly make the shift from appearing as a website to appearing as a mobile app. Users most likely wouldn’t even know that they are using a PWA instead of a native iOS or Android app.

To get an idea of how well PWAs can be implemented today, I recommend checking out the following examples and installing them on your mobile device or desktop:

Steps to add a PWA to your homescreen on iOS
iOS/Safari steps to add a PWA to the homescreen

Android/Chrome link to add a PWA to the homescreen

Chrome link to install a PWA on a desktop
PWA desktop app example
Trivago PWA desktop app running on MacOS

Enterprise Mobile App Strategy: The state of PWAs going into 2020

When observing Google’s efforts to enable PWAs, it appears that they support PWAs becoming a standard for mobile applications. Their Chrome team is leading the charge, adding new PWA features in virtually every Chrome release. 

Unfortunately, Apple is not as supportive of PWAs in public. They haven’t been assigning as many resources to the implementation of the standards that make up PWAs as other companies. One could argue that this likely is to protect its iOS App Store business. PWAs present a threat to Apple’s App Store revenue, which has added up to over $40 billion since the App Store launched 10 years ago. PWAs aren’t subject to Apple’s app approval and revenue-sharing model, circumventing their walled garden. Google faces a similar threat to their Play Store revenue, yet have allowed their teams to pursue PWA support more rapidly. Largely due to the lack of support by Apple, PWAs have only slowly been hitting the mainstream. Most smartphone users are unaware of PWAs, relying entirely on native apps for their daily needs.

Since 2017, Apple has slowly been adding PWA support to iOS, but they remain the bottleneck in PWA adoption. The good news is that as of iOS 12.2, which was released in March 2019, Apple has finally raised their support to a level that makes basic PWA applications functional on their devices. And with iOS 13, due out in the fall of 2019, several more limitations in their PWA support will be addressed. Given these developments from Apple’s side, PWAs are becoming viable replacement options for both Android and iOS native apps.

If you are considering a PWA for your enterprise mobile app, you’ll need to evaluate if any of the following iOS PWA limitations will restrict the functionality of your app. With the launch of iOS 13, we anticipate that PWAs on iOS will still not be able to do the following:

  • Push notifications
  • Background syncing
  • Open web links in-app (link capture)
  • Deploy to the app store
  • Ability to show install prompts and install confirmations (appinstalled and beforeinstallprompt events)

The current list is based on the public beta of iOS 13 and we will update it as iOS 13 is launched in mid-September 2019 so you can plan for 2020.

Key benefits of Progressive Web Apps vs Native Apps

PWAs work across device platforms (desktop/mobile, iOS/Android, Windows/MacOS/Linux), anywhere there is a browser

Building a single PWA can replace the following applications, which traditionally would have required separate codebases:

  • Web Application
  • iOS App
  • Android App
  • MacOS Application
  • Windows Application
  • Linux Application

In this scenario, using the PWA standards would mean that only the web application would need to be built and maintained. The upfront and ongoing development cost could be reduced by as much as 80% compared to the traditional native application approach, if the number of codebases goes from five to one. Even if you are using wrappers such as Electron or Cordova, time can be saved by removing the wrapper deployments from the development workflow.

Standardized user experience across all mobile device platforms

Many product owners struggle with delivering the same mobile user experience on multiple device platforms. This is often the result of different teams working on an Android application vs. an iOS application. Using a single PWA would lead to both UX and feature parity.

Cuts out the app store

PWAs are not restricted by the iOS App Store and Google Play Store revenue splits. They lend themselves well to subscription-based applications that don’t require an upfront purchase to install the application. PWAs also provide immunity to the app stores’ sometimes arbitrary app approval policies.

Can be found and crawled by regular search engines

Many apps contain content that could be indexed by search engines, but is unfortunately hidden inside of the app ecosystem that can’t be crawled. Since PWAs run as websites behind the scenes, Google and other search engines can crawl and index any public content in your app. This can improve the visibility of your app and attract new users that may subsequently be prompted to install the app once they click through from Google.

No risk of removal from app stores

One of the biggest business risks for app-based businesses is that Apple or Google can revoke your certificate, which disables your app instantly. This happened to Facebook earlier this year, when Apple revoked their app certificate, crippling internal business operations for days until Apple reinstated its certificate. Running a PWA is independent of Apple’s or Google’s certificate system and therefore outside of their reach.

Use significantly less storage

Native apps have become massive consumers of on-device storage. It’s not uncommon to see apps that use more than 100MB of storage on a phone when they are first installed. PWAs are developed for the web, so they are more lightweight than native apps. For example, the Twitter native app uses 86.1MB, as opposed to 0.19MB for the PWA. The Pinterest native app uses 103MB, compared to 0.18MB for the PWA. This is because PWAs leverage the device’s browser for much of the behind-the-scenes functionality, as opposed to needing to build it all into the app executable.

Downsides of Progressive Web Apps compared to native apps

Lack of user awareness

Everyone knows how to find an app on their respective app store and install it. Very few people know how to install a PWA from their browser’s menu though. Google fortunately now allows deploying PWAs into the Google Play Store, although they haven’t published any official documentation to support this yet. iOS users will likely be living in the dark for a while though.

No iOS app store presence, promotion or discovery

The iOS App Store has become a popular search engine in its own accord; users know to come here to look for brands and their apps. The store also offers promotion options and ways for users to discover apps they weren’t actively looking for. Placing a web application into a webview wrapper, such as Cordova, and launching it to the App Store still remains an option though.

Enterprise deployment options limited

Many enterprises use mobile device management (MDM) software to automatically deploy their internal applications to their employees’ phones. Google and Apple both support PWAs in their own enterprise deployment tools (Google Play EMM and Apple Configurator), but third party MDM support for PWAs is lagging behind.

Some hardware integrations missing, such as phone/SMS, bluetooth, fingerprint, contacts, calendar, system settings

Mark this one as “under development”. Fortunately, the standards to support some of the lower-level hardware integrations are already implemented in Chrome, such as the Web Authentication API and the Web Bluetooth API. It will be a while before these standards are supported across all browsers and devices.

Standards surrounding PWAs are still evolving

Since the standards that make up PWAs are still evolving and browser/device support is changing (typically for the better), product owners need to be ready to make adjustments to their apps on short notice. When supporting a native iOS or Android app, product managers will usually have a few months’ notice to test their app on a new operating system version before it is released. This becomes exponentially harder though if an application has to support multiple browsers across multiple device platforms. A recent culprit has been Apple, which actually has introduced new bugs into their PWA support with new iOS version releases.

The future of Progressive Web Apps

While Apple remains close-lipped about their future plans for additional PWA support (we only know what iOS 13 will bring by manually working through the beta release), we know that PWAs are here to stay. Chrome keeps pushing the envelope on what PWAs are capable of doing and consider it a key functionality of their web platform. Firefox and Microsoft, while lagging a bit, are also making progress with their support of the standards that make up PWAs. At this point going the PWA route as opposed to building native apps still requires careful evaluation, but we see this balance continually shifting towards PWAs over time.

If you want to stay on the cutting edge of PWA developments we recommend following Maximiliano Firtman, who is one of the leading PWA proponents and has been doing a fantastic job covering Apple’s PWA support. He also provides a PWA online course that walks through many of the topics in this post in more detail. Google also keeps their PWA developer site up-to-date. If you are working on your digital product strategy, also check out our post on how to build a digital product platform for scale.

Many great ideas and opportunities are never realized. You may have experienced this yourself working on a digital product that never came close to realizing it’s potential. One of the reasons that so many organizations fail at delivering valuable products and services is the lack of a well-defined strategy or the complete absence of a strategy. 

Creating a digital product or service is complex. Identifying the right opportunity, selecting where to compete, and solving a problem for customers in a viable, unique, and sustainable way (a.k.a your competitive advantage) are the cornerstones of a successful strategy. If you boil all of this down it’s simple — create value for your audience and as a result you will create value for your business. In an interview, Jeff Bezos phrased it this way, “In the long term, there is never any misalignment between customer interests and shareholder interests.” 

Unfortunately, strategy has become a buzzword for many, but it has never been more imperative than it is today. 

There is significant confusion today about what strategy is. There is an overwhelming amount of information, fads, and academic resources. Harvard Business School Professor and leader in strategy, Michael Porter delineates the importance of strategy in his work.  To summarize: the quest for productivity, quality, and speed have spawned a remarkable number of management tools and techniques. These tools and techniques have incrementally, and almost imperceptibly taken the place of strategy, but they are not strategy.

A strategy rests on making essential choices. To help you and your products be as successful as possible we’ve stripped away the noise. Let’s look at what a great digital strategy needs to include.

What is a digital product strategy? 

A great strategy defines the value you will create in a succinct and tangible way; where to focus, why, and what it will take to achieve that value. This empowers your team to focus on the right things and determine how to facilitate the delivery of a great product or service. 

Having a strategic foundation provides clarity.  It promotes a shared understanding that organizations, business units, and teams must have in place to pursue, and ultimately achieve their goal.  Depending on your business goals your strategy may be focused on a single product or it could guide a suite of products that become a cross-connected platform. 

A strategic foundation is made up of five core elements: the product or service vision, the challenge that needs to be solved, its current impact, the target audience whom the challenge is being solved for, and the desired future outcome. 

To be clear: a plan is not a strategy, which compounds people’s confusion. Plans are made up of tactics that define exactly what we’re going to do, when we’re going to execute them, and what will follow. Essentially, in following this plan and taking these steps, success will be attained moving forward.  Plans don’t account for the unknowns, changes, prioritization, or provide a framework for critical decision making. A plan without a strategic foundation gives people a false sense of clarity and security that often leads to failure. When a solution is seen as a quick-fix, without understanding the complexity of the challenge that needs to be solved, failure will often be the result. Understanding the difference between complex things vs. complicated things becomes extremely important. (To learn more about this concept check out the Cynefin framework in this video.) 

You will want to have a plan, but know that it will change, probably more than once. A plan needs to be adaptive, and built upon a solid strategic foundation.  

Five Core Elements of a Digital Product Strategy 

1. Vision

The vision is the long-term overarching goal the company or business unit is aiming to achieve and the reason for creating the product(s). It provides your team with a collective purpose, acting as the product’s true north, facilitating alignment, and effective collaboration. 

The importance of vision cannot be overemphasized. You need to provide people with clarity of the big picture goals and how the product will help fulfill that vision. People also want to know how their contributions will make a difference, whether on the product team or working across the organization. A well-articulated vision is also of tantamount importance for people to know what does not require their time, energy and depletes limited resources.

For example, your product vision may be to provide a platform that improves the way people work, unlocking the speed at which they can collaborate.

2. Challenge

The second core element is the challenge you’re solving for; providing context for what it will take to realize the long-term vision. By understanding the challenge we can then start to differentiate between symptomatic issues and the root causes. 

This allows us to break down the large challenge into smaller manageable, specific, and actionable issues to focus on solving. Notice we’re not trying to solve the issue. We’re making sure we understand the complexity of the challenge. Breaking down a challenge helps to unveil essential insights that will inform the success of the product moving forward. 

For example, the challenge you need to solve is subscriber retention. The most immediate opportunity is to address a poor on-boarding experience.

3. Impact

Next, we need to identify and understand the impact of the issues on the business and/or the audience. What is the baseline or current state?  This helps to clearly understand (measure or delineate) the current business state and measure the progress as people work towards the intended outcome.  Understanding the impact also allows you to highlight qualitative and quantitative metrics to support the business case by using a single variable or a cumulative effect.

For example, the impact of the unmet challenge is the high costs of new subscriber acquisition combined with customer service inquiries averaging a cost $650/user. 

4. Audience

The foundation of a successful digital product is understanding the wants and needs of your audience. Whether your users are external or internal, your strategy must define who they are. You may have multiple user types that need to be considered. There is not a single solution that is perfect for everyone. With a full understanding of our audience,  it is possible to align the focus of the vision with your intended outcomes.

For example, your ideal customer may be a small businesses with 10+ active users that can realize the full benefits of improving the way their employees work.

5. Outcome

The fifth core element of your digital product strategic foundation is identifying the desired outcomes you are hoping to achieve by addressing the issue(s) that make up the larger challenge. 

Another way to look at it would be what is the future state or results(s) you want to achieve. How will this feature, product or suite of products address the individual issues?  How will this promote long-term potential benefits and enable other outcomes if done correctly? While the vision articulates the big picture goal, outcomes focus on the results of addressing issues in an incremental, measurable way that moves the organization forward. To build that forward momentum we need to understand the first step and take action toward realizing those outcomes. Often, this becomes invaluable in helping to identify an ideal starting point. Ultimately, this will also help to ensure everyone involved is on the same page, having a shared interpretation of success.  It allows benchmarks to be established that will measure the progress toward the vision and desired outcomes.

For example, the desired outcome you are aiming for is an increase of 40% in the customer onboarding completion rate and a 25% increase in customer adoption within the first 90 days.

The shift from strategy to execution     

Having a strong strategic foundation is imperative.  It is essential in providing clarity, team focus, informing better decision making, accelerating the speed of delivery, and team collaboration.  Conversely, poor execution of a great idea is as detrimental as not having a strategy at all. Shifting from strategy to effective execution is not an easy process. It requires alignment, excellent ongoing communication, often additional skills, and a culture that supports change. This is where proper planning comes into play.  A plan that focuses on deploying the appropriate capabilities, processes, tools, and resources at the right time.

There are significant considerations in leadership, management, and across the entire product development lifecycle (i.e. waterfall, agile or a hybrid model).  However, with a solid foundation in place, you’re forging the right path towards success. 

As you and the rest of your team works to identify solutions to your prioritized issue(s) you will have the information necessary to ensure you are working on the right things.  It enables you to do the right things in the right way. 

You can now begin to understand who across your organization will need to be involved to create, execute, and support your product. Essentially defining a clear picture early on of roles and responsibilities. 

In exploring each solution you can also start to map out and understand the interdependencies.  Interdependencies in this scenario are the relationships between people, processes, and systems that will be necessary to bring your product to market. When business cases are developed prematurely in the process without this insight, things will often fall apart.  When executed correctly, this is when business cases can be defined and outline the true potential investment ahead. This information brings potential complexities to the forefront that need to be managed, crucial to your product’s success.

As you define the solution, you can now also start documenting your requirements addressing key business, design and technical considerations essential to delivering your product. 

A strong strategic foundation becomes a powerful advantage. It gives you critical insight, galvanizes our efforts into essential focus, and empowers our people to be at their best in any role. The market may decide who the next generation of winners and losers are, but you can take control of your own success, not skip the steps that so many do, and inevitably realize your opportunity.

When creating a mobile app or web application, do you have a strategy for how the static content in the application is managed? An app can contain a myriad of static content that wouldn’t make sense to load dynamically from a database or server each time the content is viewed. Some types of content that fall into this category can include:

  • Home screen content
  • Inline content blocks
  • Navigation labels
  • About us page content
  • FAQ sections
  • Video sections
  • Product information that isn’t stored elsewhere

This is a challenge our clients encounter regularly, and we love helping them solve this problem.

Why should you use a Headless CMS?

Traditionally, a mobile app or React application will have its static content embedded directly inside the application code. For apps geared toward traveling users or display kiosk applications that need to run locally, this is particularly true.  While embedding content is the most straightforward and easily implemented method, the downside is that any content update will require a code change, testing, and a redeployment. Options such as loading content from an XML or JSON file exist, but these still require some technical proficiency, and potentially a redeployment if the files are still embedded in the codebase, or a server setup to host the files elsewhere.

Our clients are better served if the content can be edited directly by the content owner responsible not just for the message but the users experience, be it the product manager, the marketing department, or someone at the helpdesk. Fortunately, a new breed of content management systems is specifically tailored to address this need. They’re called Headless Content Management Systems (CMS).

A Headless CMS provides a content management interface, much like a traditional CMS such as WordPress or Drupal. But instead of outputting the content onto a website, a Headless CMS makes the content available via an API to your web or mobile application. The application can then subsequently display content loaded in realtime from the CMS, or cache the content and permit it to be displayed offline without loading times.  This is particularly advantageous for large assets such as video files.

The difference between headless CMS data flow and traditional CMS data flow

While there are both self-hosted and cloud-hosted products available, we typically recommend our clients look at hosted products (CMS-as-a-Service). These provide the benefit of eliminating ongoing management of a CMS installation and hosting. Forget constant version patches to your open source CMS; this is all automatically handled by the CMS provider. Ultimately, long-term costs and expended effort are minimized while reliability and security are maximized.

How to Evaluate which Headless CMS to use

When evaluating a Headless CMS for an app project, we typically start with the following criteria:

  • How is content managed in the CMS, and how flexible is the data structure?
    Depending on the content in the application that our clients need to manage, we will want to find a CMS that allows matching the data types to the required content structure. If data types are complex and change frequently, we prioritize a user-friendly type of builder. If there are relationships between content types, we look for a CMS that has strong options in that area. This criteria is as unique as content requirements.

  • How is the data accessed?
    The most common data-access standard is via RESTful APIs, which provides a flexible foundation for most projects. In addition, some Headless CMS solutions offer SDKs or starter projects to jumpstart development, which can save time by providing CMS specific API connectors out of the box. Another rising standard is GraphQL, which reduces roundtrips between the app and the server. GraphQL also minimizes the amount of data transferred to the absolute essentials. If you are using third party tools and frameworks that are built around using REST, you’ll want to stick with a CMS that uses RESTful APIs. If your project is more greenfield though, GraphQL might be able to reduce your development effort and provide better performance.

  • Can file assets be managed and served from the CMS?
    Some apps include media assets, such as images and videos. In that scenario, the CMS needs to include an asset management module, as well as the ability to store files through the CMS in a cloud storage environment. Different Headless CMS solutions have varying limitations on these parameters. We ensure that the offering is aligned with the app’s content requirements. We are mindful to assess limitations such as size limit per asset, total storage amount, and included bandwidth.

  • How many records does the CMS allow?
    Some Headless CMS solutions have limitations on the total number of records that can be stored in the CMS. Depending on the specific use case of our projects this is something we are diligent to examine. One such example would be a database of property information that is batch uploaded into the CMS, which could consist of tens of thousands of records. Given that Contentful allows 5,000 records at the $39/month price level, and 50,000 records at the $879/month price level, this could be a deal breaker based on the project needs and budget.

  • Is a content delivery network (CDN) built into the CMS infrastructure?
    If the content is accessed and displayed in realtime from the Headless CMS, having a content delivery network available can save a few seconds in lag time. This is particularly true if an application we are working on has a global reach. For example, Contentful is hosted in the AWS US East data center, so a CDN would accelerate load times for users outside of the continental US.

  • How strong are the support resources and how big is the development community?
    Given the vendor lock that’s part of working with a Headless CMS, it is critical that we are confident the requirements of the application can be achieved with the selected solution. Having solid documentation and community support (Slack, forums, etc.) is key to this.

  • How old and established is the company?
    The oldest players in the Headless CMS industry were founded in 2013, but it seems that there are new Headless CMS providers emerging every month. We significantly study a company’s track record before making a recommendation, and would only recommend a younger company if the technological benefits outweigh the risks.

  • Is there a status page to shows uptime history?
    Building on the track record requirements, we look for transparency around platform uptime and frequency of issues. We’ll review a solution’s system status page for transparency of information as well as issue history. Good examples are https://www.contentfulstatus.com/ and https://status.graphcms.com/.

Our favorite Headless CMS solutions

Based on these evaluation criteria, the Headless CMS products that we are recommending the most to our clients are:

  • Contentful
    One of the oldest and most established players in the Headless CMS industry, Contentful checks the boxes for most of our projects with ease. From our experience we consider them the current market leader, which is also reflected in the strong community support available. We particularly appreciate the variety of code repositories on their Github account, which includes SDKs for several programming languages.  As mentioned above, they do have limits on the number of content records stored in the CMS, which many other providers do not, so look out for that if you anticipate storing a large amount of data in the CMS.

  • Prismic
    Like Contentful, Prismic is one of the older companies in the space. They offer a full-featured account for a single CMS user for free, which can be perfect for smaller or experimental projects, or anyone wanting to try a Headless CMS for their product. Even Prismic’s entry level paid account is only $84/year, undercutting most other mainstream competitors. Their team has also created a myriad of starter project libraries and SDKs that cover everything from Angular2 to .NET.

  • GraphCMS
    This solution is the first Headless CMS to use GraphQL instead of a RESTful API. We consider GraphQL superior to REST, but it is still a newer standard and in some cases the interconnectivity with other systems might be a limiter. GraphCMS’ entry point on pricing is a little higher than the other providers listed here (starting at $588/year), but if GraphQL is something you can take advantage of, it very well can pay for itself.

If you would like to view more Headless CMS options, including open source and self-hosted solutions, headlessCMS.org is a great resource.

As you can see, headless content management systems have come a long way and established themselves well in the CMS world. Consider leveraging one of them to empower the content owners in your organization and reduce load on your development team for content updates. If you find yourself needing a hand on getting started with your mobile app or React application project or are considering a Headless CMS, feel free to reach out. We’d love to talk.