Appcues for Mobile

Appcues for Mobile

Appcues Design System

Appcues for Mobile

For years, customers had asked when we would release a product for mobile apps instead of just web, and the time had finally come. A larger team in 2018 meant we had the resources to tackle this huge undertaking. Designing for a new platform's unique technical and UX challenges was expectedly grueling, but the payoff of finally delivering a product customers had been dying for felt great.

For years, customers had asked when we would release a product for mobile apps instead of just web, and the time had finally come. A larger team in 2018 meant we had the resources to tackle this huge undertaking. Designing for mobile's unique technical and UX challenges was grueling. But the payoff of finally delivered a product customers had been dying for felt great.

For years, customers had asked when we would release a product for mobile apps instead of just web, and the time had finally come. A larger team in 2018 meant we had the resources to tackle this huge undertaking. Designing for mobile's unique technical and UX challenges was grueling. But the payoff of finally delivered a product customers had been dying for felt great.

My goal was to lead the design of Appcues' new mobile product, from conception to release. Kicking off with a design sprint, I helped the team refine our MVP and polish features for general release.

May 2018 - present

My goal was to lead the design of Appcues' new mobile product, from conception to release. Kicking off with a design sprint, I helped the team refine our MVP and polish features for general release.

May 2018 - present
My goal was to lead the design of Appcues' new mobile product, from conception to release. Kicking off with a design sprint, I helped the team refine our MVP and polish features for general release.
May 2018 - present
mobile thumbnail

ABOUT THE ORG

Appcues is an experience layer for your product that enables you to build customizable, targeted, and measurable onboarding, feature adoption, and surveying experiences, to better engage your users and grow your business. In more concrete terms, it means you can insert modals, tooltips, checklists and Net Promoter Surveys (NPS) into your app, code-free.

Problem

Problem

Appcues users could succesfully build content for their web apps... but we knew we needed to support native mobile apps. Why? We all know how addicted we are to our phones and the plethora of apps for them, but if you need stats, according to a report by comScore, of the total time spent on devices, users spend twice as much on mobile as they do on desktop. Customers had been asking for a mobile product for years, and we kept losing more deals because we didn't have one. Developing mobile was a no brainer, but it was a big undertaking that needed a dedicated team and a proper strategy.

GOAL

Provide a focus and solid design foundation
for the mobile team's MVP.

Provide a focus and solid design foundation for the mobile team's MVP.

Solution

Solution

Design sprint
Leverage a design sprint to define and validate an MVP. You're probably already familiar with the basics of Jake Knapp's design sprint, but as a quick refresher: It's an effective, scripted process helping teams define, storyboard, and validate a working hypothesis that's grounded in research—all within five days. It is useful when: the cost of failure is high, there is significant complexity involving multiple departments, or there is limited knowledge about feasible solutions and the competitive space.

Challenges

Challenges

Developing a standalone product for a new platform
In order to be successful, mobile needed to be a standalone product that worked end-to-end. Other teams had delivered features that built off the core web product and those features could withstand an occasional UX hiccup here or there. But everything about mobile, from installation through building and publishing content, had to work.

A completely new team
Most of the mobile team members were recent Appcues hires, not having any established rapport with each other, nor a deep history with the main web product.

Loss of resources
Shortly after our beta release, our lead front-end developer on the team moved to another company, and we lost several other employees across departments. The mini-exodus strained morale and had us scrambling to pull devs off other teams while we hired more. Additionally, I had to straddle two other main projects after losing fellow designers.

Late-stage technical realizations
During our beta release, about six months after the sprint, we realized we had tried to do too much technical magic for the user in how mobile screens were being saved on the web. Users weren't able to reliably release content in their apps because of it. We would need to rework how we handled screens on the backend as well as introduce UX into the product to have users save their mobile screens in a new way. This pushed us back from our original release target.

DAY 1

Kicking off the design sprint

Kicking off the design sprint

