Using Twitter and Slack to bring the voice of the users to the organization

I’ve worked in small and large organisations. I’ve been part of a centralised team of designers, worked embedded in a product team and also been the only designer of any kind in a large business.

Some organisations fully embrace user-centred design, with every member of the team, regardless of job title, feeling ownership of the users’ experience. Perhaps more commonly, a designer’s job is to advocate for users in companies where there is some kind of disconnect between the business and its customers. Put simply, to be the voice of the user.

Even the most user-centred organisation can become immune to or disconnected from users’ problems. Messages sent through support channels may not be getting to the right people, stories get boiled down to a single bug report without context, individuals can feel of helpless or unable to act, the quantity of feedback can be overwhelming or simply that too much knowledge can skew what you believe to be an actual issue, putting something down to “user error”.

How this started

I was working in an organisation where the feedback loop was relatively closed. The product team understood quantitative data. They kept an eye on completion rates and defined success metrics for certain flows, but as a designer this didn’t tell me much about the genuine experience of an individual or their feelings towards the product as a whole.

If a user needs to perform a task and has no alternative they will often find a way to complete it. But completion rates don’t tell you anything about how they felt and what they had been through to get there.

While we conducted usability research for brand new things, the only people that spoke to real users on a regular basis were the customer support team. They were located in the another office and were rightfully more concerned about dealing with the user issue in hand, than giving detailed reports to the product team.

Dealing with user issues isn’t clear cut. It’s not always obvious what the root cause of the problem is and as relationships between customer service and product are often fraught with tension, it can be unclear to support staff what a product team would actually want to be told about or if they would do anything about it if they were.

These support tickets were dealt with using a matrix of common issues recorded over time, categorised and put into a top line monthly report. The product team would hear “There has been a 10% increase in contact relating to resetting passwords this quarter”, at which point the real life context and impact of these problems was lost.

My first Twitter search

After launching a fairly major redesign of part of a website I was working on, I was curious to know if anyone had mentioned it online. So I searched Twitter.

This took me down a deep, deep rabbit hole. I had collected more human stories about our product in a few hours than I had in several months before that. The type of information I was finding was not really on anyone’s radar.

Searching for sentiment

Most support is reactive, for example a user Tweets, “Hey @company, I have a problem”, this Tweet creates a ticket and this ticket is dealt with by a member of the support team.

Being proactive about finding issues is very different. Rather than searching for mentions like “Hey @company, I have a problem”, I started looking for tweets with the sentiment “I used (company name) and this happened to me”. Thoughts broadcasted to networks, not formed into direct requests for help, but capturing the general feeling of what it was like to use our product.

What started as a search about a simple user flow, I ended up finding something much darker: patterns highlighting the harassment of a group of users on our platform. I recorded and documented these Tweets and distributed them to the product and customer support team. We were able to make small changes that would reduce the possibility of this happening in the future, not to mention putting these real-life stories front of mind when prioritising work on our roadmap.

After searching the Twitter history, backdated to about 6 months, I was able to pull out common issues and language, create a series of search terms that would allow me to check issues over time.

I started a document which contained 10–20 terms that I would search every morning before I started my “normal” working day. This list grew significantly and at this point I was just recording these issues in keynote decks and sharing them when it seemed appropriate.

After about 6 months I created a Slack channel called ‘#voice-of-the-users’ to broadcast these issues to the whole of the organisation. Since leaving that company I have set up exactly the same thing in my current role and plan to continue if move on in the future.

What to search for

When searching Twitter for issues with your product or service it’s important to consider a few things:

• How many users have you got?
• How many results do you get from basic searches of the product or company name?
• How many interactions are there with the official Twitter account?
• If you’re in a competitive marketplace, how users speak about competitors in relation to you?

If you only get a few mentions a day it’s not worth you setting up more than a few basic search terms. Twitter has a number of search operators that will help you target specific ways words and accounts are mentioned.

For example if you worked for “Acme Inc” you would only need to set up search terms for:

@acme_inc (Tweets that mention @acme_inc)
to:acme_inc (Tweets that are directed to @acme_inc)
“acme inc” (Tweets that contain “acme inc”, not “acme” or “inc”)
acme + inc (Tweets that contain “acme” and “inc” but not together)

