@Kirsten happy to call them labels, it’d take me a while to update the prototypes or we can just describe this name change in the dev issue.
@Rachel I believe the intention was for BO users to be able to assign their own tags/labels to products so they can better search and filter their product list. This is arguably, the biggest ‘new’ aspect of UI uplift.
I assume this was decided due to Mario’s original discovery work and there’s rationale for it but I don’t have the discovery history documents easily to hand.
I certainly see how it can be useful once it’s fully integrated with other tagging systems and this ‘first part’ is a good ‘brining tagging to the product list’ idea but in my opinion, it needs to be a system wide tagging function before it can be super useful. But flagging my pov is not the main thing here, Mario would have had rationale and research to back this design choice up.
I would say that adding a tag/label to give me the ability to organize/filter my own products is the primary rationale behind the uplift phase 1 - is it not? We know that users have moved products to inventory now, because of the ability to ‘hide’ items there for example. We want to shift people away from using inventory if they don’t need to be using it. So this means they need an ability to organize their products. Typically - I think for many producers - this will be by seasons. I have 50 products I only need to see/sell in May. Then I can filter them out, and just bring into focus my June products…
And I agree we shouldn’t call these ‘tags’ to avoid confusion with our other ‘tags’ that have power/agency. In this case, a tag = a self-created label, useful only for the product list owner - is that right?
The importance of the tags/labels is that a major point of this exercise as a step to Network 2.0 is that we want to retire Inventory. To do so, we need to move the functionality of Inventory out of Inventory (feature parrot / parity :).
The first use case that we are moving out of Inventory is the one where people use it purely so that they can control which products they see or don’t see i.e. ‘hiding’ or only adding the ones that are actually active.
So what we are tracking in this phase is whether we can reduce variants in Inventory that have neither stock nor price overwritten - as this suggests that Inventory is being used purely for list management
The labels and ability to hide products/variants on the Product page are therefore necessary to conduct this experiment
The “tag/label” field is the most visible field on the page. I assumed it is visible by default as it impacts a filter on the top of the page. But maybe I missunderstood this? And the mockups are only about all the possible fields? In that case maybe it will be less a struggle?
If it is there by default, then we will have people reacting to it (we have very few inventory users, we are basically chasing them away from inventory as much as we can ).
When I showed the new layout to a couple of users this week their first reaction was “what the hell is that field”. As playing with it will not help them discovering the impacts, they will reach support for more info. I’m foreseeing a flood in support like the time we change the order of the main OFN menu…
But that topic is linked to how customers are walked through any new features. Maybe I’m too pessimist and FR is not well organized in communication towards users. How do others plan to walk them through this new layout?
This is why I would advocate a component/element by element roll-out of UI uplift as opposed to a whole one big change. Let users get used to sections at a time and that way each new element and good testing can be done on independent elements e.g.
If we rolled out tags/labels first users could get used to it, give feedback as they used it and we could observe and improve in an agile-y way.
Then we choose the next element say…checkboxes and bulk actions for example.
We would plan on ‘selling’ this new ‘tags/labels’ potential - ie: ‘now you can organize your product list any way YOU want’. But for sure - Rachel is right - this will be a biggie from a support point of view. I think once users get that its basically an organizing tool for them (or they can hide it if they don’t use it) - they’ll love it.