← Work

Artsy Payments

• Company: Artsy

• Platforms: Web, Email

• Year: 2017

• Role: Principle Product Designer, Partner Applications

• Project Team: 1 Product Designer, 1 Product Manager

Testing a hypothesis

At Artsy, I owned design for partner facing products and services. My most consequential project was to lead user research and design for Artsy’s first integrated payments offering.

Most art galleries are willing to take credit cards to process payments, but as small businesses they often aren't equipped to confidently accept credit card payments online. Originally imagined as a standalone invoicing feature, Artsy had trouble getting feature adoption because our invoicing feature didn't meet all of the stringent requirements that galleries have for paper based invoicing.

With the goal of increasing the amount of trackable transactions through the platform, I conducted dozens of user research sessions with customers to understand how they saw our nascent invoicing feature and how they receive payments today. This research led our team to a new strategy for how the feature should function and a new approach for how the feature should be marketed.

We repositioned the invoicing feature as simply requesting payments, aligning our functionality closer to services like Venmo or Square Cash. We also integrated the feature directly into Artsy's communications feature so that galleries would be more likely to start using the feature.

Conducting research

My research process began by trying to understand how the invoicing feature had originally been conceived by the team at Artsy. I worked with the engineering lead and the product management lead to understand what the data structures looked like and how they had considered integrating the functionality into the Artsy CMS application. Their approach was for invoicing to be a standalone feature and to essentially be an interface for the Stripe APIs. Due to this, customers would need to adopt the invoice feature on their own and depart from how they do business today. For art collectors, adoption would be somewhat less unintuitive because they would’ve begun working with the gallery through Artsy. But it would still be detached from the original email thread that they would be having with the gallery.

I put together user testing scripts which would ask the gallery staff member to use the Artsy CMS application in a way that they normally would, create a payment invoice for an art collector, attach the artwork that was being purchased, set its price, and send to the collector. The staff member would then get a response from the art collector and would proceed to complete the sale. I used these interviews as opportunities to not just test the interface but to understand the value that the feature might bring to the gallery. We were also able to get insight into how they viewed invoicing in general.

What became clear through the research process was that using a credit card payment system like Stripe was really only going to cover a small percentage of art sales. In reality, art collectors typically would pay with checks, or with other means of payment, because the value of artwork can be quite high. So to pay with a credit card could end up meaning a large additional fee for either the gallery or the art collector. Artwork is also not purchased in a rapid way, so taking the time to use a checkbook is typically not a big deal.

There were also adoption issues. Art galleries collect the payment all the time without major issue, and there wasn’t a requirement to use Artsy’s system even if the lead came from Artsy.

Imagining an integrated system

To help the team understand the outcomes of the user research that I conducted, I put together a presentation outlining the different types of feedback we received, how to think about different types of feedback, how it could be integrated into our process, and ultimately what my core recommendations were for how to update the invoice feature.

I proposed that the invoice feature should be integrated into the chat and messaging functionality that already existed in the Artsy CMS application. I also proposed that the invoicing feature should support use cases beyond credit card transactions. Instead it should be agnostic to payment method and credit card transactions should be one of many options. It was likely that being able to generate an invoice document that simply requested the art collector was a more appropriate way of handling payment in the art world.

Working closely with the engineering team, I put together designs and flows that demonstrated the new functionality. These were reviewed across the company and included the gallery partnerships team who work closely with galleries day-to-day. While the designs worked for the web, it’s important to note that email was a critical piece of this feature. So, in some ways, this was a web and email product.

Polishing a new experience

As we continued to develop the designs, I returned to some of the galleries that we had spoken with before. I went through another round of usability testing to confirm (and continue iterating on) the designs to make sure that we continued to stay aligned with what would provide the most amount of value.

The Artsy payments feature was the first time that real monetary transactions were possible on the Artsy platform. It allowed Artsy to not only provide more value to customers, but also to better understand the value of the company itself since being a marketplace hinges on the idea that it can actually handle real transactions. This would eventually allow Artsy to take a percentage of each sale which was the expectation of many of the company’s investors for the long-term of Artsy‘s business.

Architizer Source →