I’ve been working furiously on the back end logic for Fwd:Vault for the past few weeks, specifically the logic that processes incoming messages/attachments, archiving them in the system, or returning stored data per user request. As I got into the final nitty gritty, I confronted a serious design issue: should the system use one email address for all processes (storing new data and retrieving stored data), or should I split the processes into separate addresses (one to store data, another to retrieve)? I’d like to share the process I went through to reach a decision, and the rationale for the final decision; I thought someone out there might find it useful. Fwd:Vault’s claim to fame is the marriage of email with backups, eliminating the software in the middle (details in the launch announcement and the official site). Consequently, how the addresses are arranged from the systems end is critically important. The signup process and basic use instructions must make it clear where and how to send requests to store and retrieve data. Two addresses could confuse the issue, but then again so could one (“Hello, CS Rep, my request for my stored document got stored as a new item instead…”). I see this issue as one of the most fundamental hurdles I’ve faced with the system yet, so I sat down and laid out pros and cons for each. I came up with the following lists… Arguments for 1 Address:

• Simpler usage process overall
• Less instructions required
• Simpler mail headers — no need to worry about different reply-to in storage receipts; less likely to be ID’d as spam

Arguments for 2 Addresses:

• Cleanly separates store/recover processes
• No processing logic to “guess” message intent
• Simpler code logic — less chance for errors/bugs in general

When I sat down and compared the lists, the decision to use a single email address became a no-brainer. Here’s the trick: do you see the natural break occurring in those lists, making the decision so easy? As the post title indicates, its all a matter of perspective. Each list represents problems and benefits for entirely different sets of people. If you still don’t see it, reread each bullet, then ask yourself, “Who is this actually a problem for?” Easy use, less instructions, and simpler mail headers are all benefits to the user, while separation of processes, message analysis, and bugs are all problems that the developer can overcome with enough time and attention. In short, if I chose two addresses instead of one, I’d be robbing the user of a better experience in exchange for saving myself some development effort. This of course turns around and robs me of more users down the road, effectively nullifying any short term gain in time I might have. In an age of endless choice, the best overall experience always wins. When putting together any product or service for any target audience, tie always goes to the customer. If it improves the experience, and costs of both time and money are within reason, then you should always go the extra mile. Long tail economics will pay back that effort in spades over time.