Riffing Off Of Scott Belsky’s Framework
Chris Dixon has a popular saying : “Come for the tool, stay for the network”. It’s one of the very powerful frameworks with which one can evaluate products very effectively.
I use frameworks too. I always use them when I use, evaluate and compare products. I have two of them —
“Stickiness is built with accumulating utility, delight & network effects”
“Invite them with a hook, make them stick around with a community.”
In the second framework, by “them”, I mean the users. By “hook”, I am referring to something that compels someone to use a product for a bit longer after having tested it out for the first time. The “hook” involves the on-boarding process. I think of the hook as everything from the discovery to first impression of the product after having played around with it for a minute or so.
I recently read a piece by Scott Belsky where he talks about what he calls the “first mile” experience. Belsky writes —
In a world of moving fast and pushing out a “minimum viable product,” the first mile of a product’s user experience is almost always an afterthought.The welcome/tour, the onboarding, the explanatory copy, the empty states, and the defaults of your product make up the first mile.
He, too, is referring to the initial experience with a product. And, it reminds me of the first half of my second framework that I mentioned above.
In an older piece, Belsky writes —
In the first 15 seconds, your visitors are lazy in the sense that they have no extra time to invest in something they don’t know. They are vain in that they want to look good quickly using your product. And they’re selfish in that, despite the big picture potential and purpose of what your service stands for, they want to know what will immediately benefit them.
I find this mental model of thinking very intriguing. Belsky has discussed how his framework applies to websites or apps, retail shops and books in his posts. I want to see how his framework of first mile experience fits into the bot paradigm.
What I’ll do now do is deconstruct his piece and see how his ideas are relevant in the context of bot products. I will mention the sub-topic with a couple of his lines along with my thoughts in the bot context.
Optimize For The First 15 Seconds Of Laziness, Vanity, & Selfishness
In the first 15 seconds, your visitors are lazy in the sense that they have no extra time to invest in something they don’t know. They are vain in that they want to look good quickly using your product. And they’re selfish in that, despite the big picture potential and purpose of what your service stands for, they want to know what will immediately benefit them.
People are too lazy to invest time and effort into understanding —
- Why does a chatbot makes more sense than an app for a particular use case?
- How do you communicate the navigation? What commands/syntax to use?
People are vain in the sense they want to feel accomplished by getting done with whatever it is they wanted to do as fast and conveniently as possible.
People are selfish in that no one cares about developers’ app discovery issues, dwindling app monetization prospects, a new conversational UI trend, declining app downloads and dozens of other reasons why a chatbot matters or why the trend is something worth paying attention to. All they care about is satisfying their needs, desire and intents. Immediately.
Belsky says every person, while dealing with new products, is lazy, vain and selfish. I fully agree with that.
Ain’t nobody got any time for developers’ rants or processes.
(I have programed a fair bit. I have built products. I know how brutal it gets. But a user just won’t care. )
DO>SHOW>EXPLAIN
The most challenging products must EXPLAIN how something should be done
Expecting people to read your blog or watch a video on what commands to use and how to extract maximum value out of a chatbot would be the worst way of going about dealing with user laziness and onboarding.
One step better than explaining is SHOWING
In the app world, showing how things get done mainly imply in-app, real-time tutorials in the form of tool-tips. But, in the bot world, this could mean pushing an explainer GIF in the very beginning to educate a user about value proposition and commands/navigation. This will be possible only when the underlying platforms will support rich media push.
But the absolute best hook in the first mile of a user experience is DOING things proactively for the user.
For bots, this would mean builders need to be very accommodating with what user might respond initially when they don’t have much idea as to what to do. Either offer the value upfront without user having to say (or type) much or the “error catch” game needs to be strong to offer value subsequent to user’s initial responses which may not be what you really wanted them to be.
ACCOMODATE EGO ANALYTICS
Are you more likely to use the product when your friends post great content, or immediately after you post great content? If you’re like most people, you feel the greatest impulse to jump back into a social product (whether it is for work, or for personal use) after you’ve just posted something for others to see. Why? Because your ego is on the line.
All the social products and some utility apps have a reengagement mechanism that fuels a user’s ego for building stickiness. It could be likes on Facebook or earning points on Swarm. In the bot world, there could be some gamification in certain use cases. Words of encouragement on completing the tasks and building up a personality via a voice could help in bringing users back. In the future, I can imagine bots having some social aspects to them once the underlying platforms facilitate some advanced user interactions for building a social graph. This could be used in creative ways for what Belsky calls ego analytics.
PROVIDE IMMEDIATE NOVELTY OR UTILITY
In all successful networks (and most other tools) I have seen, an immediate novelty or utility preceeds the larger promised benefits.
The larger promised benefits might be building one-to-one relationships with users, saving them the hassle of downloading/maintaining/storing another app, eliminating the struggle of switching contexts etc. But, all of that won’t matter if the user is not satisfied with what the product does immediately for them. The core purpose needs to be delivered from a utilitarian standpoint first along with the novelty of having an unique voice.
NAIL YOUR DEFAULTS & EMPTY STATES
The default options you provide, like which tab they land on and pre-populating fields with suggested selections, make all the difference in pulling new users through the first mile.
I cant think of what “defaults” might be in the context of conversational products. It could probably mean, in some use cases, delivering a static result or some value thats independent of user inputs so that user could get atleast something out of it without doing anything.
Product designers tend to design their products with the lens of an active user, someone who has already engaged enough to not have an empty experience. But the reality is that new users land without any history in your product, and what they typically see is sad. If the feed is empty, find something else to show that helps educate and entertain.
This one is huge. I have found myself falling into this trap myself while building a chatbot. It’s very easy for builders to just assume that a user knows how to navigate a conversational workflow by using certain terms in certain fashion just because active users or people that understand chatbots in general use. In reality, when you get a non-techie (for lack of a better word) to beta-test your service, you realize how differently different people think and navigate within the same environment. Moreover, it is quite a sad experience to literally have an empty chat feed and expecting a user to know what exactly to say or do to begin the workflow.
BE MORE ACCOMMODATING, LESS RETRAINING
When you can use a familiar term instead of being original, do so.
I believe this is the only concept from Belsky’s piece that literally translates well into a bot context.
This approach in no way is a proven path to building a successful bot. I am still learning and exploring myself. I just thought it would be interesting to see how Belsky’s general ideas fit into a specific product designing process. Please reach out with any of your ideas or thoughts on this.
Thanks Esther Crawford for reviewing a version of this piece. Check out her personal bot.