Kicking off the design sprint

Our core team of a product lead, iOS developer, designer (myself) and head of product carved out time and space dedicated to kicking off the sprint. We invited members of support, design, marketing, sales and engineering throughout to leave feedback and soak up good vibes.

Our core team of a product lead, iOS developer, designer (myself) and head of product carved out time and space dedicated to kicking off the sprint. We invited members of support, design, marketing, sales and engineering throughout to leave feedback and soak up good vibes.

design sprint photo

Defining our goal

Defining our goal

Defining our goal

We kicked off by defining our sprint goal, our cornerstone for staying aligned and on track throughout the week.

We focused on user adoption as our targeted use case since earlier contextual research with prospects indicated that basic onboarding for their apps (and not surveying, for example) was what they needed most. In the end, this would translate to us offering simple modals and tooltips to customers as our first patterns for mobile.

We kicked off by defining our sprint goal, our cornerstone for staying aligned and on track throughout the week.

We focused on user adoption as our targeted use case since earlier contextual research with prospects indicated that basic onboarding for their apps (and not surveying, for example) was what they needed most. In the end, this would translate to us offering simple modals and tooltips to customers as our first patterns for mobile.

We kicked off by defining our sprint goal, our cornerstone for staying aligned and on track throughout the week.

We focused on user adoption as our targeted use case since earlier contextual research with prospects indicated that basic onboarding for their apps (and not surveying, for example) was what they needed most. In the end, this would translate to us offering simple modals and tooltips to customers as our first patterns for mobile.


sprint goal
PM building flows

Selecting our target persona
and journey point

Selecting our target persona
and journey point

Next up was to select a particular target persona and point in their experience of the product. Trying to design for everyone and for all tasks would be too daunting—we needed to zero in. Our targets were:

Product manager
PMs would be frequent builders of content on mobile and also heavily involved in evaluating and retaining the product.

Building content
How a PM would create content for their app stood out as unique to mobile, with the most unknowns to solve for on the UX and tech side. Would users need to build everything on the device itself, or would we somehow link their app with our web builder? Either option was ripe with challenges and needed a solution.

Next up was to select a particular target persona and point in their experience of the product. Trying to design for everyone and for all tasks would be too daunting—we needed to zero in. Our targets were:

Product manager
PMs would be frequent builders of content on mobile and also heavily involved in evaluating and retaining the product.

Building content
How a PM would create content for their app stood out as unique to mobile, with the most unknowns to solve for on the UX and tech side. Would users need to build everything on the device itself, or would we somehow link their app with our web builder? Either option was ripe with challenges and needed a solution.

Next up was to select a particular target persona and point in their experience of the product. Trying to design for everyone and for all tasks would be too daunting—we needed to zero in. Our targets were:

Product manager
PMs would be frequent builders of content on mobile and also heavily involved in evaluating and retaining the product.

Building content
How a PM would create content for their app stood out as unique to mobile, with the most unknowns to solve for on the UX and tech side. Would users need to build everything on the device itself, or would we somehow link their app with our web builder? Either option was ripe with challenges and needed a solution.

Next up was to select a particular target persona and point in their experience of the product. Trying to design for everyone and for all tasks would be too daunting—we needed to zero in. Our targets were:

Product manager
PMs would be frequent builders of content on mobile and also heavily involved in evaluating and retaining the product.

Building content
How a PM would create content for their app stood out as unique to mobile, with the most unknowns to solve for on the UX and tech side. Would users need to build everything on the device itself, or would we somehow link their app with our web builder? Either option was ripe with challenges and needed a solution.

Next up was to select a particular target persona and point in their experience of the product. Trying to design for everyone and for all tasks would be too daunting—we needed to zero in. Our targets were:

Product manager
PMs would be frequent builders of content on mobile and also heavily involved in evaluating and retaining the product.

