Syndy — Product Hub

The heart of the Syndy-platform is its Product Hub. It is here were suppliers can manage all of the content for their products. From product information such as nutrients and allergens to digital assets like packshots and other media. Furtermore, the page provides real-time information about the status of a product per retailer. The challenge of this project was to simplify content management, making sure the user is in full control of their product information, together with providing critical feedback whenever needed. Please read the full details for this project in the case study.

The background

The Product Hub has been one of those pages on the platform that needed improvement for quite some time but got postponed everytime while quickly patching any discrepancies. First built in 2014, then extended over the course of the years to incorporate new features. For every new feature needed, we were confronted with a page that was not really flexible. This resulted in a page that had its fair share of problems with informaton architecture, interactions and technical aspects.

We planned to extend this page quite a bit with better management of digital assets, analytics, and feedback to suppliers coming in from connected retailers. It needed to be as flexible and modular as possible to support new features that were still yet in their conceptual phases. But before even going there, we had to do some proper research.

Screenshot of the new Product Hub
fig. 14
Screenshot of the old Product Edit Page
Product Edit Page 2014–2016


We knew that this page had its weak points and it was our wish to make it future-proof and more scalable. We also wanted more insights into how users interact with the page and started doing even more user research. Talking to people and seeing them interact with the product highlighted several other problems on the Product Hub.

During user interviews we tried to really get to the core of their problems. It happens often that some people will try to request features or make suggestions on how something needs work—specifically for them. You need to keep asking why they work in a certain why, or why they want a certain feature. This gave us invaluable information. Information which we think helped us in improving this particular page.


Together with the users we identified a plethora of problems for this page which needed adequate solutions.

  • In the previous design it was difficult for people to understand what was expected from them. There was a lack of information architecture.
  • The Media Library (digital assets) was detached from the rest of the product. When users wanted to manage assets for a specific product, they were led to a page which did not properly show its relation to the product. As there was no appropriate wayfinding, some users had difficulty finding their way back to the product page.
  • As the platform got more complex, we started to have trouble with fitting in new stuff on this page. Elements would sometimes be placed in whichever available empty spot for the time being, just to get a feature in. Something that was significantly reduced with the help of the Syndy Design System.
  • The statusbox was taking away horizontal screen real estate, making it difficult to fit all fields in a proper way. One of the fields we had trouble fitting in properly was the nutrients table. This is one of the more complex fields on the platform.
  • The nutrients table itself was one of the fields which users had some trouble with understanding. Both in terms of interaction and the underlying tech it was not something to be proud of. The flow was just not good enough.


As mentioned, this page is the heart of the platform and where most aspects come together in all their complexities. Users—suppliers—spend most of their time working here, and changes made at this level affect pretty much all related pages and data feeding out of the page. Together with the insights from the research, we identified a couple of key elements which needed to be solved.

  • User tasks and information
  • Layout
  • Template editing
  • Scalability

The next figure [fig. 01] helps illustrate how the main layout for the previous version of the Product Hub was constructed. A simple two-column layout that was sufficient in the early days, but became a reoccurring obstacle the more the platform matured.

Screenshot Product Edit Page Skeleton
fig. 01

01. User tasks and information

First we set out to fix problems that were the result of lack of clear distinction between editing and relevant information. In the previous version it was possible to edit data in both the profile section and the template section. Although all editable data was in fact part of one large set of related fields—a template—the decision was made back in 2014 to seperate three product identifying fields into the profile section and present the rest in the template section. Most users missed over the part that they could edit fields in the first part. And quite frankly, those input fields did not have any perceived affordances. You had to know that they were editable, or at least hover over them to see a hint of affordance [fig. 02].

Screenshot Product Edit Page field hover
fig. 02

We decided to reunite these three fields with the rest of the other fields in the template section and treat them as equals [fig. 03]. Now whenever users need to make any edits to product information, everything will be available for them at one place.

Though the editing capabilities were gone from the profile section, we did keep the information that was displayed in those fields namely product name, EAN (barcode), and the short description. It will become clear later why this decision was made. The same counts for actions the user can perform, either on the product itself by removing it from the platform, or by changing the content language.

The last item left in the profile section was the button leading to the Media Gallery. A button is not the right decision to lead users to a different page. The correct way to handle this should have been a link. Disregarding this for a moment, the action lead the users to a completely different page, one which was out of the context of the Prouct Hub. With no proper wayfinding users had difficulty finding their way back to the Product Hub. I will tell more about how we solved the Media Gallery when covering scalability.

