A simpler shopping experience
Adventus
What is Adventus?
An online shopping app that was designed by me to facilitate a faster and more streamlined shopping approach. I took inspiration from my time in college and asking the busy people around me over the years what they would want out of an ideal online shopping experience. They would go on to tell me things like: if being onboarded to an app was quicker I might sign up for an account with X retailer or if checkout was really quick and there was less hoops for me to jump through I would shop more with Y service. This was my first ever design project and something I have revisited to see what I could improve upon. I learned a lot from this and I understand there will be much more to learn as I grow in this field of work.
What were the main goals of designing Adventus?
Easy and efficient onboarding of the user. Making sure they could log in or create an account as quickly as possible. Having pain points with the user experience before you’re even using the app would mean loss of real user acquisition and retention.
Quick conversions from items in your cart to a sale was a large goal in the process. Keeping things quick, concise, and predictable would be the biggest pillars in the checkout flow. It also had to follow basic guardrails to prevent accidental purchases. No unexpected hurdles to jump over, no lengthy checkout.
Also creating lists was something I personally like doing when I shop and I wanted to make sure that if someone was to make a list they could very easily just add all those items to cart or invite others to see them. Sometimes you have a holiday coming up and you have to buy a bunch of stuff for people you love and it would be nice if creating lists and buying items from them was simple and easy. This feature of the app was pretty personal to me as I feel some other online retailers don’t do this particularly well.
Onboarding Flow
Problem 1: Onboarding flows needed to feel expected as well as being short and sweet
The concerns that occurred over time for getting this right were:
How long is too long? What information does the app need to just get you going
What steps does the user need to go through as opposed to optional steps? Where might friction be expected?
How does the user skip steps if they don’t want to complete them?
If they hit “skip” how far into the process does that take them?
If a user decides to exit out of creating their own account, what happens? How does the app respond to a guest?
Being a crucial initial piece of the puzzle to get right I started to investigate more of what other apps try to do to get people moving faster. I noticed that other apps get you through this faster by giving you the option to connect a different account to their service. All you had to do was sign into your Google, Facebook, or other account and you were 90% of the way done or fully done. I took the hint here as I didn’t want this to be hang up for anyone.
That likely alleviates onboarding/registration for most people, but what if someone didn’t have one of these other accounts? How do we get them to get through the app easily? The steps/questions asked had to feel somewhat predictable.
The proposed solution:
I thought the best answer here would be give the user as much agency as possible in navigating these flows. I didn’t want the app to force them along or not be clear about what was expected of them either. So I marked each screen with a clear goal with some basic text and buttons to get the point across. Wire framing the process of a brand new user making their own account from scratch. I ended up making quite a long process between intro and onboarding. It included entering your email, name, DOB, password, your interests, a photo, and a shipping address. I felt it might be a bit lengthy but decided to test it anyways as my first draft.
Did it work?
Not really, go figure. In testing this on friends and family, I got a really good question. “How do I know how much of this process is left?” You might imagine this to be confirmation on me making the process too long. You would be right, but also I realized this was a great opportunity to add a progress bar to each step. I also asked what felt like too much to do in the onboarding. The feedback I received was along the lines of “having to input basically everything after my password feels like I should use a different service.” Back to the drawing board.
Version 2:
In this iteration I included a progress bar with the step number and cut out everything after an email and a password besides interests and a profile photo. I did mark these as optional steps and gave the option to just continue like they weren’t there. I then retested. I got more completions of the process and less friction. People seemed happy with the progress bar and knowing they could just move past steps if they wanted to. This time I ran into a new problem though. Someone had decided they wanted to exit this whole process and just see the app and peruse. The exit button just brought them back to the login and create an account page with no way to fully exit it. Seeing this oversight led me to make an exit button in the progress header that would drop you straight into the app and I also added a skip button to the initial login prompt.
Our MVP before adding color and aesthetics:
I retested everyone on this process one last time and got the most completions and no hiccups. Heres what that looked like and also heres what the final version looks like as well.
Onboarding start to finish
Skipping through Onboarding
Checkout Flow
Problem 1: How to make the checkout process seamless for a brand new user
I started creating a rough iteration of the flow piece by piece and as I had finished up the general thought process I realized I may encounter some friction with how I had presented the flow. There was an immediate question of friction with payment and shipping for a brand new user. They would have no linked account to pull any information from. It felt to me that this would be a pain point and probably lose sales and users (if it was a real app). So how do we still skip this step for new users?
Proposed Solution: Linking your virtual wallet
Queue my lightbulb moment when I realized I never really pull out my credit card half the time when I go shopping for things in the real world because of Apple Pay. So what if we just add options like that to checkout? It would have all the information the app would need to complete and ship your order to you. The only thing I could think of was that if the user for some reason or another had not connected a virtual wallet to their device, they would still need to go through the process of inputting or autofilling that information one way or the other. This issue seemed unavoidable but the feature should still help lots of users all the same.
Version 1:
The first wireframe iteration of this did not include this as it was an immediate afterthought. So there’s not much to say here other than the process gets a little long with inputting information and it would be a genuine point of contention.
I should also note that with this being my first start to finish design project, I forgot to keep an iteration of these flows that occurs between me finalizing components for this part of the app and the next version you’re about to see. So while technically a version 3, I am calling it version 2 just to avoid any labeling confusion.
Version 2:
This includes the virtual wallet payment methods and also the option to add a credit card as well. I had the idea of showing a graphic of your type of credit card with just your name, 4 digits, and expiration visible on it. I had designed this flow as something where you could verify your payment and shipping first and then proceed to an order review. I realized after testing this on friends and family that it made no sense to have the virtual wallet options be on that first page because you didn’t get to review your order first before the virtual wallet would complete the purchase for you. This is due to them opening their own verification windows and completing those automatically completes the transaction
MVP and Final Version:
This one shifted the first screen post cart to be the order review and the second to be verifying your payment and shipping. The order review removed the shipping address and instead replaced it with shipping options. In revamping this part of the flow it became clearer how long it would take for an order to arrive and how you would be paying for it. I also decided in this version to make the credit card graphic smaller as it took up quite a bit of screen space initially. In considering the motion for this I opted for the standard Move In dynamic but I animated matching layers so that the headers had a clear effect to them to let you know you had entered a new page.
Shared Lists Flow
Problem: Making sure that a user could easily see who was invited to certain lists and what their access to them was
The first question after designing the lists page was “what would be the simplest way to share this with someone else?” I wanted to keep this theme of making things intuitive and easy to see/access. I sketched a few ideas from having it be directly inside of your lists in a settings tab to having a singular button next the lists header and you could choose which list you wanted to share to then just placing a share button next to each list.
Version 1:
The first sketch of having it be tucked away inside of list settings felt like it would take too many taps to get to and wasn’t particularly obvious. I was really looking for this to be as simple as possible and I wasn’t sold on this idea yet so I didn’t bring it into the wire frame stage. Here’s what that sketch looked like for the flow.
Version 2 and MVP:
Having a single button next to your list headers seemed like a decent upgrade over the last sketch. Now there would be less digging from the user to find this feature. It was front and center but in talking with others about the features placement and its icon, it seemed people were unsure if this meant they would be sharing all of their lists or not. I could see where the confusion was coming from so I iterated on this concept one step further by placing the share icon next to each list instead.
Placing the icon next to each list seemed to solve this problem of people being a little confused on what the button would actually do. Now it felt much more obvious that the feature both existed and that it was meant to share just the single list and not everything.
Final design:
After finalizing the look of the screen and making some subtle changes for aesthetics this is what I ended up with. Some headers were added to delineate between your lists and ones that have been shared. Keeping the share icon next to each list just like the previous iterations as well.
Problem 2: How does the user see who is invited to their list and what privileges they have?
This was a problem that I thought could be solved with a list recipients tab and the names of the people that you invited along the way. The questions was where should this tab exist within the list menu? The second question was how can I convey what access these recipients have as “at a glance” as possible. Everyone leads busy lives so quick and easy information was imperative.
Version 1:
I dove in to answer the first question. I figured that each list having its own settings would be an appropriate place to start. So within each list there’s a setting wheel that can be tapped to access a handful of simple settings. In here would be the list recipients. Now the name that gets displayed for each recipient would be directly tied to their account name and would be displayed as a list.
After that first version was done it was time to try and answer the second question. How easily can we make the access privileges be shown? I thought placing words next to every recipient would solve the problem - or at the very least get us closer to solving it. Words like “Can View” and “Edit.” This version would get shot down pretty fast after getting some feedback because the main point of contention was that if someone has a long first name it might get wedged near the access status. Then it becomes one long line of text essentially.
Version 1.5:
Version 2:
This version took me back to the drawing board for a few minutes. I realized that I could use icons to convey this to people instead and it would free up some space for those longer names. Tapping the icons would also toggle through the the two choices you had as well - editing and viewing. I grabbed some feedback and it seemed like friends and family were pretty sold on this design so it made its way to the final stages of design.
Final version:
With a more finalized look and feel to it this is what ended up being the final product for the lists flow. Below that is the animation interaction I mentioned
Flows, Animations, and Micro-interactions
Home Screen Navigation
Each time a nav bar item is selected it highlights itself, moves to the appropriate page, and deselects the previous nav bar item.
List Items Being Removed from List and Added to Cart
It was important that the user is essentially asked if they want to remove the items from the list once they’ve added them all to cart. This way they can have a clean slate in this list if they would like to use it again. In a similar prompting, the user is asked if they are sure they want to remove all the items in the list when they tap that button. In both instances once the items are removed from the list and they disappear from the screen, the “Remove All Items” button is replaced with an “Undo” button in the event the user made a mistake or changed their mind.
List Item Removal Animation
I incorporated the swipe to delete feature that is common amongst othe applications for ease of deletion for the user. This way there isn’t extra buttons or UI elements to clutter the screen or the list items. List items can be presented clearly and simply.
The interactions I want to highlight here are that the heart icon for saving something to your wishlist can be toggled. The versions of the product (hardcover, paperback, etc) can also be toggled. It lets you know what has been selected by highlighting in green. Finally is the micro-interaction of adding the book to cart. The button shifts the icon to the right, changes to green, and has an animated checkmark that spins before eventually animating back to the original button. Also you’ll notice the cart icon updates here as well. This all gives the effect that the easily tangible feedback to your actions within it. What you’ve selected and the feedback for it is obvious.
Product Search and Adding to Cart
Here the filters overlay opens via the icon next to the search bar. It indicates to the user that this is a different style of screen by moving in from the bottom of the screen. It also has an “X” icon to close it and various options for the user to interact with. Radio buttons and checkboxes are present for different types of options. Both animate to show if they have been selected or deselected. The overlay when it is closed will move opposite of its initial direction to show that it is being closed.
Search Filters
