How might we allow Salsify to expand to new customer segments?

As Salsify brought in new retailer and customer segments to its network, the product struggled to display increasingly complex and diverse retailer requirements in a consumable and actionable way to users.

Nutritional data has historically been one of the most challenging example of complex data and the breaking point for our product due to its multi-level structure. Without the ability to support nutritional information, customers in the Consumer Packaged Goods category are blocked from selling products with nutritional information online.

What's Salsify?

Salsify is a Product Experience Management software that allows brands to manage their product information and publish data to retailer websites to sell their products online.

My role

I served as a product designer working across two global teams: Platform Channels and Retailer Connections. These teams were responsible for the area where users mapped and assessed a product's "readiness" for publish to a retailer website.

UX strategy

Advocated for design work to be included in this proof of concept.

Regularly presented UX progress to an executive audience

Research

Organized usability testing sessions with 5 users

Conducted follow-up user interviews

Defined and measured UX metrics

Design

Led a design workshop

Rapidly designed 2 clickable prototypes

Platform Channels team

Emalie Hermans, Product Manager

Chris Davies, Engineering Manager

Pattra Audcharevorakul, Front-End Lead

Tom Hulihan, Back-End Lead

Retail Connections team

Ashley Young, Product Manager

Carlos Fraga, Engineering Manager

Ana Santos, Back-End Lead

User problem

User problem

User problem

Users need a way to easily view, map, and publish nutritional labels to retailer websites.

Business goal

Business goal

Business goal

Salsify wants to expand its customer base in the Consumer Packaged Goods segment.

Technical constraints

Technical
constraint

Technical
constraint

Engineers need a way to enable data nesting in the data model powering how product information is sent from Salsify to retailer endpoints.

Design process

With multiple teams owning the underlying data structure, user interface, and varied retailer use cases, our challenge was to figure out how to align and work together to address the problem. We decided to embark on a 9-week sprint to explore, ideate, and implement a proof-of-concept solution. As a part of this investment, I advocated for and led a 1-week design sprint.

Despite the short timeline, I wanted to give my teammates a glimpse into a full design cycle. I chose activities that would help demonstrate the value of UX.

Day 01: Design workshop

I organized a design workshop to kick-off the week and align us on a direction for the prototype we would put in front of users for usability testing. The format of the workshop was inspired by The Design Sprint.

Expert talks and How Might We's

Expert talks and How Might We's

Two lead engineers, a product manager, and I gave short presentations or "Expert talks" during the beginning portion of the workshop. We shared context from the technical & user perspective and defined objectives & scope together.

During the presentations, workshop participants took notes in the form of "How might we…" questions, including:

HMW support flexible sets of nutrients?

HMW make it easier to publish multiple serving sizes?

Preparing for research

Given our goal to test an initial idea with users, we defined what we wanted to test and how we wanted to measure success.

We drafted user problem statements based on the needs of the primary user persona, Salsify implementation consultants who helps customers set-up their channels for the first-time

Research questions adapted from UX-lite to quantify user perception.

Crazy 8's, sketching, & voting on a direction

Using our objectives, shared context, and HMW questions, we rapidly iterated through an exercise called Crazy 8’s.

Participants chose one idea from their 8 sketches to expand on and present with the group.

During presentations, we discussed the pros and cons of each design and voted on a direction to test.

Day 02: Design iteration #1

Using the direction we voted on, I designed a clickable prototype intended for use in usability testing.

The first iteration included:

New structure to data was added in a collapsible area within a table row

Due to structuring data, table rows were significantly reduced from 112 nutrient-related rows to just 15!

A way for users to perform simple configurations directly on the table and only jump into a modal for advanced cases

A way for users to configure all panels per nutrient in context of the nutrient

Selected design direction

Resulting prototype

Day 03: Usability testing

I organized usability tests with 5 users who fit our primary persona. I gave users two tasks to complete in the prototype, asked open-ended questions to understand user expectation, and administered the research questionnaire we designed to quantify user perception.

I invited team members to observe testing sessions and take notes. My team saw first-hand some of the challenges users experienced. This was an amazing empathy-building activity.

Methodology

After setting up the scenario for usability testing, members of the working group took notes in a Rainbow Spreadsheet (pictured to the right) on their observations. We found this to be a great way of documenting and easily finding trends in the data we collected during testing.

Day 04: Design iteration #2

Applying learnings from usability testing

Users viewed the proposed solution as meeting their requirements, easier to use, and time-saving. Below are the top insights we derived from usability testing that directly informed the second iteration of designs:

