The Hidden Homescreen
A conversation about conversational interfaces.
Lots of discussion around conversational chat interfaces and bots. Here are my thoughts (much of which are reflections of conversations I’ve had with John Borthwick, Peter Rojas, Ana Rosenstein as well as others inside and outside of betaworks: Part I defines some terms, Part II is some background and Part III goes into detail on where I think the opportunities are.
Part I: First, let’s talk about what we’re talking about.
Bots and Chat Interfaces are not the same thing, but they’re related. For the purpose of this post, lets define them as follows: Bots are chat-based conversations between a user and an automated response system. No humans. Chat interfaces are a superset of this — any app where the user interface looks more like messaging than point-and-click. So, all bots have chat interfaces, but not all chat interfaces are bots. Square is a rectangle type situation.
A few of the chat interfaces I currently use, or have tried, include automated bots, human-powered bots, and something in-between — where some parts of the interface route to humans and other parts to automated bots. Some fall into the category of productivity and others are purely for entertainment:
Pure bot interfaces into other services:
- Digit: text once a day with today’s account balance and the difference from yesterday. I can respond “why” to get all transactions in past day, “recent” for last 3, “balance” and it siphons off a bit of my income into a separate savings account. It also texts when I get an ACH deposit (usually a paycheck).
- PlusPlus: a slack bot that tracks “karma” from different slack users. In any slack channel. You can give someone karma by saying “@mathartman++” (or minus minus) and the bot keeps the leaderboard. It’s intended to be for entertainment, not tied to any specific scale.
- Eat Arcade: text once a day with two lunch options which I can pick to be delivered at noon. I can respond with one word to order.
- Movie Night*: kik messenger bot that I can ask for movie recommendations for what’s playing this weekend. No unsolicited push notifications ever, just responds when I ask it for recommendations & movie times
- Massively: a number of chat-based games/interactive stories
- Assi.st: multi-platform (I use it on telegram) text-based interface to do everything from ordering flowers to getting an uber. I believe they’ve just aggregated a bunch of APIs, so no humans in the flow
- Howdy: Bot in slack that lets you manage daily standup meetings by DM’ing everyone in the meeting over slack to get their agenda items and then aggregates them back in the main channel once everyone has responded. (betaworks invested in this one)
- CVS: pharmacy auto texts me when my prescription is ready
Chat Interfaces that are at least partly human in the communications layer:
- Rise & Lark: weight loss apps where a personal nutritionist gives you feedback over chat. Lark’s onboarding is particularly fun and entirely chat-based
- Operator: chat-based interface to shop
- TalkTo: this service was shut down but I loved it. I could text a question to a business and someone (disclosure: betaworks invested in Path, which acquired TalkTo)
- GoButler & Magic: both let you chat with a person about what you need accomplished and they’ll use on demand services to get it done for you. Like a personal assistant. Magic started out purely as a text-message based service.
- Poncho: daily text message with a personalized weather forecast. I take the 2,3 train so it lets me know when there are delays. If I drove, it would tell me which side of the street I could park on today, and if I had frizzy hair or were allergic to pollen, it would include those details too. But I don’t, so it gives me only what I need. I‘m including this not as a pure bot, since real people write bits and pieces of their humorous weather reports. (disclosure: this was built at betaworks)
- Fin: Haven’t tried this much yet, but it’s a search engine built entirely on top of a chat interface (and includes audio input as well)
- Text Rex: An SMS-based restaurant recommendation service built by The Infatuation.
(Lots more telegram bots at botfamily.com and slack bots at slackbotlist.com)
Part II: What’s causing the rise of the chat-based interface
The move to chat-based interfaces is mainly developer driven: relative to a native iOS or Android app, development of a chat-based app is faster and marketing is less crowded (for now). It is also partly consumer driven in that it is a painful for consumers to have to switch in and out of different apps — or even to have to download an app at all. However the developer pain point is more significant at present.
For app developers, marketing is often hard. #Homescreen data shows that apps on users’ homescreens are pretty calcified. In January 2016 over 50,000 apps were submitted to the app store. However, most smartphone users download zero apps per month.
So, basically:
Anecdotally, developers are reporting lower user acquisition costs for text message based services. This doesn’t make total sense to me since it’s unclear how users learn about the text #. However, I do believe it’s possible that an SMS-based signup funnel may have less friction than an app-download user acquisition funnel. Moreover, Slack and SMS are not overcrowded with these services yet, making users more open to trying them new than they are to trying new apps. This will likely reduce user acquisition costs (for now).
In addition to marketing, development is also easier. Coding for iOS takes more time than coding for SMS, primarily because there is no GUI to create and developers aren’t often also graphic designers. Additionally, as Sam Lessin pointed out in his post, because bots run server-side, the entire interface is controlled server-side. So, it’s far easier to deploy changes and customizations. Perhaps most importantly, the depth of these services can live on the server-side versus in the deployed user interface (since there is no deployed UI).
Part III: The fun stuff…where are the opportunities?
Okay so the shift to chat interfaces is driven much more by developer needs than consumer needs. That doesn’t mean there aren’t use cases that turn out to be great for consumers. So what types of chat interfaces are actually good for the user? Asked another way: Should your service live in chat? Or, if you want to make a useful chat-based service or bot, what should you build?
What follows are a few ways of thinking about where chat interfaces add value for consumers.
1. Context
The value of a chat interface is inversely relatated to the number of new parameters the user will need to provide.:
One example I hear a lot is “we’re going to let you call Uber directly from a Chat.” The question here is whether the chat will be able to get enough context for this to be a better experience for a consumer. The parameters Uber needs are: Location and Type of Car. Knowing where you’re going would be nice, but it’s an optional parameter. Here’s how that might look over SMS:
I’d argue this is not a better experience than the native Uber iphone app. The SMS message has no additional context from which to get its parameters. Compared to the mobile app, which already has your location. Simply by typing “call me an uber” you’ve already tapped on your keyboard 15 times versus tapping once in the app.
One obvious way to solve this is by the messaging platforms allowing permissions. For example, if you’ve already given Facebook Messenger access to your location, then the link to a location might highlight an you might enjoy an experience where you hold down
That’s a subtle difference, but the two reasons it’s interesting are that I’m already in the context of the chat, so I don’t even need to switch apps, and since it knows my location, if it weren’t surging it would literally just me typing “uberx” to summon the car.
There is a second way to improve context and that’s by providing outside constraints. There is a new Amazon Alexa skill to call an Uber directly from the Amazon Echo. Normally you run into the same problems as with an SMS bot. However there is a new constraint: the Echo is stationary, so if you’re using it, you’re where it is — i.e., the location parameter is effectively hard-coded.
So, the more context the service already has, the more value a chat interface can add. Conversely, more parameters required means a worse chat experience.
2. Collapsing Conversations
If more context means easier communication, there is an opportunity to collapse what would normally be a very long conversation down to a very short one. My current favorite example of this is Everlane’s receipt over Facebook Messenger (Everlane is a betaworks investment). Brian Donohue told me recently that he bought something on Everlane and they asked him to get the receipt as a Facebook Message. Now this alone isn’t such a big deal, just push distribution. However, it didn’t fit, so he needed to exchange it for another size.
The normal return flow might be: look up a phone number for customer support, wait on hold, they ask you for your receipt number and perhaps to confirm your address. If you’re Brian, then maybe you have to spell your last name: D-as-in-dog-O-N-O-H-U-E-as-in-Everlane. It always struck me as ironic that we have to go through this customer service process while talking on a supercomputer.
Think of all the context and parameters that Everlane already had when Brian responded to the Facebook Message asking for an exchange:
I have no idea if this is actually how they responded, but think of all the parameters they had without asking Brian a single question: the receipt number, the item, and all of his customer data including his home address. This is a great experience for the consumer. It collapsed what would be a long conversation into a very brief one, powered by all of the context that comes with having started a chat on top of the receipt data.
3. Ongoing Conversations
Different from collapsing conversations, an ongoing conversation between a user and a service can often lend itself to chat. But just because something requires a long conversation doesn’t mean that chat is a better interface. For example, using a chat-based interface to describe which Instagram filter you want may not be more efficient than just pressing a few preview buttons.
A good example of an ongoing conversation that works well in a chat interface is Digit:
You can think of Digit as a conversation around my spending habits. The goal of their product is to help me save using Digit, but in the process, they’ve built such an easy lightweight interface that I now rarely open up my bank’s iPhone app.
3. Designing Push & Pull
If being thoughtful about what people actually want pushed to them was important in email, it’s 10x more important — maybe even 100x — in chat-based interfaces since they show up directly in the notifications screen on your phone.
Tuning your push notifications is difficult at best, and often impossible if an app hasn’t allowed a certain level of granularity. So for a “pushy” iOS app, users must decide either to delete it, or navigate to the notifications settings and see what options you gave them to turn off push notifications. In a chat interface, users often have the granular control to unsubscribe/block/delete easily after a single annoying push.
Great chat-based apps will message you just enough helpful information you need and then wait silently until you pull asking for more specific information.
One way to think about the Pull side of this equation is like a messaging-based deep link. In the Digit example, typing “Recent” lets us the user reach directly for the information he or she wants, instead of traversing its web site pages or phone tree.
I don’t think people are making a big enough deal out of this. Almost every business has multiple constituencies when you look under the hood, and often different types of users who want to get different things out of it. When designing an app or website, you make tradeoffs about who you’re targeting.
An easy example of this is Libsyn podcast software. Some people release podcasts once a month. For my DYB podcast, I release about once a week. The main dashboard for Libsyn shows total number of downloads, which is nice. But the other metric I think is important is downloads of my most recent episode, whatever that happens to be. This is located under Stats->Show Stats->Pick the show->Details->scroll down to Downloads By Day. So it’s deep in there on a website I had to log into, that is also optimized only for desktop. Not ideal.
Why do I care about this episode? Because it’s the only one I put an advertisement on, so I want to track how it’s doing. However, most podcasters probably have ads in all episodes, so it matters less to them. Libsyn made a perfectly rational decision to de-prioritize a feature that is really important only to only a small portion of its userbase.
But imagine if Libsyn had a chat-based interface like Digit. Every day it could push notify me with today’s downloads and yesterday’s. That would be helpful. What if the command “Ep 3” gave me stats on episode 3.
This change is profound for two reasons. First, it’s a deep link directly into the information I want. But second, its the beginning of an invisible, customized Homescreen.
A Hidden Homescreen
For a subset of services, particularly those in the ongoing conversations category, there’s valuable information they can push every single day. Digit has started to replace my bank’s mobile app not because it’s easier to text a bank, but because it texts me once a day. As a result, it’s almost always in my most recent 10 texts. While my bank’s app isn’t on my homescreen, my SMS app is. Often, several of my most recent text messages are from services:
If Everlane or Digit starts pushing me coupons, I’ll quickly block them. But if they respect my inbox, there is a fascinating opportunity for me to reengage. This set of contacts looks a lot like a list of my favorite apps. Instead, it’s a list of my most frequently used chat-based services. I have a similar lists in Telegram and Slack and there can be similar lists in Kik an Facebook Messenger.
Their commands are even less visible. This is true of natural language services such as Operator, but especially true of bots, which often have strictly defined commands. I can customize this Hidden Homescreen by remembering my most used commands.
One way to see a list of functions is simply to look back in the chat stream to see what you said before. Was it ‘balance’ or ‘savings’? Oh yeah, I typed ‘balance’ last time and it gave me my savings balance. These commands form the second axis of The Hidden Homescreen.
This means extreme personalization since the commands I use most don’t have to be the same ones you use. In the podcast example, Libsyn no longer has to decide to prioritize your user needs ahead of mine. Each of us can focus on the commands that best meet our needs, like a bookmark in a browser or an app on your iPhone (the old, visible homescreen).
It’s often difficult to put a label on what isn’t there, but this Hidden Homescreen of functions becomes even more apparent (and more hidden) when you have chat-based services that use voice. The Amazon Echo uses a Siri-like interface calle Alexa, to which you can add “skills” which seem a lot like apps or services. Remembering the names of each skill you’ve installed, let alone the commands in each skill, illustrates the extent to which this new homescreen is entirely invisible. I’ve heard some people make notes about what skills they’ve added along with the commands Alexa understands and then users tape that list to the wall above the machine.
Conclusion & Further Exploration
Yes, the proliferation of chat interfaces has been driven as much or more by developers than by explicit consumer demand. But in the process, valuable services are being unlocked, some of which consumers will surely love.
I wrote a lot about what types of new services can thrive, but the depth of the service matters too. For data and AI-focused services such as x.ai, the depth of service is on the back-end where the message processing happens.
Some services are creating chat interfaces on the front-end and stitching together APIs on the back-end. In this case the “depth” is on neither side, making it difficult to create meaningful platform value.
Another area to explore is where these bots live. I have no link for MoveNight above because there is no website — no way for me to link to it other than telling you to add it by name on Kik. This is not only inconvenient, it has the potential to have a viral coefficient of zero. How will these services be discovered beyond being featured by the platforms on which they exist?
A new chapter is beginning and I look forward to trying out, building, and investing around the new Hidden Homescreen.
If you’re interested in the Hidden Homescreen and chat-based interfaces, let me know on twitter @matthartman.
I work on seed stage investments at betaworks in new york city. You can find me on twitter @matthartman and listen to my podcast about profitable, non-tech businesses at dybpodcast.com
