The final season of the fantasy TV series Game of Thrones, which aired recently, was panned for its tonal shift from prior seasons. The audience blamed the show writers for pacing and action that seemed contrary to the character arcs developed in George RR Martin’s books. There were many arguments and discussions about what the true cause was, but one particular critique from a Twitter user caught my eye. The author describes how differences between “plotters” and “pantsers,” two writer archetypes, could have been at the heart of the issue. And I realized it reflects how differences in our approaches to designing user onboarding can affect the user experience.
It has to do with the behind-the-scenes process of plotters vs. pantsers. If you’re not familiar with the distinction, plotters create a fairly detailed outline before they commit a single word to the page. /2— Daniel Silvermint (@DSilvermint) May 7, 2019
Pantsers discover the story as they write it, often treating the first draft like one big elaborate outline. Neither approach is ‘right’ – it’s just a way to characterize the writing process. But the two approaches do tend to have different advantages. /3— Daniel Silvermint (@DSilvermint) May 7, 2019
In short: plotters start by creating a detailed outline before writing a story, and pantsers, who “fly by the seats of their pants,” jump right into story building, unearthing main plot points as a byproduct of character development. Per this thread, the final seasons of Game of Thrones suffered because the showrunners, who were plotters, had to fit the looser character arcs from Martin, a pantser, into the fixed-timeline outcome of their show outline.
This thread stuck out because it parallels some of my observations about onboarding design. User onboarding is a process of guiding a new user on their journey from a product’s entry point to an endpoint of success, and can present challenges similar to that of writers trying to shephard characters through a plot. And there seems to be the plotter’s approach, and the pantser’s one.
The plotter’s approach
I’ve mostly experienced teams who take a plotter’s approach to onboarding design. They treat it like a narrative. An end goal is defined, like retention, satisfaction, or some variation of a north star metric, and then the designers lay out a sequence of steps they want new users to follow to reach that goal. The upside of plotted onboarding is that it’s goal-oriented. But experiences aren’t stories to be told, and this rigidity can cause problems.
The results of an overly-plotted onboarding experience are obvious when encountered: step-by-step tutorials, time-consuming setup wizards, or a series of hints and notifications that push you to take a series of actions. Teams who take the plotting approach are boggled when new users come in and don’t follow the path prescribed for them. Because people have so many different situations when they come to a new product or feature, and because they likely aren’t motivated by your long-term goal, they behave in a way that appears chaotic and short-sighted, but it’s just because the “plot” of the onboarding design didn’t account for the standard variety of human behavior.
This can result in two knee-jerk responses from the plotter team. They might double-down on the plotting, perhaps making a more rigid setup flow or getting heavy-handed with hints and pop-ups. Or, put off by the difficulty of aligning end-users to a long-term goal, they pull back to plotting users towards short-term goals they can more easily control, like signups.
A rigid plotter’s design can also suffer as a product ages, because it can rarely scale well if the product grows or changes focus.
The pantser’s approach
To a lesser extent, I’ve seen teams who take a pantser’s approach to onboarding design. In this approach, the team focuses on guiding users through individual actions and concepts as they’re encountered, shuffling them on to next-step actions when complete. The pantser team doesn’t have an opinionated stance about where a user should end up and instead embraces user-defined paths. The team that takes a pantser approach might not even think they’re designing onboarding, but instead that they’re designing general user education.
The pantser approach has benefits that offset the issues of the plotter’s approach. Such experiences can feel less forced, leading to a more welcoming first impression than a prescribed usage template. They’re also well-suited for product scalability because guidance is modularized instead of being a separate flow to be maintained.
But a fly-by-the-seat-of-your-pants approach can also have problems. Without a sense of direction, there’s no criteria for when guidance should and shouldn’t be applied. This can create guidance that is applied in an ad-hoc way, with inconsistencies from moment to moment, and potential collisions when multiple pieces of education happen at the same time. New users might feel lost if they aren’t greeted by an agent that helps them move forward. And, while letting people define their own paths is great, the product may lose users if they’re not being guided toward a long-term end goal.
Somewhere in between
Like most things in life and design, neither approach is wrong or right. “Plotter” and “pantser” describe two ends of a spectrum, and the best approach to user onboarding falls somewhere in between.
Teams shouldn’t treat user onboarding like a map, nor should they untether it completely from an end goal. I prefer to think that good onboarding behaves like a compass, a thing that takes users in different situations to a destination of success for them, and for our products.
I’ve blended a variety of plotting and pantser strategies into “Designing a user onboarding compass,” a workshop aimed at helping teams design better onboarding. The first exercise has them work backwards from successful end states to find common actions that can be on a new user’s path to success. This gives the team a high-level, plotter-like view of the different combination of key actions that onboarding can guide users through. Afterwards, the team takes individual key onboarding actions, scaffolds them with guidance in a modular fashion, and designs ways for the guidance of one action to link up to the triggers of possible next-step actions.
Successful onboarding teams might use a mix of plotter and pantser exercises, or they might designate some designers as plotters and others as pantsers. A product might start out with a panster approach, and skew more towards a plotter’s method as it becomes established. So, whether you’re a plotter, a pantser, or something in between, you have ample opportunity to design a great user onboarding experience, as long as you balance out the pros and cons of both approaches.