Insight 1: The relationship between structured data wasn’t clear

Business goal

4 out of 4 participants experienced confusion around how the form inputs within a data row on the table of the proposed experience related to each other. 

We heard questions like, “How is it going to output? Is it going to concatenate value of calories with value of calories unit of measurement?” (Gareth) or comments like, “I’m a little confused on how some things are relating to the attribute itself.” (Immad, pointing to structured data within an data row).

Insight 2: Users wanted visibility into the mapping result

Business goal

4 out of 4 participants wanted to see the end result of their configurations and work alongside a visual. 

According to Lea, “I want to see the actual result, and not just the source of what I’m doing.” Immad mentioned, “if there was a way to add a preview to the design model on the table similar to how a formula editor preview works that would be wonderful.” Lea, Immad, and Sarah mentioned flipping between different views of the Channel for that purpose. Kyle even took a screenshot of an image of nutritional table that was shown to him as a part of the task to reference as he was mapping on the table.

It was extremely easy to pull insights from the rainbow spreadsheet; it was a matter of looking at the colored cells and selecting the ones that affected all participants in a significant way.

I'd recommend this method to anyone who want a lightweight way to quantify qualitative data.

How insight 1 and 2 informed design iteration 2

We believe insights 1 & 2 are related to the same root problem - to better understand how "structs," or the lowest-level pieces of data in the back-end model, are related to each other (which was a point of confusion in the first iteration of designs), users needed visibility into the end result of their mappings.

The second design iteration includes a preview of the nutritional table alongside the structs, which highlights exactly where a user is mapping in order to create more transparency between how someone’s mappings translate to the endpoint.

Before

After

Insight 3: The concept of structs (a back-end term)
was not understandable when displayed in the interface


Insight 3: The concept of structs (a back-end term)
was not understandable when displayed in the interface

4 out of 4 participants didn’t understand what a struct was.

While it’s not especially important that users understand this back-end concept, it is important they see some logic and value in the new organization of data as a result of the new data model.

The presentation of structs likely impacts how intuitive the relationship between data rows would be to users, as illustrated in the first insight.

How insight 3 informed design iteration 2

To address insight 3, I moved the new experience out of the constraints of the table and into a separate worksheet to allow for more flexibility in how we communicate the relationship between data in a more intuitive way without surfacing the back-end concepts to users.

I included a sidebar navigation in the worksheet to reinforce the high-level structure of data and give users a way to easily move through their configurations.

One reason we presented back-end concepts to users in our first iteration was to explain why certain pieces of data behaved differently from others. In this second iteration, I presented technical solution as valuable capabilities that allowed users to perform new actions such as naming, adding, and deleting while obscuring details that were less relevant.

Before

After

Final solution

This second and final iteration of designs included:

Obscuring back-end concepts and leveraging user friendly language to introduce these new changes in the Channel

Representing data in a worksheet component instead of sharing space on the table

Due to the new data structure, the number of table rows were reduced even more 1 row!

A nutritional table preview that addresses user needs around understanding how their configurations would translate to the retailer site

UX metrics

User problem

User problem

Usability increased by

33%

All users said the proposed experience met their requirements better than the current one. Their average rating of the proposed experience increased by 33% from the current experience, from 2.94 to 4.34 out of 5.

Ease of use increased by

41%

All users said the proposed experience was easier to use than the current one. Their average rating of the proposed experience increased by 41% from the current experience, from 2.34 to 4 out of 5.

Time saved

1h

All users said the proposed experience was faster to configure than the current one. On average, users estimated the proposed experience would save up to an hour’s worth of work.

Final thoughts

Usability problems, user perception, and technical issues have been long standing problems for the Channels product. Because ownership of the back-end data model, user interface, and retailer use cases was fragmented across several teams at Salsify, solving such a pervasive issue was extremely challenging. Our team was the first to experiment with the format of a time-constrained, focused proof-of-concept. We aimed to set a precedent for cross-team collaboration, agile methodology to learn quickly and understand the problem, and ideally bring us one step closer towards a solution that would address business, technical, and user needs.

As a working group, we had regular check-ins with members across the organization every week to present our progress and solution. I presented on our design process, research methodologies, findings, and design iterations. Through this transparency, we gained the trust of our leadership and visibility into the complexities of the problem space. We ultimately received buy-in for dedicated engineering and UX investment to make our proof-of-concept a reality for customers and users.

Next: How might we rapidly grow adoption of retailer channels?