The User Experience (UX) Of Email As An Application Platform Interface
When you build a web-based application, Email is a natural and inevitable extension of your application platform. It provides an easy to consume, asynchronous means of communication. In the majority of cases, this communication is unidirectional - application to user. But, in some cases, email provides a bidirectional workflow; one in which the user can communicate back to the application using an email Reply. The user experience (UX) of this user-initiated communication tends to be awkward; and is something that I avoid, even in an application that I've personally built.
To be clear, I am not one of those people that hates on Email. Sure, I get way too much email; but, it's still a great medium. In this post, I am specifically talking about the use of email as a bidirectional communications workflow for an application. Take, for example, the ability to respond to InVision App comments using an email reply:
| |
|
|
||
| |
 |
|
||
| |
|
|
Notice the call-to-action for a "Reply" as a means to post a comment back to the application. I built this workflow. I built the email parser that strips out signatures. I built the code that pipes the extracted comment into the target conversation. I know exactly how it works.
And yet, I never use it.
This isn't a shortcoming of the InVision application or an insecurity about my code. This is a user experience (UX) problem. This is an emotional problem. And, it is in no way specific to InVision.
No feedback or confirmation of success.
When I use an email to communicate back to an application, the biggest user experience problem is that I get no feedback that it actually worked. The email just disappears off into the ether, routing through network devices, SMTP servers, HTML parsers, and application WebHooks. At any point, one of the systems could fail, and I may never know about it.
Now, I could open the application and check to see if my content made it to the intended destination. But such an exercise is fraught with false-negatives. Email is an asynchronous communications medium. It takes a while to get to where it's going. And, even when it gets there, the processing of that email may be asynchronous - maybe it gets pushed onto a message queue and consumed by a set of workers. If my email-based content isn't available in the application yet, something may have gone horribly wrong; or, it may still be getting processed by the application. As a user, I can't know.
And, of course, opening up the application to check for proper processing completely negates the benefits presented by using email-based workflows.
No validation that your email-based content was consumed correctly.
Dovetailing with the previous concern, even if the email gets to where it's going and is processed by the application, I have no assurance that it was actually processed correctly. Did the application see all of my content? Did it see too much content? Did it accidentally pull in the automatically appended signature that I don't even see in my "compose" textarea?
No one wants to be this guy:
| |
|
|
||
| |
 |
|
||
| |
|
|
And frankly, no one wants to work with this guy. When your email signature shows up in an application, it leaves a bad taste in people's mouth. It makes them think that you're lazy and just haphazardly using the system whenever it suits you. Which is, of course, not actually the case at all - you just didn't realize that the application started pulling in your signature because of some wonky formatting you thought would be fun to use.
No insight into the timeliness and / or relevance of the interaction.
Email is an asynchronous communication workflow by nature. It takes time for the email to get to your inbox. Then, it takes time for you to see it and read it (and, if you're like me, that's a lot of time). Then, it takes time for you to write your reply. Then it takes time for your reply to get back to the application. Then it takes time for your reply to be processed by the application.
A lot of time can pass between the initiating action and the processing of your response to that action. And, a lot can happen in that time. But, when you're looking at an email, there's no way to know what, if anything, has happened. Depending on the type of application, there's no way to know that your response is still relevant or warranted.
No overarching context.
Dovetailing with the previous concern, email-based workflows often lack a sense of greater context. Which means that when you go to reply to an application email, you're working with an incomplete mental model. And while this may not be relevant for the particular email interaction, it creates a point of friction in one's mind - a subconscious sense that you may not understand the full gravity of your actions. This subconscious sense of unease will have a negative impact on the way you feel about the application at large.
Now, not every type of application will suffer from all of these concerns. For example, the concept of timeliness and relevance is likely to be an issue only when you're collaborating with other people. But, I think the user experience (UX) of email as an application interface is a tough one to get right. I know that there have been very few instances of this workflow that leave me feeling confident and satisfied with my interaction. But, your mileage may vary and will definitely heavily on the type of application that you're building.
Reader Comments
Hi Ben,
not related to this post.
please review my video:
https://www.youtube.com/watch?v=bEkPEnudm7s&feature=youtu.be
I think you will appreciate it as it gives you the best of all worlds, typed redux store...
let me know what you think
Angular 2 Kitchen sink: http://ng2.javascriptninja.io
and source@ https://github.com/born2net/ng2Boilerplate
Regards,
Sean
First of all, being bored at work does pay well if you have a Smartphone and you browse through blogs. Amazing information with facts thoughtfully incorporated within. Definitely going to come back for more! :)