Using User Flows for Support

Product feature maps as help documentation

(Sample user flow)


There are a billion tech articles about designing and prototyping apps with wireframes and user flows. This isn’t one of them. I’m not a designer — I work in Support . But you could say I’m a Support Utopian

And as a Support Utopian, I’m always dreaming of a better way.

So, if the guiding light of app development is the Build → Measure → Learn cycle…

Support is basically anything that’s not Build.

Map & Territory

There’s a fundamental problem in Support that I’ve yet to see anyone coherently solve: the map is not the territory. When you make an FAQ, a support bot, helpdesk macros or a full-on Help Center, you’re making a representation of the product which in most cases is woefully separate from the product-itself. Changes made in the Build part of the dev cycle do not automatically propagate to Support documentation.

Apart from making completely self-documenting code and product (which some Support Unbelievers say is not currently possible), I wonder if integrating things like wireframes and user flows into Support products (eg, help desks/ticketing/documentation systems) might be a way to bridge the gap between what is now and what could be…

All the big help desk software systems that I’ve encountered seem have two basic components. A ticketing area (only available to agents):

Ticketing in Zendesk

And an area for managing the help center documentation, which plus or minus management features is basically the same for agents and users:

Feature mapping

Despite minor differences among platforms, all the major ticketing/help desk companies are organized along basically these same lines. Obviously, these products work the way they are. But I’m increasingly finding a gap — or is it an opportunity — in functionality which I’d love to see someone tackle: feature mapping.

When I say Feature Maps, I’m talking about something distinctly different from Product Roadmaps. I understand those to be more like strategic overviews related to product direction and prioritization set against a timeline — which may be public or internal-only.

Feature Maps are even more elemental. They would be a graphic depiction of all the features available in the product and how they link together. Something along the lines of this (borrowed from a blog post about test case maps):

The same information could also be expressed as a nested list:

Partial recreation of the above diagram/mind map as a list

In my theoretical Support Utopian software system, you’d be able to switch between views and hop between related nodes via a diagrammatic mind-map or a nested list of all the features in the product.

A list like the above is quick and easy to set up. It’s a lightweight flexible representation of the product (any product for which support is required) as a skeleton on which support agents can hang documentation and tickets on... like a… Support Christmas Tree.

The ornaments are supposed to represent tickets and documentation… in case that’s non-obvious.

Clicking in to any branch in your feature map would enable the agent to accomplish two main objectives:

  1. View and edit linked documentation (help center articles, FAQs, bot responses, macros)
  2. View and analyze tickets associated with that cluster of features in the product. (ie, Measure → Learn)

So in the above browser example, in one fell swoop I could see that I have 36 tickets or bot questions input over the past two months by users related to product feature: Browser > History > Clear history. I could also see right alongside that what my existing macros are which relate to this , any bot responses I’ve written and what my Help Center article(s) say (eg, pre-built answers).

Single Source of Truth

In other words, I could compare directly what my documents say to what people are asking and make any necessary changes on my end all in the same screen to harmonize user intents with existing features.

Ideally, I’d also be able to mark or flag updates I make so that I can then come back two months later and see if I’m still getting the same questions or if my last update has calmed the ticket storm before it was able to manifest…

At the same time, I’d be able to quickly output a report for product management which summarizes all user feedback and feature requests linked to this branch of my feature map. If recent documentation updates are not enough to solve certain high-priority problems for users, the product build team would have actionable data collected from real users and their insights.

Tracking Action Paths

As I wrote in my original Support Utopia manifesto, the ideal situation would be something like:

Tickets, feedback and feature requests could be opened from anywhere, and the activity path which lead to creating a ticket would be appended to a transcript for analysis… leading to more accurate, element-specific measurements of bugs (including steps to repro, plus ability to accurately measure against documented purpose/expected behavior of elements) and enabling granularity of feature requests linked to specific elements/activities (ie, user intents lacking apparent paths to actualization).

What that means in simpler terms is that the Feature Map underlying the core Support system would be directly tied to UI elements of the product. Users could access help natively in-product. No more separation between help center and product. UI elements could send usage signals back to support.

At a higher level, not only would we be able to look at a Support-Feature-Map-Xmas-Tree and see the pretty decorations of data from tickets, bots, macros and help documents, we’d also be able to marry that to real data of how people are using the product.

Whether this were to take the form of session recording data, like offers (cc: FullStory) or something else, Support agents would have access both to general trends in user flows through the product (which ought to correlate to ticket trends). And they could access records of specific users’ action paths from Point A → Point B → C (ie, “proof” for troubleshooting), which would enable them to more quickly diagnose and correct problems, or triage issues for engineering or other teams to handle.


First, re-organizing how Support software works and second, looping well-ordered Support data to product usage data would, IMO, be a kind of quantum leap forward to:

1. Tighten and strengthen the Build → Measure → Learn cycle with richer, more shaped and actionable feedback;
2. Move Support out of the shadows to become a dancing partner 💃🏽 to Product;
3. And actualize Support Utopia in our lifetimes.

“Hey — I’m allowed to dream, aren’t I?”™