Writing two sides of one transaction
By: Yael Ben-David
Tags: Case Study, Ux Writing, UX, Content Strategy, Fintech

Writing two sides of one transaction

Microcopy challenges and solutions for products serving diverse segments

We talk a lot about developing a strong voice and expressing it consistently; writing content that addresses our users’ pain and terminology that resonates and garners trust. But what’s a UX writer to do when we must connect with two very different audiences?

In fintech, this comes up a lot, because when a financial transaction happens, there are usually (at least) two sides involved. At Fundbox, we have a payments platform which is completely dependant on both buyers and sellers engaging with the same product.

Before I describe some of our challenges, methodologies, solutions, and how they can be applied to other products, I’ll explain real quick how our payments platform works. Otherwise, none of the examples will make any sense :)

The point of this product is to solve the “net terms problem”: Buyers can’t always pay for purchases up front — say they’re buying inventory for their store and might not have the cash to pay for the inventory until they sell it and turn a profit — they want net terms which means they order now and pay later. At the same time, the seller doesn’t want to manufacture the goods without getting paid first. That’s where Fundbox comes in — we pay the seller right when the purchase is made and the buyer pays us back later.

Challenge 1: Different segments have different pain

We need to address our users’ pain, but how do we craft cohesive messaging when user segments may have very different pain?

We discovered that our sellers don’t necessarily know the final price at the point of purchase. For example, say buyer Jimmie’s Hats orders 500 hats. Seller Hat Wholesalers doesn’t know how much the order will cost — they need to actually manufacture the hats and package them before they can calculate the final shipping costs. Hat Wholesalers needs to give a price up front while also leaving wiggle room to adjust later. So we created a feature that allows them to do just that. The seller can reserve a little extra of the buyer’s “Fundbox funds” so they are sure the money will be there if they need to adjust the price up at the end.

This created a problem for the buyer: No one wants to place an order for $1,000 and then be charged $1,150! Before Fundbox pays Hat Wholesalers, Jimmie’s Hats wants to know exactly how much they’re agreeing to pay Fundbox back.

The microcopy challenge was how to communicate that a) some of the buyer’s “Fundbox funds” are being reserved in addition to the order price; b) not to worry, this is the MAX that the seller can actually collect without additional confirmation; c) if the seller doesn’t end up needing to whole amount, the difference will be returned to the buyer’s account.

At the touch point where the buyer agrees to the amount Fundbox should send the seller, we solved for all of this pain using content design and microcopy. Content design-wise we made the “extra wiggle room amount” a separate line item to make it clear that this is not part of the price they were expecting the actual hats to cost. And in our microcopy we called it “Estimated shipping (15%)” — clear, concise, accurate, reassuring, and transparent. We also added a string further explaining what this extra amount is for and what will happen if the final adjustment ends up being more or less than this estimate.

BONUS CHALLENGE: Adjustments are not always for shipping

Turns out sellers in different verticals need to adjust for different reasons, it’s not always about shipping. So how do we rewrite this to be general enough to apply to all industries and yet specific enough that our users know what the heck we’re talking about?

We went through many iterations including many that used the word “overage”. Overage is indeed what we’re talking about here, but nobody says that so we weren’t about to start. In the end we went with “Reserved for adjustments (15%)” and we used shipping as an example in our explanation of what an adjustment might mean, instead of shipping being the only type of adjustment.

How did we do it?

Now you’re asking what was our process so that you can use it at home :)

First, research the offline flow. This need to adjust final prices and the pain each side feels exists in the world, offline, outside of Fundox. We investigated how it’s being handled today. Then we listened to the conversations about the flow that the buyers and sellers are already having. What language are they using? Next, we used that common context that the two segments already share as an anchor. It was a starting point. It was basically how we got to “estimated shipping”. But we weren’t done yet. We then had to workshop language based on that common context that was right for our product. The conversations we learned from were each industry-specific and our product isn’t. So we learned from our users as a springboard, and then adapted what we learned to our interface.

Challenge 2: Different segments use different terminology

Not only do buyers and sellers experience different pain that needs to be addressed within a single feature, they often use different terminology as well. We, on the other hand, need to choose a set of terms that work both buyer- and seller-facing.

Again, the first step here is to listen to how buyers and sellers are already talking to each other. Interestingly, we found that they use some common language that we never would have thought of. It’s like they have inside jokes that don’t make sense to us but we were not about to come up with our own terms that we felt were more intuitive to replace the words they’re already using. We followed their lead.

Again in this challenge, just listening to the words our users use and repeating them back to them was not enough. We used their words as a starting point and went from there.

We also looked at how our users are used to being spoken to. We did market research to understand how other products in our space are discussing these issues. What words are they using and why? Not because we want to copy their terms exactly but to give us ideas. They’ve already looked into words that make sense for our common audiences so why not leverage that? On the other hand, their product is their product and our product is our product. We used their terminology for inspiration instead of starting with a blank slate, but didn’t stop there. We tailored what we saw to our specific context.

An example of this came up in our “auth and cap” feature. You know how when you go to a hotel, they ask for your credit card up front to authorize funds? They don’t actually charge you any money, but they check that you have credit and may even hold some of it on the side in case they need to actually charge you (capture) later, when they inventory your minibar.

