Adding a Return Address
Ink Cards App
Ink Cards is an app used to mail physical greeting cards to people. Customers choose a card design, personalize it using their pictures and writing a message, and we mail the card for them. Up until November 2017, customers sending a card did not have a way to include a return address with their card.
Customers have been requesting that we add return addressing to our cards since 2016. From our customer support tickets and survey feedback, we heard multiple times that the cards they sent were thrown away because the recipient thought it was junk mail.
Make it quick and easy for customers to add a return address.
Lead designer responsible for user testing, UX/UI, prototyping
Me, 1 iOS dev, 1 Android dev, 1 backend dev
September - November 2017
Understanding and defining the problem
After talking with some of the engineers, I found out that long before I joined the company, we used to ask customers for their address but stopped a few years ago. Therefore, we already had some existing customer addresses in our database, but reusing and resurfacing this data in the app in the form of a return address could be confusing to customers. We discussed the pros and cons of reusing addresses or creating a brand new field, and after finding out that 34% of our customers had an address tied to their account, we decided to reuse the old field. Now, I had to figure out how to make it easy for our customers who had a saved address to include it in their order or update it.
Talking to the engineers gave me more questions to think through in my design process:
What happens if a customer wants to change their return address?
What if a customer doesn’t always want to use their return address? What if they do?
What if customers never want to add a return address?
With these considerations in mind, how might we create an experience that gives control to customers who want to add a return address and eliminates unnecessary steps for customers who don’t?
Before thinking about the design requirements, I thought about the different scenarios our customers might be in when using the app and the functionality they would need to achieve their goals. Based on the motivations and outcomes I identified, I was able to more clearly define the scope of the return address feature with the engineers.
Design requirements for our customers’ ideal outcomes
We needed the following functionality to create the best return address experience for all customers:
Make it feel optional so that customers who don’t want to add a return address don’t have to go through extra taps or screens to send a card
Make it easy for customers to add and remove their return address to an order
Make it easy for customers to change their return address for future orders
Make it easy for customers to fix their return address for recently placed orders if they discover an error
How might we allow customers to add a return address to their order?
I first explored how and when we’d ask customers to add their return address. Customers needed a way to add a return address to two different types of cards we offer—a postcard that is mailed without an envelope and a flat card that is mailed in an envelope. One of my early ideas was to allow customers to add a return address in the card creation process because it felt more natural to the way people write letters in the real world—they write their letter, put it in an envelope, write the recipient address on the envelope, then write their return address in the upper left corner.
I thought about placing a button to add a return address on the card itself where the return address would be so that customers didn’t have to go through an extra screen. This, however, only worked easily for postcards. For flat cards mailed in an envelope, we only partially show the back of the envelope behind the card. In order to implement this for our flat cards, we’d have to somehow show more of the envelope and add a button to it. In one of my iterations, customers would have to tap the part of the envelope already showing in the app to see the front of the envelope—this didn’t sound like an easily discoverable feature.
I iterated on the version above by adding a more visible button for return address above the Add Recipients button instead of on the postcard/envelope. Although this iteration was in line with the visual experience of the version above, it introduced an extra screen for customers to go through before getting to the shopping cart. Since most people only have one return address that didn’t change very often, I didn’t want them to go through this extra screen every time they ordered a card.
I also thought about grouping the actions of adding recipients and return address on one screen, but this would’ve created even more steps for customers who did not want to add a return address.
Forcing customers to see the return address form was another solution I explored, but I decided against this because adding a return address might feel required even though they could tap the Skip button in the upper right.
Since return address was going to be an optional feature, I thought that the simplest way we could implement it would be to add the option to the Order Summary screen—our version of the shopping cart. It would be easy for the developers to add a new section for return address, and it would feel more optional than adding it to the card creation process.
Getting feedback on prototypes
After exploring way more solutions than I showed above, I created two prototypes—one where the return address step is part of the card creation process (version 2 above) and one where the return address step is on the Order Summary screen (version 5 above).
I conducted a remote usability test with 10 people who had never used the Ink app before to see if they struggled to add a return address using the two prototypes. While all 10 users thought it was very easy to add a return address using both prototypes, 6/10 users preferred adding it in the card creation process because the button was more visible, and the experience felt more intuitive.
I also tested the prototypes with 8 people in the office and asked which one they preferred and why. While some preferred adding a return address in the card creation process because it was more visual and intuitive, more people preferred adding a return address at order summary because it felt less forced and less intrusive to the current card creation process.
Hearing from real customers
Because new users in the usability test preferred one option, and my colleagues in the office preferred the other, I wanted to collect more data. I sent a survey to Ink customers and found that 44% of users either did not want to add a return address or did not care. With this in mind, we decided as a team to add the return address feature on the Order Summary screen—it would be a simple change for existing customers that wouldn’t negatively impact earlier parts of the funnel; it would feel more optional for all customers; and it would be easier to implement for the engineers.
Final solution for adding a return address
The final solution for adding a return address only changed the existing experience after a customer got to the shopping cart.
How might we allow customers to update their return address after placing an order?
Since people make typos all the time, we knew we had to make it easy for our customers to update their return address after placing an order. I talked to the engineers about the design requirements for this functionality and learned that customers place a lot of orders around the holidays. Thus, we needed to make it easy for them to update their return address on previous orders in case they made a mistake on all of them. We also needed to make it easy for them to update the return address tied to their account so that future orders wouldn’t have the same mistake.
Since customers can update an order by going to the order detail screen, I added the ability to update the return address as another item on the update order action sheet. When they update their return address on one order, they also have the option to update their return address on future orders and orders that have not been printed and shipped.
How might we give customers control over adding their return address on future orders?
Once a customer places an order with a return address, the address is saved to their account and added to future orders by default; if they don’t want to add a return address to their next order, they can just toggle it off.
Implementing the return address feature
During the implementation of this feature, I worked closely with the iOS, Android, and backend developers to make sure we showed customers the correct return address form and return address update dialogue in different scenarios. Learning about how order information was sent and retrieved on the backend helped me decide when loading and success messages appeared and when the return address update dialogue should be displayed.
Once the developers completed the changes, I reviewed test builds to make sure everything worked as designed. We also had other people in the office use the test builds in order to identify bugs and usability issues with adding and updating a return address.
After we launched the feature. I ran a remote, unmoderated usability test with 4 users new to Ink Cards on iPhone and 4 participants on iPad to identify any issues with adding a return address and did not observe any issues.
Within two weeks of launching return address, 33% of orders included a return address. Overtime, the percentage of unique users who add a return address has remained steady at about 33-36%.
With this project, I learned that it’s important to balance the needs of new customers and existing customers when designing a new feature, especially since a new feature could make the app more complicated for existing users. I also learned to be more mindful of how features affect the returning user experience. If I had introduced the return address feature during the card creation process, I would’ve made customers who didn’t want to add or change their return address go through an extra screen every time they wanted to buy a card, which was unnecessary.
Working closely with the developers before and during implementation and sitting in on technical meetings about how the client and backend communicate helped me understand both the app and our customers better, which helped me make better design decisions.
If I were to do things differently, I would explore and test more ways to add the return address feature in the card creation process that would not make customers go through an additional screen. I might design one experience for the launch of the return address feature so that all customers are aware that it exists, and then design a different experience for the subsequent times a customer uses the app that doesn’t make them go through an additional screen.