Email, the Operating System for Life
Why you should bring your interactions to the place where people already spend their time.
Email is the #1 Destination
Ryan Hoover published a great article the other day on the trend of using email as an interface to do other things. You probably already use it in this way by sending commands to other systems: “forward this email to my expense site”, “watch my email for interesting stuff,” and “make a to-do list out of my emails.” In my experience, managing tasks through email (though hopefully not using your inbox) increases productivity and makes you generally better at getting stuff done. And there’s a bit more that we ought to be doing.
The “stuff we ought to be doing” varies, and usually relates to long-running recurrent tasks (remember someone’s birthday, maintain a daily or weekly status), project-based tasks with a deadline (I need to get some stuff done before next Wednesday), and one-time actions (“Can you find this for me, right now?”) Email is really lousy at these things, which is why we use other applications for help.
We need a better way to surface applications and services in email without breaking the way people handle email today.
Remember. All. the. Logins.
Awesome! You remembered all of your passwords (or have a great SaaS app to handle that.)
There are so many great applications that are out there (many are even free) that can get stuff done. Now, which ones should we hire to do the job? And what job are we actually doing? Just managing the logins can be a chore, and getting beyond that to switch contexts every time you want to start something new can waste a lot more of your time.
Getting started isn’t easy.
One of the great challenges of Software as a Service products is that there is a login to remember, a site to visit, and tasks to do in that other system that will help you to better manage the minute details of the things you do. You might use Sprintly for Agile Dev, Desk.com for Customer Service Interactions, Expensify for Expenses, and so on. Yet all of these products depend upon you start an action in email and then resume it in another system.
So which app was I using to do that?
When you make constant decisions that force you to have another login, another app to pay attention to when you’re on the go, and yet another slew of notifications, you dilute your ability to make quick decisions. It’s a mental burden to understand which things really need attention and which notifications arrive as a result of long-forgotten decisions that are no longer important.
Ok, Now What?
When you build an application - and need customers to participate - it’s your job to find the place and interface where they will get the most value out of your idea. I believe you should not only make your service responsive but also your service design responsive.
Towards a Responsive Service Design
Making a basic responsive design is pretty straightforward - making an insanely great one is really hard. I think the same is true when you invent a responsive service design. Making your service design responsive anticipates that customers will use different modalities and interfaces to access your idea, and that some customers will never cross into another way to use your idea. App customers may not behave the same as email customers, and vice-verse. But there are a ton of people using email, so how can you add value to their experience without being overwhelming?
Service Design as a concept implies that there are activities that customers take to get tasks done. Completing the tasks may require external actions and may depend on other tasks or actors. Finally, the activity you are designing may happen in multiple places.
Email to the Rescue: The Lowest Common Denominator
Because people spend lots of time in email and there are already many ways to access it, email is a great candidate to act as an operating system where customers might do these service tasks as part of an overall service design.
There are three basic ways you can push email towards being an operating system of sorts:
- Create a browser extension - force your way into the experience, either passively (Klout in adding scores to your Twitter pages) or actively (Rapportive, adding persistent information to the existing real estate)
- Invisibly solve a problem - have a background service that listens to email and makes decisions or surfaces information based on your preferences (Sanebox, for example, which automatically files your messages)
- Take explicit email commands - “add note”, “send tweet”, etc and make them easier to use for “normal” people and abstract them to other media
Time to fight the blank page
All of these methods have advantages and challenges - let’s take a look.
Make a Plug-In
You could make a browser extension that will either take over the real estate or silently monitor or insert information in the places you’ll most likely interact with other services. Plug-ins are awesome for absolute control and transfer very poorly to other interfaces.
As an example, I love Rapportive because it does a great job of using the mostly empty screen real estate I used to see in Gmail and fills it with valuable information about the person who is contacting me. It even shows me the latest view that other people using the same service have of me. Rapportive is a great experience because it exposes some methods to other application services I use (send invitation, start tweet, read Facebook post) without cluttering my view. Some drawbacks of this method are that I don’t have any more mental space for more plug-ins. I’m sure that was one of the reasons LinkedIn purchased this scrappy team.
Create an Invisible Service That Does Your Work
Another way of approaching this problem is to work behind the scenes and make the changes necessary to increase productivity or other goals. This method is cool because it’s client-independent. And it still requires developers to create different interfaces in different client. (There’s less to customize, though.)
Sanebox just works - it filters the email I receive into Gmail labels and then gives me a single digest a day to take actions. From my daily email digest I can delete unwanted messages, set reminders, and see how I’m doing relative to prior days or weeks. When I want to ignore Sanebox, it’s still doing work for me and allows me to close email for long periods of time and then solve for a burst of emails all at once. I don’t have to worry about filing any more - I just search.
Another version of this implementation is the inverse of a service that is implemented everywhere - Mailbox lives only in an iPhone app and allows you to connect to many email clients and apply the same simple management effort to each one. Mailbox takes the best metaphors from the mobile interface and applies them to email: swipe to promote an email to a task or to archive or delete it.
Make external tasks possible in Email
The traditional, geeky way to make external tasks possible in email is to require the customer to send an explicit email command in a subject line or in an interaction body so that the server on the other end of the “conversation” knows exactly what task to execute. In practice, this works well for “send my stuff to you and have you process it” and is harder to execute for “do only the thing I want you to do and not that other thing based on the thing I type.” Normal people - that is, people who don’t talk to computers all day - have a hard time doing this.
Yet the potential exists - many of us use Siri, Google Voice Commands, or interfaces like Google Glass to create a graph search-like call and response with our services. So let’s do that with email - and that’s where Google is going.
Google’s version of this is borrowed from another company, however. Their previous versions of “do stuff in your email” were possible only for geeks to do. You needed to install a “Labs Feature,” or use keyboard shortcuts, or do other things late adopters don’t tend to do. And what’s the solution? Apps that magically show you what to do and offer fewer choices and fewer configuration steps.
We should thank Facebook and Apple for priming customers to act this way - the app economy makes customers expect one-click actions to solve their problems. So now it will be possible for publishers like Google to create structured, in-context actions for customers to complete and interact with other systems. Some will call this backsliding and the new “Death of Email.” I call this the birth of “Email, the Operating System for Life.”
——————————————
Greg Meyer thinks about service at scale and also writes at Information Maven. Find Greg on Twitter at @grmeyer.