Building content
How a PM would create content for their app stood out as unique to mobile, with the most unknowns to solve for on the UX and tech side. Would users need to build everything on the device itself, or would we somehow link their app with our web builder? Either option was ripe with challenges and needed a solution.

DAY 2

DAY 2

Exploring solutions

Exploring solutions

Exploring solutions

Exploring solutions

From day 1's efforts, we had our focus—helping PMs build mobile adoption experiences. But, the big question in the room was, how and where would users build content?

From day 1's efforts, we had our focus—helping PMs build mobile adoption experiences. But, the big question in the room was, how and where would users build content?

From day 1's efforts, we had our focus—helping PMs build mobile adoption experiences. But, the big question in the room was, how and where would users build content?

Building on web was preferred

Building on web was preferred

Building on web was preferred

Again, prior contextual research came in handy—customers and prospects had already expressed a strong preference for building content on web. It was simply easier to access from anywhere. If building occurred solely on the device, users would always need one on hand if they wanted to work, and that was simply too much friction given that:

  • not all organizations have test devices with which to build content, so users would need to use their personal device for work tasks, something not all would want to do
  • for the orgs that do have test devices, those devices are shared between teammates who would have to vie for access to do their job

Instead, having content building occur in our web app would mean more users could create or edit content from anywhere, anytime.

Note: Having the building experience take place on the web meant that we would need some way for users to either send screens from their app to the web, or emulate the app. And it also meant that whatever was built on the web would have to be rendered faithfully on the device. These two tradeoffs of our solution, particularly the sending of screen data to the web, would prove to be the tougher challenges of the product, ones we worked steadily through in the solid year+ of development after the sprint.

Again, prior contextual research came in handy—customers and prospects had already expressed a strong preference for building content on web. It was simply easier to access from anywhere. If building occurred solely on the device, users would always need one on hand if they wanted to work, and that was simply too much friction given that:

  • not all organizations have test devices with which to build content, so users would need to use their personal device for work tasks, something not all would want to do
  • for the orgs that do have test devices, those devices are shared between teammates who would have to vie for access to do their job

Instead, having content building occur in our web app would mean more users could create or edit content from anywhere, anytime.

Note: Having the building experience take place on the web meant that we would need some way for users to either send screens from their app to the web, or emulate the app. And it also meant that whatever was built on the web would have to be rendered faithfully on the device. These two tradeoffs of our solution, particularly the sending of screen data to the web, would prove to be the tougher challenges of the product, ones we worked steadily through in the solid year+ of development after the sprint.

Again, prior contextual research came in handy—customers and prospects had already expressed a strong preference for building content on web. It was simply easier to access from anywhere. If building occurred solely on the device, users would always need one on hand if they wanted to work, and that was simply too much friction given that:

  • not all organizations have test devices with which to build content, so users would need to use their personal device for work tasks, something not all would want to do
  • for the orgs that do have test devices, those devices are shared between teammates who would have to vie for access to do their job

Instead, having content building occur in our web app would mean more users could create or edit content from anywhere, anytime.

Note: Having the building experience take place on the web meant that we would need some way for users to either send screens from their app to the web, or emulate the app. And it also meant that whatever was built on the web would have to be rendered faithfully on the device. These two tradeoffs of our solution, particularly the sending of screen data to the web, would prove to be the tougher challenges of the product, ones we worked steadily through in the solid year+ of development after the sprint.


How would we represent mobile screens on web?

How would we represent mobile screens on web?

How would we represent mobile screens on web?

We looked at companies who handled content creation for mobile apps on the web—Elasticode, Walkme, Apptimize, Appetize, and Pendo. Most used app emulators, but Walkme featured a button users could just tap to send a screen from their mobile to the web. Ultimately, we chose to send screens from the device to the web, since the ease of use provided access to the widest pool of users.

We looked at companies who handled content creation for mobile apps on the web—Elasticode, Walkme, Apptimize, Appetize, and Pendo. Most used app emulators, but Walkme featured a button users could just tap on to send a screen from their mobile to the web. Ultimately, we chose to send screens to the web, since it provided access to the widest pool of users.

