DATAFEEDWATCH:
Visibility of system status

DATAFEEDWATCH:
Visibility of system status

DataFeedWatch by Cart.com is a tool that helps e-commerce owners and big marketing agencies manage and optimise all product data and advertise the right products the right time and in the right way on platforms such as Google Ads, Pinterest, Instagram, etc.

This project was about clearly communicating the system status to clients, but also internal stakeholders such as the Support team. This one wasn't so much based on solving new user problems – but it was very clearly related to prior signals from Support, and the heuristic called "Visibility of system status".

I'll use this one as an opportunity to show you the process I established for managing and creating product copy.

OPPORTUNITY

As the main app's page is moved to a newer frontend technology, a chance appeared on the horizon to simplify that page just a bit. At the same time, it was also clearly stated that no big changes were to be implemented, only the ones that will make the very development easier.

One thing we, as the designers on the team, wanted to smuggle was a clearer distinction that we are talking here about the list of shops, as we have in the App a few similar views.

In this project, those were my main goals:

  • Limit the number of options to eliminate ambiguity of statuses and descriptions

  • In case of errors, clearly show the way out of the situation

  • Rethink information architecture of options in the dropdown menu

  • Apply the Voice and Tone to the new content

Being part of the product team working on this, I had a chance to talk to all the stakeholders and propose things that are based well on feasibility and technical limitations on one hand, and in the context of proposed solutions on the other.

STYLE GUIDE AND PROCESS

Taking a step back, at DataFeedWatch, I proposed completely new Voice and Tone. Previously the language was very heavy and formal.

Taking into account rather young audience and importance (for them) of delivering the message with whatever means, I recommended the following tones to it:

  • Informative

  • Enthusiastic and Friendly

  • Confident

This gave us a lot more confidence in delivering the information required. Of course, intensity tones would be considered on case by case basis, to adjust to real user situations.

The tool to work on the conciseness of information and detecting the tone, was a combination of Hemingwayapp.com (fog index) and Grammarly (punctuation and tone detection). Quite powerful duo!

COPY DOCS

I came across the concept of Copy Docs and it helped work on product copy in a collaborative way, sharing the copy and consulting it first in Google Docs format, later it evolved and moved to Notion.

Copy Docs would usually have:

  • Initial content, "protocopy"

  • Final copy

  • Explorations

To involve stakeholders early in the decision-making, I would create 1-3 versions of each piece, and allow people to discuss and vote on their favourites or justify why some option shouldn't be chosen.

RESULTS

As a result, we could observe fewer Support tickets relating to configuration, and clear indication of next steps both for the users to follow independently, and also for the Support team to be able to better help users.

More resources: