From Feature Soup to Auto Replies

String is a text messaging tool for professionals that send a high volume of messages. Think of it like an email client for text messages.

As our product became more mature, it started to feel like feature soup. This meant that our customers were having a hard time distinguishing one feature from another and remembering what did what.

This case study outlines how I identified this problem, explored potential solutions, implemented changes, and tracked their impact.

Our customers ran their businesses from their phones. Every unanswered text could be a lost client, so the stakes of a messy inbox were high. Here’s who they were, what they struggled with, and how String helped.

The “Pro-sumer” (professional consumer).

• Generally running their own business, and has deep, personal relationships with their clients.
• Individuals who are in charge of their own “Stack” - they choose what technology to use, and are usually very discerning with the tools they implement.
• Text messaging is a large part of their business
• Often texting from their personal phone so they can always be within reach
• Mostly iPhone users

Our users provide their clients accessibility by communicating via SMS, but current messaging services leave users in fear that they are drowning in messages and about to drop the ball on important relationships.

When a user signs up for String, they first choose a new number, this becomes their new work number. Messages and calls to and from that number are managed in our app, leaving their personal phone number to be just that - personal.

Then on top of that base we built a host of features, built with the intention of making it easier to initiate high volumes of conversations, organize those conversations to fit any workflow, and step away from the phone with confidence that you’re not dropping the ball.

The best analog for the String product is an email client for text messages. Below is a list of some of our features, with their closest email parallel.

Plus more organization and automation features

• List view - view your messages laid out like a Trello board
• Keyword responses - Automated responses to specific inbound texts
• Mark unread - easily flag messages to come back to
• Unlimited calling and voicemail

Below are our most heavily used features explained in more detail. Our users implement them in order to automate some of their responses.

And herein lies the problem. These features are hard to differentiate, especially to new users.

Without dedicated time or money to conduct formal user research studies, I searched for other ways to get information directly from our users. I created a process I dubbed as “passive research.” I took over customer-facing activities that were already happening from on-boarding calls to help center emails.

Onboarding calls

We were at a stage in our growth where we onboarded every customer we let into the product - Superhuman style. It allowed us to gate who was accessing the product, build a wait list, and most importantly - our data showed that hand-onboarded customers were 3x less likely to churn in the first 3 months.

I offered to start conducting these calls since I wanted to understand how people thought about our features, and find the most useful mental model to describe each one. In response to customer’s reactions during more than 100 onboards, the way that I described particular features evolved as I found what resonated with the most people.

Customer service email

I also took over the role of first responder to customer service emails, allowing me to see first hand the issues that customers were writing to us about.

Admittedly, most of the emails were concerning bugs, but there were also some very illuminating messages that exposed the difficulty our users had grokking our features. I’ll get deeper into exactly what these issues were in the next section.

As I have alluded to above, I found that our users had a hard time understanding the differences between some of our features. First time users especially had a hard time understanding what actions would trigger which Boosts. The comments I gathered from users fell into three main buckets:

1. Too many features - intimidating
2. Many features seemed to have similar function which made it hard to keep them straight
3. Their names are slightly obscure.

I would hear things like this from customers…

There was the most confusion around Away Messages, Missed Call Responses, and Keyword Responses. It was clear that we needed to redesign how we presented these so that our customers could properly understand their function and set them up with confidence.

Here is my obligatory “UX is messy” process shot.

In order to find the right solution, I knew we had to explore a few options. Below are 3 of the many concepts we explored before ultimately deciding on one. (Spoiler alert: it ended up being a bit of a hybrid)

First, here is the home page of the app after a recent visual overhaul. You can see that the “Boosts” live under the inbox header and name on the left of the screen. Shown below are the three states of the left nav.

If a user clicks on “Auto Replies” in the left nav, they are brought to this screen, which now is home to three different flavors of Auto Reply. You can see that in the second column there is permanent space for a description of each feature to help a user choose the right Boost.

Below are the “Create New” screens for each of the Auto Replies. You can see that we adopted a mad lib style which spells out the function of each feature in plain English with some empty slots for the user to fill out.

To the great disappointment of myself as well as our hundreds of paying customers, String.ai was forced to close its doors after last-minute funding fell through. Because of that, I wasn’t able to carry out the tracking plan I had devised for the new release of the product.

I had designed a system for tracking the performance of this new layout that included both qualitative and quantitative metrics that went as follows:

I also wanted to understand if the new architecture (nesting these features under the title “Auto Reply”) helped users understand exactly what the features did.

Using UserTesting.com I was going to craft a study where I said something along the lines of, “Pretend you are a real estate agent and you have your phone number on a billboard. You have a standard response that you send to all inbound text messages from numbers you don’t know. Can you find a way to automate that process with this tool?” I would then have 1/2 of the users complete the task on the old build, and 1/2 on the new build and compare the time to completion as well as qualitative report on their commentary through the process.

If you’ve made it all the way down here, I commend you.

Contact me to talk more.