We looked at companies who handled content creation for mobile apps on the web—Elasticode, Walkme, Apptimize, Appetize, and Pendo. Most used app emulators, but Walkme featured a button users could just tap on to send a screen from their mobile to the web. Ultimately, we chose to send screens to the web, since it provided access to the widest pool of users.

App emulation

APP EMULATORS

APP EMULATORS

Pro—easier to leverage in our product

Con—most of our users are non-technical, with limited desire and ability to use emulators

Pro—easier to leverage in our product


Con—most of our users are non-technical, with limited desire and ability to use emulators

Pro—easier to leverage in our product


Con—most of our users are non-technical, with limited desire and ability to use emulators

send screen

SENDING SCREENS

Pro—anyone could send a screen to the web, using a pre-installed Appcues button

Con—screens would need to be stored in our system and referenced in a user's dashboard

Sketching the building workflow

Sketching the building workflow

Sketching the building workflow

The fun part...sketching! The team, non-designers included, broke out the markers to visualize their ideas for various aspects of building, all the way from picking a screen on their device through publishing its finished content.

The fun part...sketching! The team, non-designers included, broke out the markers to visualize their ideas for various aspects of building, all the way from picking a screen on their device through publishing its finished content.

The fun part...sketching! The team, non-designers included, broke out the markers to visualize their ideas for various aspects of building, all the way from picking a screen on their device through publishing its finished content.

design sprint sketches

After independent sketching, we assembled to discuss our ideas with the group, voting on the coolest and most impactful.

Top-voted sketches

  • App map—a way to automatically build a map of screens from an app, enabling users to easily visualize where to build content.
  • Styling made simple—our web builder's style settings were more numerous, but hard to make sense of. We wanted to pare down the settings offered and make them immediately recognizable and easy to toggle on and off.
  • Wizard builder—building on mobile required some tricky setup—first pairing devices and then sending screens. To walk users through, we played with using a progressive set of steps in a wizard.

DAY 3

Storyboarding our mobile MVP

Storyboarding our mobile MVP

Storyboarding our mobile MVP

Storyboarding our mobile MVP

Phew! By Day 3 in a sprint, you already feel exhausted. But you've got to keep the momentum going. Storyboarding is where you pretend to be movie directors stitch your sketches together into a cohesive workflow, uncovering and solving for any unaccounted glitches, and then move on to prototyping.

Phew! By Day 3 in a sprint, you already feel exhausted. But you've got to keep the momentum going. Storyboarding is where you pretend to be movie directors stitch your sketches together into a cohesive workflow, uncovering and solving for any unaccounted glitches, and then move on to prototyping.

storyboard for mobile
Diagramming our storyboard

DAY 4

From storyboard to prototype

From storyboard to prototype

From storyboard to prototype

From storyboard to prototype

Once we had our storyboard agreed upon, we began prototyping and scriptwriting. This part of the sprint falls mostly on the designer's shoulders (me, in this case), so the rest of the sprinters scurried back to their desks for a bit of a breather.

We had a whole new product experience to design, a daunting task, but also freeing in the sense that we could break some old design artifacts. The result was a prototype of an MVP that felt fresh and exciting, and incorporated many of our best sketches.

prototype, app map
An early screen of the App Map, where users browsed their app's screens
prototype, builder
An early screen of the Builder, where users create content.

DAY 5

Validating with users

Validating with users

Validating with users

Thankfully, recruiting for this test had been a breeze—we already had 8 participants, some current customers and some prospects—who were dying to get a first peek at mobile.

Key questions

  • Did the App Map—the display of screens—bring any value?
  • Was setup—pairing devices and sending screens—too confusing or intensive?
  • Was this building experience simpler and more preferable to the web's?
  • Would users buy this product? Why or why not?

