Just last week we released a new feature called “Go Live” — a co-browsing addition to session playback that lets you ride along with your customer’s activity in real time. And while everyone here is rather excited about what it portends for our customers (and us, as we’re avid FullStory users of course), I was particularly energized by the process by which it was created.
What follows is a quick peek-behind-the-curtain into how a little (big) feature named Go Live came to be.
It all starts with the “Feature Brief.”
A Feature Brief is a piece of internal documentation we produce early in the life of a new feature. We began doing these a few cycles ago at FullStory to help direct the design and development process. It has a few distinct purposes:
- The feature brief brings internal (nay, cross-theme) clarity to the ideal, ship-ready state of a proposed new feature, and…
- The nature of a feature brief forces us to collaborate (across Marketing, Engineering, Design, Hugging, etc.) from the start of a new project.
I did some digging and found the the brief that became what we know today as “Go Live.” Intentionally short and sweet, here’s what we said…
Go Live with FullStory and view your online customers’ sessions in real time.
Most exciting flow:
Sam Support Agent receives an incoming chat from a customer, John, who is struggling to save a project. Sam isn’t sure what’s going on so he clicks the link to John’s session in FullStory and clicks Go Live to view what’s happening for John in real time. Sam immediately sees that a notification is obscuring the save button. He is able to quickly assist John to dismiss the notification and save his project. Then, Sam makes a note on the session and shares it with his product team so they can fix the design of the notification.
Benefit to customers:
Significantly lower cost per support ticket
Improved customer satisfaction
In summary, unless we start at the end — as feature briefs force us to do — finding the intrinsic nature of a new thing is a ridiculously cumbersome task. For us, feature briefs clarify essence.
Feature briefs tell the story.
Design, engineering exploration happens concurrently.
As both I and fellow FullStorian Stephanie Brubaker have discussed (at length), we’ve iterated our way to a product development process where both design and engineering work hand-in-hand from when nothing exists, to when something does. And this project was no different. With Joel leading the engineering effort, I was to ensure what we shipped to customers was truly useful, coherent, and delightful.
Joel quickly hacked out a promising proof-of-concept. The prototype, built atop our production environment, helped surface many of the edge cases that would need thoughtful design consideration. A huge benefit of working with engineering early on is that they can help surface all the edge cases and constraints (and boy, do I mean all of them). 🙂
Quick aside to designers: No, seriously, you want edge cases. Don’t run from them. Nor fear them. Embrace them, discover the new opportunities they bring, and bend the will of your product around them. This is the fun part of what we do!
One such issue that comes up in live sessions is that the person using FullStory needs some way to know whether or not the session is really live. There are several possible states:
- Open and active: The page is open and focused, and the user is actively doing things.
- Open and inactive: The page is open and focused, but the user isn’t interacting with it.
- Open and unfocused: The page is open, but the user is on another tab or application.
- Open and sleeping: The page is open, but the machine is hibernating.
- Maybe closed: The page may have been closed, but we don’t have proof.
- Closed: The page has definitely been closed.
That’s a lot of states. And left to my own devices, I wouldn’t have seen half of them coming. But by understanding each of these scenarios early enough (thanks to Joel’s very large brain and excellent prototype), design priorities were brought into focus.
Early artifacts of the design process.
Given the various user/browser scenarios Joel outlined, I felt that a prototype (sooner vs. later in the process) would be useful in sussing out the transitions between each state. I quickly mocked up a few basic interactions using Principle (my prototyping tool of choice), recorded a quick explainer video, and shared it amongst the team via Slack.
While the prototype I mocked up didn’t account for each of the potential states, it did help provide a compelling vision for the the most common interactions. Then, through a series of rapid-fire desk meetings, Joel and I worked out what scenarios made most sense to account for in the final design.
Getting feedback, tweaking.
We’re big fans of developing with feature flags — integrating new code into the product as early as possible but hiding it behind an on/off toggle. Practically speaking, feature flags let us turn on in-development features for a small subset of customers with the flip of a switch, enabling early testing and feedback. We’ll typically do this as we inch ever closer to shipping and, of course, use the feature internally to make sure it meets our standards.
Thankfully, the customer feedback for Go Live was resoundingly positive. After a while, when you’re too close to a project, it’s easy to forget the impact it’ll have on real people. Getting feedback like “OMG this is awesome!” “amazing,” “this is magic,” and “my customer support team already used this feature instead of regular screen-share and is totally excited,” serves as just the right kind of motivation to get a feature across the finish line.
Of course, we did address a few pieces of feedback. Three quick examples:
- Launching Go Live from a segment or list of search results wasn’t very smooth. Prior to its release, most sessions took a few minutes to show up after they started recording, which severely dampened Go Live’s impact. This forced us to conquer a long-standing desire we had to index new sessions instantly. We now show these “zero-indexed” sessions with a timestamp of “Live” in the user list. All in, this problem required a much deeper engineering effort than the client UI change.
There was robust internal debate about whether, when you click a session from the user list, FullStory should jump directly to the Live moment or retain the old, familiar behavior of starting at the beginning of the session. In the end, the existing behavior won out (mostly because of some nuanced integration-related use cases). But, the “Live” label (as noted in the first example) might allow us to get the best of both worlds in a future iteration, potentially serving as a click target of its own.
This last one’s a little thing, but profoundly meaningful to us. As we see it, the FullStory playback UI in particular needs a high pixel-to-value ratio, meaning we want our customer’s product to be the focus. When the FullStory UI starts to encroach on the playback window, we’re simply not being respectful. Our UI should not be the emphasis. That said, the design of Go Live did demand a new plot of real-estate in the playback window. And, as a result, there were scenarios where it’d directly obscure the bottom-right corner of customer UI. Not wanting to hide the control entirely behind a hover action, we designed it such that the control goes “hollow” when hovering it. This treatment on the control, an un-clickable element (when watching real-time), felt appropriate.
Once design and engineering had signed off on the feedback-related changes, we flagged Go Live on for all of our customers. So far, so good! The response has been overwhelmingly positive, and over a thousand customers have already gone live. (We can tell, of course, using FullStory.)
As with every new feature we build, there’s much left in the editing room and we can’t wait to keep building and improving on Go Live. So that seems like enough introspection for one blog post. It’s time to get back to it.