Our sellers are perfectly comfortable with “authorize” and “capture”. They do it all the time. Buyers on the other hand, weren’t quite sure about “capture” and it even sounded a bit scary. So what could we use instead that would still make us look professional, trustworthy, like we know what we’re talking about and like we are as sophisticated as our sellers, without losing out buyers along the way?

We went with “authorize” and “process payment”.

BONUS CHALLENGE: Sub-segments use different terminology

We felt pretty good about finding a term that worked for both buyers and sellers, until we realized that not all buyers and not all sellers speak exactly the same way. For example, this entire product is a net terms product and we discovered that not all sellers use the phrase “net terms”! How are we going to get them to sign up to accept payment with Fundbox if we can’t explain what it is?

Some sellers use “net terms”, others use “trade credit”, and still others insist they don’t offer net terms at all. They use “deposits”… which is essentially collecting a small percentage of the payment up front and the rest later, in other words, a slightly lower risk version of net terms.

In the end we decided to go with “net terms” but on the page where they sign up, also added: “Give your customers time to pay for their purchases while you get paid right away.” This explains clearly to anyone who doesn’t use “net terms” what it is, without over-explaining which would turn off the users who do use it.

How did we do it?

I’d recommend solving this challenge by first and foremost, pretending there is no real world and just focusing on accuracy. Ask yourself, in a vacuum where no words have any conventional nuance or preconceived notions attached to them, what is the most precise way to describe the thing you’re trying to describe? Make a list of your options.

Then, admit there is a real world and research whether any of your terms do carry some unintended meaning.

Take the terms you have left on your list and consider which make the most sense in the context of the flow you’re working on. The same way buttons are usually in second person because they’re the user’s opportunity to speak to the product, while checkboxes are in first person because they’re the user talking about themselves, here too think about the user’s headspace when they get to this string and that should help narrow down your terms further.

Speak to industry experts. Before I started working at Fundbox, I’d never heard of the term “authorize”. That doesn’t mean I shouldn’t use it. So part of the process was having conversations with people who had worked on payments at Amazon and PayPal and asking, “What does ‘authorize’ mean to you? In what context would you expect or not expect to see it used? Does it feel accurate and organic in the place I’m about to stick it?”

As always, us as many words as you need, or actually, as many words as your users need, to understand. For a number of these challenge, in general in complex products, and in all microcopy really, I do not believe in the holy grail of “concise”.

Challenge 3: There may not always be a one-size fits all solution

When you encounter the challenge of writing for two audiences at once, after you use all of the methods I’ve described above, there still may not be a solution. Sometimes you simply need to maintain two versions… or even more.

BONUS CHALLENGE: There may be more than two sides of the transaction

Remember our original flow that starts with the buyer ordering from the seller? Well sometimes we have a middle-person who orders on behalf of the buyer.

This middle-person will not encounter much of our flow, but will get stuck at the part where the buyer would ordinarily log into their Fundbox account, because it’s not the middle-person’s Fundbox account. Now we need that login page to make sense for a third party, too.

After an arduous process, with many considerations — like the “agent scenario” being the use case that brought the issue to our attention and the feature to life but the third party is not actually always an agent — we arrived at “Ordering for someone else? Ask them to approve this payment method”.

Our Help Center is an extreme example of needing to accommodate multiple audiences in one place. We considered maintaining multiple versions. But this would require engineering resources that we didn’t think were worth it considering we had a much cheaper copy solution we could go with.

Our Help Center is where sellers go to get answers. And buyers go to get answers. And people who use or are thinking about using the rest of Fundbox’s product, oh my!

We solved this first, by grouping FAQs by audience and giving the groups clear section titles that should right of the bat help each user find navigate to the right place for them.

In case they clicked on the wrong question anyway, we start almost every article with a string in a larger font than the rest of the answers briefly explaining that Fundbox has multiple products and this particular article is relevant for [segment].

How did we do it?

The first thing to do is to inventory resources. Are you going to maintain multiple version or not? What would it cost and is it worth it? Is there a copy alternative?

Then, draw the right users in quickly to where they need to go, like we did with section title. And last, get the wrong users out quickly and back on their way if they land in the wrong place like we did with that opening “disclaimer” at the top of each article.

Two more tips

In addition to all of the “How to’s” sprinkled above, I want to add two more techniques that help me a lot.

The first is to workshop with Product. There is a lot of talk about how important it is to workshop with marketing, that they are also language people and that they know our users and potential users from a different perspective. They know what bits of our product are selling and which less so and have a lot of valuable insight to offer. But don’t forget about Product. Product spec’ed out the feature in the first place. They know best exactly what they are trying to do and you need that deep understanding of the thing you are describing before you describe it.

And last but so-very-much-not-least, collaborate with your user-facing teams. Sales and Support are exposed every day to the users who don’t get it, they users you’ve failed. Understand from how user-facing teams clear up the confusion to preempt the confusion in-product.

This blog post is a summary of a talk I gave to 150+ UX writers at a meetup in Tel Aviv in January 2020.

The gorgeous audience