Test findings

  • The App Map was really nifty, something valuable in and of itself, as most PMs lamented that nowhere on their own teams did they have a comprehensive map of their product. They immediately pictured how we could overlay all sorts of performance data and alerts for content. However, most users were understandably skeptical about how the map could be auto-generated. We would quickly abandon it as an MVP feature, though still dream of making it a reality someday.
  • Setup was a little long but intuitive, with the wizard approach greatly helping users feel guided throughout it all. There were comments on length—besides pairing devices and sending screens, there were steps for selecting content templates as well. During development, we would consolidate much of the setup to get users building quicker.
  • The look of the Builder and styling flexibility was preferred to our web product, with users calling it more intuitive, modern, clean and friendly. Most users inquired about whether saving style settings for their content, a web feature, would also be available, but confirmed they did not need it for MVP.
  • And finally, with some saying "probably", most users said yes, they would definitely buy this mobile product

Thankfully, recruiting for this test had been a breeze—we already had 8 participants, some current customers and some prospects—who were dying to get a first peek at mobile.

Key questions

  • Did the App Map—the display of screens—bring any value?
  • Was setup—pairing devices and sending screens—too confusing or intensive?
  • Was this building experience simpler and more preferable to the web's?
  • Would users buy this product? Why or why not?

Test findings

  • The App Map was really nifty, something valuable in and of itself, as most PMs lamented that nowhere on their own teams did they have a comprehensive map of their product. They immediately pictured how we could overlay all sorts of performance data and alerts for content. However, most users were understandably skeptical about how the map could be auto-generated. We would quickly abandon it as an MVP feature, though still dream of making it a reality someday.
  • Setup was a little long but intuitive, with the wizard approach greatly helping users feel guided throughout it all. There were comments on length—besides pairing devices and sending screens, there were steps for selecting content templates as well. During development, we would consolidate much of the setup to get users building quicker.
  • The look of the Builder and styling flexibility was preferred to our web product, with users calling it more intuitive, modern, clean and friendly. Most users inquired about whether saving style settings for their content, a web feature, would also be available, but confirmed they did not need it for MVP.
  • And finally, with some saying "probably", most users said yes, they would definitely buy this mobile product

Post-sprint to release

Post-sprint to release

Post-sprint to release

Post-sprint to release

Ok, so design sprints are great and all, but there's a lot that happens after them.

builder
What the Builder evolved to for our general release

Besides some trivial updates to the visual design and UX, in the 1+ years of development post-sprint, we encountered a number of development and UX challenges, some of which I mentioned earlier.

Saving screens wasn't as straightforward as we hoped

Saving screens wasn't as straightforward as we hoped

Saving screens wasn't as straightforward as we hoped

Our solution had users tap a pre-installed Appcues button on their mobile app to send a given screen to the web. The screen would appear, users would craft a tooltip or two, then publish them, hoping those tooltips would only appear where intended.

During our beta release, about six months after the sprint, we realized it was possible for content to show up on unintended screens, and for it to stop showing on the intended screen when the app's version updated, even slightly.

The root of the problem was in how screens were being identified and saved in our system. Before any building could take place, developers needed to install Appcues, during which they would tag all the screens and elements they thought their team would need for building content. Content wouldn't appear accurately without knowing which tagged places it should appear with. However, the tagging process was intensive for developers and error-prone—they may not tag everything, or tag the wrong things, not knowing what was important later on for users who wanted to build content. If a builder later decided they needed something not already tagged, they needed to go back to their developer. This was simply too much friction and had resulted in users abandoning building.

Our solution had users tap a pre-installed Appcues button on their mobile app to send a given screen to the web. The screen would appear, users would craft a tooltip or two, then publish them, hoping those tooltips would only appear where intended.

During our beta release, about six months after the sprint, we realized it was possible for content to show up on unintended screens, and for it to stop showing on the intended screen when the app's version updated, even slightly.