Screenshot Product Edit Page Template Edit
fig. 03

Referring back to the figure of the page’s skeleton, you might remember that on the right-hand side there was what we called the Statusbox. It contained information such as completion scores, retailer assortment and a button to validate the product.

To make a long story short on validating a product; validation meant that suppliers had done their utmost best to ensure data was filled in correctly. Retailers could see this as a stamp of quality. If a product was not validated, its content was not sent to the retailers. But managing and maintaining a validation process like this is next to impossible with possibly thousands of products a supplier could have for their brands. The process hindered both suppliers and retailers to quickly get content pushed through our API into the retailers e-commerce websites. Instead of keeping this placebo button, we decided to remove it altogether. Now whenever a supplier changes any content for a product, those will be instantly pushed to the retailer.

Of course suppliers might still enter wrong content and we can not let this problem be unsolved. Knowing that most retailers have content teams working on checking every piece of data that comes in, we started experimenting with ways of letting retailers give feedback on all content coming from the supplier. Think of suggestions and error corrections flowing back to the suppliers.

In the statusbox—just as in the profile section—there was information left that was useful for the users; completion scores and retailer assortment, the latter which indicates if a retailer is actually selling a product on their e-commerce website. Combined with the product name, EAN (barcode) from the profile section this made up a good set of base statistics for the users to help in determining the state of a product.

02. Layout

On to the layout of the page, which started to become more feature-rich. Giving everything a proper place was giving us some headaches as the page proved to be rather inflexible. This page needed the necessary layout changes and realignments.

One of the main culprits was the Statusbox. This elements was hanging on the right-hand side of the page and was always visible, even when scrolling. It prevented the profile and templating sections to make full use of the container-width. For most elements this was not a problem. However there is a specific field in the template section that is quite complex and needs every possible space available—the Nutrients Table. This was one of the fields which users had some trouble with understanding. First time users felt intimidated when looking at the table. With just 850 pixels available to us horizontally, we needed to squeeze things in and place some elements in odd places in the table which did not make this field pleasant to work with.

Reasons enough to reconsider the layout of the page and remove the persistent statusbox from the right. As mentioned earlier, we decided to keep the product name, EAN (barcode), and the short description from the profile section. Combined with information from the Statusbox—completion scores and retailer assortment—we could create a better status section, and we think we did. The previous profile section and the statusbox—when merged together—became the Product Card which contained relevant statistics for the users at a glance [fig. 04]. Desctructive actions such as removing a product were safely put in a menu, but still quickly available when needed. And when people eventually scroll down, the product card changes to a statusbar at the top of the page while still giving relevant contextual information [fig. 05].

Screenshot of Product profile card
fig. 04
Screenshot of Product profile statusbar
fig. 05

03. Template editing

Each product on the Syndy platform is conntected to a combination of templates. These templates fall into three different classifications: a Syndy Basic template, a category template, and a retailer specific template.

Templates breakdown
fig. 06

All products have at least a Syndy Basic template. Such a template consists merely of a product name, EAN, brand, and a short description. We then give each product a category template. This identifies what type of product it is and presents the correct fields. Think of product categories such as food, beverages, home appliances, etc. With these categories Syndy is able to support any product one can think of. These category templates also make it possible to share data for a product between each retailer it is connected to. Changing it at one place immediately changes it in other places. By doing this the user can pretty much change content for one retailer and almost be finished for the others. The last template that a product can have is a retailer template. This template has retailer specific fields with which they may request extra content from a supplier.

The amount of fields presented to the user to be filled in depends on the category and retailer templates. Some products can contain upwards to 100 fields or more. Making this as convenient as possible to fill in proved to be a challenge. Looking at the previous version of the platform, you can already see that it was not a joy to work with it [fig. 07]. Because of the many lines, users had a harder time identifying to which field some elements belonged. On top of this, some field were updated through the years with a somewhat newer visual style, while others maintained the older style.

Screenshot of Template Editing (Old)
fig. 07

User feedback can be brutal but very valuable. And thanks to this feedback we had a concrete roadmap on what needed to be done to improve editing on this page. Some higlights from the improvements are:

  • More organised fields and adequate breathing room to aid in processing data and improve legibility.
  • Focused editing per field.
  • Consistency between fields.
  • A more consistent and usable nutrients table.