If you have hundreds, or thousands of interactions a day you will need to set up multiple search terms to catch mentions of specific things you’re interested in hearing about.

I currently have 80+ search terms set up and I use TweetDeck to manage them. If you have this many, it’s certainly more efficient than doing manual searches every morning.

Limiting the flow

A few of the search terms I monitor have a continuous flow of interactions, most of which are not relevant to user related issues. In this case I use negative search operators (putting a minus before the word or group of words you want to exclude) to remove tweets that mention certain things. For example if I wanted to see all tweets to “acme_inc” but cut out the ones that mention “road runner” I would use the search term to:acme_inc -“road runner”.

Learning your users’ language

Once you have been monitoring basic company or product search terms for a few hours, weeks or months it becomes easier to spot patterns in both users’ language and the way they communicate about specific situations.

Some basic negative language I’ve included in searches to capture common issues are words like ‘can’t’, “down”, “broken” and “isn’t”. These will result in finding tweets like “I can’t upload a photo”, “Is your site down?”, “This form is broken” and “The call centre isn’t picking up”.

Setting up temporary searches

From searching broad terms, you will often find something very specific that needs further attention. For example, if you find users reporting a bug and quoting a particular error message it’s useful to set up a new search term for that message such as, to:acme_inc “Record not found”. This will allow you to understand how many users this is happening to, how long it’s been happening for and by keeping the search term saved, when it stops happening. After the numbers drop, you can delete this search.

Images can tell a story as much as words

When something happens to a user on your product they don’t always mention the problem using words, they often share an screenshot accompanied by a statement, for example “WTF @acme_inc”.

To someone with deep knowledge of the product these screenshots can tell a real story. I use a combination of search operators to capture tweets containing images. For example, “to:acme_inc filter:media” will reveal results that are directly @‘ing the Twitter account and contain an image or video.

Depending on the frequency of tweets you receive you can use combinations to merge similar searches into one, so “acme inc” OR @acme_inc filter:media will give you tweets that contain images or videos that mention @acme_inc explicitly or the words “acme inc” next to each other.

A real life example

As a quick example, I made some initial broad searches for users mentioning “coca cola”. I saw one person say they’d mistakenly bought a coke zero due to the current label design. This immediately resonated with me as I have done the very same thing.

I adapted my search to “coca cola” OR coke label and caught a few mentions about this, but there was also a lot of mentions about coke labels generally.

After finding a few examples of what I was looking for I noticed users expressing the sentiment “I didn’t realise” in a few Tweets. I adapted my search term to not mention the label at all and focus on this common language “coca cola” OR coke zero realise OR realize. We’re interested in knowing if people were mistakenly buying the wrong type of coke, rather than pointing out issues with the label design specifically.

Here’s a few screenshots of what I found using that search term:

Things to bear in mind

When broadcasting these messages within an organisation you should always be aware that your colleagues may have designed or implemented the thing that the user is talking about. Be sensitive to this when you post.

You should also include messages with a positive sentiment. The way most users interact with brands or organisations on social media is not particularly positive, if something “just works” it’s not normally considered a topic of conversation unless it’s unexpected. Positive messages can help tone down the channel, restore some balance and be there to represent the users that have had a good experience.

Something I’ve often failed at is making the intent of these channels clear. In some scenarios you will want to use a feed to simply connect a disconnected team with real users. In this instance, integrating a rolling Twitter feed into Slack may be enough.

Over time you will find things that need to be dealt with. In my experience of doing this for the past 4–5 years, users often flag up issues before product teams know about them. If you decide to maintain a channel like this you will have to make decisions on what to do with this type of content on a case-by-case basis.

I tend to only post potential bugs if I see the same thing more than 2–3 times in a short period of time or 10–20 times across a long period of time. I contact teams directly depending on the severity of an issue, I post examples of where users have been confused by an interface to contribute to long term research of our design patterns rather than an isolated incident to be dealt with.

In short, the reason for sharing this information isn’t always the same, but you should try and be clear why you are posting something and if you’re asking anyone to act on it.

If you think this might be useful in your organisation and you have any questions, feel free to drop me a line.