The root of the problem was in how screens were being identified and saved in our system. Before any building could take place, developers needed to install Appcues, during which they would tag all the screens and elements they thought their team would need for building content. Content wouldn't appear accurately without knowing which tagged places it should appear with. However, the tagging process was intensive for developers and error-prone—they may not tag everything, or tag the wrong things, not knowing what was important later on for users who wanted to build content. If a builder later decided they needed something not already tagged, they needed to go back to their developer. This was simply too much friction and users had stopped building content.

Our solution had users tap a pre-installed Appcues button on their mobile app to send a given screen to the web. The screen would appear, users would craft a tooltip or two, then publish them, hoping those tooltips would only appear where intended.

During our beta release, about six months after the sprint, we realized it was possible for content to show up on unintended screens, and for it to stop showing on the intended screen when the app's version updated, even slightly.

The root of the problem was in how screens were being identified and saved in our system. Before any building could take place, developers needed to install Appcues, during which they would tag all the screens and elements they thought their team would need for building content. Content wouldn't appear accurately without knowing which tagged places it should appear with. However, the tagging process was intensive for developers and error-prone—they may not tag everything, or tag the wrong things, not knowing what was important later on for users who wanted to build content. If a builder later decided they needed something not already tagged, they needed to go back to their developer. This was simply too much friction and users had stopped building content.


Screens would now need to be saved by the user

Screens would now need to be saved by the user

We modeled our solution for this on a competitor's approach, Pendo. After screens were sent to the web, the user would tag the screen with important, identifying elements, right there, instead of relying on a developer.

We modeled our solution for this on a competitor's approach, Pendo. After screens were sent to the web, the user would tag the screen right there, instead of relying on a developer.

screen id’ing
Our solution allows users to flexibly define the elements that make up a mobile app Screen and save it to their dashboard.

Users would select the elements that made the screen unique from others and then save that screen in their dashboard. The challenge to this is getting non-technical users to understand why and how to tag screens effectively, something that we will improve over time. The benefit to this approach outweighed the risk of confusion, though, as users were now able to flexibly build content on screens without relying on developers.

Users would select the elements that made the screen unique from others and then save that screen in their dashboard. The challenge to this is getting non-technical users to understand why and how to tag screens effectively, something that we will improve over time. The benefit to this approach outweighed the risk of confusion, though, as users were now able to flexibly build content on screens without relying on developers.

Users would select the elements that made the screen unique from others and then save that screen in their dashboard. The challenge to this is getting non-technical users to understand why and how to tag screens effectively, something that we will improve over time. The benefit to this approach outweighed the risk of confusion, though, as users were now able to flexibly build content on screens without relying on developers.

Final thoughts

😅 🎉

Final thoughts

😅 🎉

Final thoughts

😅 🎉

While the mobile project wasn't perfect and our release date was pushed back, the sprint was still a success in kickstarting a major project for Appcues and delivering a mostly successful MVP. A deeper analysis on the technical side would have been beneficial upfront so that we didn't run into the screen identifying issue later on. Limited resources and a new team contributed to our late realizations on the technical side.

We can now proudly look forward, though, to releasing Appcues for mobile in early 2020!

While the mobile project wasn't perfect and our release date was pushed back, the sprint was still a success in kickstarting a major project for Appcues and delivering a mostly successful MVP. A deeper analysis on the technical side would have been beneficial upfront so that we didn't run into the screen identifying issue later on. Limited resources and a new team contributed to our late realizations on the technical side.

We can now proudly look forward, though, to releasing Appcues for mobile in early 2020!

While the mobile project wasn't perfect and our release date was pushed back, the sprint was still a success in kickstarting a major project for Appcues and delivering a mostly successful MVP. A deeper analysis on the technical side would have been beneficial upfront so that we didn't run into the screen identifying issue later on. Limited resources and a new team contributed to our late realizations on the technical side.


We can now proudly look forward, though, to releasing Appcues for mobile in early 2020!