The background:

We’ve all made mistakes. We’re human, after all. (This is me reminding you, dear reader, after I inevitably make a mistake the minute this post is live!) If you’re like me, you want to prevent as many hiccups as possible. And the only way to do that is by forming habits. Good habits. Habits that involve checking things off of lists and copy-pasting. Getting excited yet?

There’s no silver bullet to perfect flows, but you can give yourself some peace of mind with careful categorization, checklists, and a few handy diagnostic features in Appcues. Here’s how we do it.

Plan of action:

If you haven’t read our guide on documenting flows‚—definitely give that a quick read through. The table I reference in that is a part of our QA process. 

Even though the places the information lives (Notion, Google Sheets, Confluence) are different, the same basic formula applies. Before every flow goes live, you can start with a few quick questions:

• Is audience targeting correct? 
• Are flows showing on the right pages?
• Does the flow break in any way?
  

Over the years, I’ve added to my QA and documentation process, and it’s become quite long. Especially here at Appcues, where I really don’t want to look like a fool in front of people looking to us for inspiration. Depending on the complexity of your product and flows, this could be a 5–10 minute solo process before you publish or something a bit more involved across teams.

I am mostly a team of 1 in terms of reviewing and responsibility over publishing flows. My team supports me, but ultimately publishing and QAing flows is my zone. This has been the case for me as a long-time Appcues user, not just here at Appcues. You may work with other folks who have to review flows before they go out, but the bones of this process should be more or less the same! Ok, off we go!

How we built it:

Before I publish any flow, I get 4 tabs ready:

• Flow QA checklist (more on this in a sec)
• All Flows table
• Settings page for the flow
• The page where the flow will launch 
  

I start testing with a run-through of the actual flow. I do this because I prefer to catch issues or make changes to flow content before I review the targeting. Changes to the flow could potentially change the audience or any other settings. I eventually use test mode, but first I publish to myself and set it to “show every time”. 

I like to run flows through different scenarios multiple times, and it’s tedious for me to reload the link over and over. This is just how I do it—we have a detailed help doc that outlines all the possible ways to test flows. To be honest, Appcues is pretty easy to use, so I don’t make complex tours that require detailed QA from a technical standpoint. Some of the more comprehensive methods, like publishing to a staging environment, don’t make sense for us (yet). 

I target flows to myself and publish live to see how they work in the wild.

If I’m happy with the flow after I run through it live, then I start walking through my QA checklist. This is a super basic table in Notion, but you can use anything. Even… paper? I guess? 

I use a Notion table to walk through each aspect of the flow I want to QA.

I tab back and forth as I go through each item on the checklist and check it against our vision and best practices for this flow. Here are the checks I use:

• Segments (checking that a segment or audience filters are used)
• Page targeting (confirm the pages the flow is set to show on)
• Triggers (this determines how and how often the flow will show)
• Element targeting (mostly for hotspots or tooltips, I use this to triple check I am using the correct elements)
• Block list (for those who have requested not to receive any messages or opted out of specific messages)
  

Last but not least, I fill out my card in my “All Flows” table in Notion (as a reminder, this is covered in another piece where I talk about our flow documentation). 

I replicate a lot of info here in our documentation as a final check.

This card also includes the test link, so anyone from our org can go ahead and check out the flow. If I need someone else to review the flow for copy or other reasons, I always send along that test link. I’ll sometimes publish to a test account as well, depending on the complexity of the flow. 

Reviewing copy is a whole different process, one I haven’t dug into here yet. Are you curious how I review copy? Do you have your own unique process you want to share? Send me a note at lyla@appcues.com or reach out to me on LinkedIn.