We did not try to come up with a completely new concept for filling in fields and forms. What we did was improve the ways this can be done and taking away annoyances users had. All these improvements helped in making this page a significantly better experience to work on.

By separating fields that are being edited and dimming inactive ones [fig. 08], there is more focus on entering correct content, without being distracted by other fields or other elements as the case was with the previous design.

Screenshot of product editing Nutrients table new version Nutrients table new version
fig. 08

A prototype is worth a thousand pictures. Throughout working on this page I made a lot of small prototypes to get an idea of what the interactions might feel like. It is a terrific way to quickly see if ideas are going to work or not. Prototyping helped tremendously in getting ideas over to developers and sometimes they could use the code immediately in production with just minor tweaks. Please try the small protoype below if you are interested.

Let's turn our focus to the Nutrients Table [fig. 09]. One of the page’s more complex fields which some users described as daunting. It was one of the parts of the platform which our Customer Success Team got the most questions about. Seeing it in isolation here, one might be fooled in thinking that it is not that bad. Fortunately we know better, and dedicated the time needed to improve the experience with this field.

Screenshot of the old Nutrients Table
fig. 09

This table will soon be covered in an upcoming case study dedicated solely to it. In a nutshell this is what we did to improve it:

  • A better first time experience, which guides the user step-by-step in filling in this table.
  • Takes advantage of the full-witdth of the page now that the statusbox has been removed, resulting in more space.
  • Conistency with the rest of the fields.

One other improvement worth mentioning here was the addition of a simple yet powerful feature; importing data. Thanks to the clever work of our great developers, when a user imports an Excel-file, we map this with the fields in the table and populate it with their data. We provide all suppliers with a pre-formatted document if they do not have one themselves. From there is it as simple as quickly filling in their data and import it into the table.

Nutrients table new version
fig. 10
Nutrients table new version
fig. 11

04. Scalability

The last element we needed to tackle was how scalable all of this was. How flexible is this page and would it be future-proof. We were overfilling the page with every information and interaction related to a product, which was not sustainable anymore. A solution was needed for this, but we could not afford to just quickly make something that needed a major overhaul again anytime soon. It took a lot of time, planning and experimenting to eventually find a solution for which we think will make this page flexible, and one that can stand the test of time.

In line with the Syndy Design System, we took on the modular thinking right from the start. A question that kept coming back was “What if everything is just a module, a plug-in so to speak?” The components in the design system are already modular, and we agreed to be building a system, not pages.

When talking about user tasks and information we were already separating the page into what is essential information for the users and what is editing of fields. We can drive this separation even further and consider that editing is in fact a module that is loaded into this page. It could for that sake also be loaded anywhere else on the platform where it would make sense, albeit in a slightly modified way.

I think this is true modular thinking. You have the building blocks to build anything imaginable.

Remember when I told that the Media Library was detached from the main page? What if we load it into this page, as a module and in context with the rest of the product information? Things started to fall more into their place. After modules for editing and digital assets, what more could we think of that can be loaded and is product related? Product analytics, product relationships, messaging on product level—e.g. direct feedback from retailers or co-workers. The list is exhaustive and the options almost limitless. Also, the name Product Hub started to make more sense.

And now for the million-dollar question; how? Tabs—simple, yet really effective—were our solution for plugging in bigger related features in a more modular way on the page [fig. 12]. For the Product Hub we are convinced that this is a structural solution that will help us solve most design related challenges for the years to come. Of course if overdone, we will eventually hit a limit. That is why it is important to stay critical and ask ourselves which modules should be implemented as tabs and which not.

Screenshot Product Hub tabs
fig. 12
Screenshot Product Hub tabs
fig. 13


The redesign of this page was a long journey in improving it for the users of the platform. Mainly for the suppliers for which it is the most used area of Syndy. But also for the retailers who will see a similar interface on their side with information and tools tailored specifically to them. All of this made possible in the way we rebuilt the Product Hub from the ground up.

It is now easier to add data to a product with a clear distinction between where to enter data and important live product information. The product information right there in front of the user in a product card and when they scroll, it will move along with them in a new statusbar. And to finish it off, the Product Hub is now truly future-proof by realigning it and making use of tabs to load in features as modules.

Screenshot of the new Product Hub
fig. 14
Screenshot of the new Product Hub
fig. 15