THE SHELL
BACKSTORY
The team at Toda.Network, an IT & Services company with offices in San Francisco and Toronto, was working on a proof of concept for an anti-spam email solution. The goal of the product was to give the receiver of messages more control over their incoming notifications, and for the sender to be able to push their messages into a higher priority tier (that has been pre-set by the receiver) to ensure that the receiver sees it.
OVERVIEW
Problem: (1) As a receiver of emails and messages, I would like to be able to have more control of my notifications so I see those that are most important to me first. (2) As a sender of emails and messages, I would like to ensure that my message get seen first instead of getting overlooked.
Objective: Create an app/plug-in/extension that integrates into the OS, providing both sender and receiver with more notification control.
Deliverable: High-fidelity wireframes & prototyping using Material Design for an Android device.
INITIAL INFO
The ultimate goal for Toda was to create an overlay to be integrated into existing email clients (but for demo purposes they imagined showing their own email client). This overlay was to encompass a couple key elements:
-
Having an inbox that sorts the messages according to the "circles of trust" the user establishes.
-
Showing circles of trust or inbox tiers. There would be at least three: the first being a whitelist of email addresses (friends and family, for example); the second being a high-priority tier whereby the user specifies that senders must attach pre-bought tokens for their message to arrive in that tier; and the third being medium priority, whereby the user specifies a lesser token amount as a condition to send an email.
Although this info concentrated more on the user who was receiving the messages, I was also given rough wireframes from the sender's perspective, so that I could begin to wrap my head around both of those experiences. The following was provided to me by the project manager:
Admittedly, this was a bit of a heady problem for me. At first glance, the ask from Toda seemed pretty simple: allow users to create 3-tiers of incoming messages based on priority, and allow senders to pay into which tier he or she wants to appear in. Easy-peasey. However once I dug in, I realized there were lots of question marks. This is where clear communication between me and the project manager became a priority with regular check-ins and feedback as I worked.
MY SOLUTION
I decided to tackle this project focusing on the experience of the receiver of messages. This would include setting up the three priority tiers, a way to organize those incoming messages, and a dashboard-style section that would allow the user to see their token balance.
Deciphering the ins-and-outs of how the system would work was one thing, however what I found most interesting was how to convey this system to a user who would be seeing it for the first time. Once the back-and-forth with Toda about the logistics was figured out, I was left with the question of "how was I to distill that information into digestable snippets that would not overwhelm the user?"
To accomplish this, the onboaring experience would be crucial, for both Toda's demo purposes and the user.
ONBOARDING
To begin, I started with lo-fi wireframes as the main communication tool between me and Toda to make sure we were all on the same page and that the concept and requirements had been fully-understood. At the same time, I tinkered around with onboarding userflows.
Once the flow and lo-fi wireframes were finalized through ongoing communication with Toda, next was creating a hi-fi prototype.
The goal here continued to be simplicity for the user. This involved short n' sweet copy (which I created using key buzzwords that Toda had been using in reference to this project) as well as call-to-actions that were concise and exactly described what the next step in the onboarding process would be. The user needed to understand the concept as s/he went along as well as what was coming next; therefore, instead of using generic CTAs (such as "Next" or "Submit"), I purposefully incorporated the actions into the copy (such as "Assign Contacts", "Add", and "On to Layer 3", etc). It's important to guide the way while keeping the user fully in-the-know at all times.
Feel free to walk through the onboarding process with the prototype below (or this InVision link if you're on mobile for example).
THE PRIORITY LAYERS
Part of the problem was showing how the different priority layers would be displayed while keeping things simple and intuitive.
With simplicity still the focus and as not to overwhelm the user, I incorporated a familiar email UI, along with tabs that would fulfill the needs of the different layers. Since this was supposed to handle both incoming emails and text messages, I colour-coded them so the user would be able to see at a glance what type of message was sitting in his or her inbox.
The incoming messages for Layer 2 would be ones that have S-Tokens attached to them. They needed to be sorted by the highest amount at the top, as well as by date. The S-Token amount needed to be obviously displayed for the user as well:
Layer 3 would follow suit, however no S-Tokens would be displayed. This layer was meant for users who did not have The Shell installed on their device or who decided not to include any S-Tokens, knowing their message would get tucked away in Layer 3.
LOCK SCREEN
Of course, since The Shell is essentially a notification management system, how would it affect the notifications that appear on the lock screen?
Toda envisioned that The Shell would be integrated into the device's OS, which would include the functionality of your home screen as well. They needed a way to demo this functionality, therefore I created a little gif that could show the possibilities.
The messages that get filtered into your Layer 1 whitelist appear as regular notifications in the same way we are all used to. The messages belonging to Layer 2 and 3, however, would be tucked away; they would still be accessible with the notification icon of how many new messages have come through, but they are not the top priority. The user can check them when he or she feels it is the right time to do so.
Toda went on to present this idea at a conference in California. The presentation can be seen here.
TAKEAWAYS
1. Clear and open communication is key. Throughout this process of trying to simplify a somewhat complex problem within a short timeframe, I found it necessary to ask questions, openly brainstorm, and send my progress throughout for feedback. This resulted in quick progress, constant reiteration and ideation, and kept both me and the project manager on track.
2. As someone who is admittedly living more in an iOS world, it was interesting to delve more into the world of Material Design. It made me reassess my (not-so-serious) snobbishness of Apple and made me (somewhat 😜) reconsider if iOS is the superior design system.
This project was done in 2018. If I were to revisit this project today, there are some key UI/UX changes I would make, however I haven't included them in this write-up. If you would like more info or have any further questions, please don't hesitate to get in touch!