When curating titles for non-book retailers, users need to be able to identify and categorize titles in unique ways that do not map neatly to shared metadata like genres, formats or publication dates. Users also needed to be able to export deliverables based on these categories, and to make these categories visible to other teammates as they were created.
Because of the wide range of approaches to tagging components across platforms and apps, I approached these interviews as an opportunity for A/B testing.
In collaboration with input from Product, I created prototypes of the workflows for each version.
In any A/B test it is valuable to gather feedback on as many variables as possible, but in this case we had too many versions & too many overlaps in characteristics. Most users had already voiced opinions on all variables and had little left to say by versions D & E.
While we learned the diminishing returns of running through too many prototypes with small variations, we still gathered valuable and instructive user feedback on an ideal component system.
I then ran a design review with the full team to go over interview outcomes, next steps, and to gather preliminary feedback from development.
Having gathered a strategy and run through some basic variations with the product owner, I move on to the final mockups, ticket details, and spec sheets. Because this tagging component was fairly complex, I put together a more in-depth spec sheet.
I cited component libraries in the ticket that developers could use as a foundation for implementation to try to improve clarity.
Citing component libraries does help developers avoid starting from square one on a component, however some limitations only emerge mid-sprint.
In this case, I had proposed certain fixed heights and positions for inputs that turned out to be too time-consuming to customize.
I worked live with developers to come to compromises on the component while maintaining some of the non-negotiable characteristics, and redesigned the UI.
Finally, we deployed and I began going through the platform for QA and to identify any bugs. In this case we had a few bugs emerge that required revisions but otherwise, we pushed a component that the team and the users felt great about!