The art of the FTUE in VUX

At Rocket we have always put a lot of thought into the FTUE (First Time User Experience) for any of our mobile or web applications. However, until recently, this topic was often overlooked for our voice skills. The more we thought about this, the more we realized that getting the FTUE right in voice was as important, if not more important in voice. The reason for this lies in the famous saying, "a picture is worth a thousand words". When users come to an app, their brains quickly digest a lot of information, ascertaining its various capabilities. Additionally, they can easily begin to click around to discover more functionality. In comparison, users of Alexa skills, are restricted to distilling information exclusively through sound. This forces the VUX designer to strike a fine balance between providing enough information to guide the user, without frustrating or boring them. Enter the importance of the Voice FTUE.

A real life example

Imagine interacting with a simple trivia game on Alexa. The first time a user interacts with our game, our goal is to make sure they have enough information to know how to use the skill, as well as, delight them with a wonderful experience. This may manifest itself in a custom theme song, followed up with detailed information about how to play the game. All in all, lets say this takes a full minute. This is fantastic for that first experience, but quickly becomes tiresome and frustrating for a user to suffer through each time they open the skill. We realized the opportunity to improve the returning user's experience by having a different message that drops them immediately into game play- our first major improvement.

Our skills often leverage the technique of progressive disclosure. For this reason we find it is important to track this experience at the intent level, rather then the overall skill level. Continuing with our trivia game example, we not only want to have a different response for when the skill is opened but also for instructions throughout the game. For instance, if a user unlocks a "daily double", an initial explanation must be provided but in the future it is unnecessary to frustrate them with that information.

Techniques to implement this

In the web world we often use cookies or local storage to track returning users. With Alexa Skills we do not have this luxury, so we need to track it in a database. At Rocket our preferred storage mechanism is Redis, because it is fast, reliable and chock-full of helpful features. We use the Alexa-App library, which provides us with nice pre and post hooks. This allows us to decorate our request object with a new field of isReturningUser. Below is some example code showing how we set / retrieve this.

function _redisKey (req) {  
  const userId = _.get(req, 'context.System.user.userId')
  const requestType = _.get(req, 'request.type')
  return requestType === 'LaunchRequest' ? 'LaunchRequest' : `intent_${_.get('request.intent.name')}`
}

app.pre = (req, res) => {  
  // Any other setup you want here.

    return redisClient
      .get(_redisKey(req))
      .then(val => {
        res.locals = _.assign({}, res.locals, { returningUser: !!val })
        return
      }
    )
    .catch(console.warn)
}

app.post = (req, res, type, exception) => {  
  // Any other error handle / post processing.
  redisClient.set(_redisKey(req), 'y')
}

Conclusion

Tracking whether or not a user has visited your skill, and the different sections of your skills is only one part of the equation. The other piece is leveraging this information to make your skill more enjoyable. No longer should returning users need to suffer through unnecessary instructions. Additionally, you can leverage this information to identify interesting hints to your users. I hope this technique leads to your users having a better first user experience then Laika's first, and only, trip to space.