Coveo Merchandising Hub
Coveo
2023 - 2024
Product Design Lead
🧵 SUMMARY
Scope
I managed and led the design team, known for its incredible talent and design maturity in the company. While doing that I got to define what the experience vision for us should be by building a visiontype, creating our design manifesto.
As my role was a hybrid one, I also got to work on capabilities that increased the breadth of our product such as page creation flows and scheduling.
Challenges
Navigating through problems that require high-context
Defining what is good enough while keeping the bar raised in our design work
Impact (so far)
Recognised as a benchmark for its design quality and processes
Helped Coveo named as a Leader in Gartner's 2024 Magic Quadrant™ for Search and Product Discovery
THE CONTEXT
Background
After acquiring Qubit to complement its Search offering with Recommendations, Badging and more, we identified best way to bring those capabilities together was to build a new product that is using Coveo's technology, while sticking with the design principles and user-centricity we built initially at Qubit.
Why?
Commercially speaking, previous attempts at selling Coveo to Qubit customers or vice versa weren't successful. On top of that, we had different tech stacks and cloud services which made integrating existing capabilities very difficult.
After discussions between Product, Design and Engineering, we've agreed to decide re-build our game-changer product from scratch, while keeping the "how it works" experience very similar to what we achieved in Qubit for Merchandisers.
BUILDING THE FONUDATIONS
Initial plan
As we were going to build the product from a tech perspective from scratch, this gave us the design team to use this opportunity to build strong foundations and make the call on what capabilities to prioritise over when it comes to re-building the product.
To achieve this, I've set up a plan to identify what are the things we de-risked and how these experiences can be built using our new design system foundations that we built on top of Mantine - an open-sourced component library - whilst keeping the look and feel that made our previous product acknowledged as superior both internally and externally.
To explain the value of getting the foundations right to the wider audience, we came up with a minimalist representation of the layers that goes into a design system's UI part: Foundations, Components, and Patterns.
As we worked on features on our roadmap, in parallel, we continued to work AND present the progress on how we are doing by introducing milestones as Design tokens, typography and even a change log to show the progress.
SETTING A VISION
VISIONTYPE
As mentioned above, there was a lack of clarity for many in this situation. And for many describing it in a vision statement just wasn't enough. For that purpose, I started reviewing what we set out to do, what would be different from our previous context (Qubit for Merchandising) and what each stakeholder understood from that future/vision statement.
After doing this, I built a vision prototype (visiontype) to have a flag in the sand, something that can be used as a communication piece across product, design and engineering to show what that 3 year vision could look like.
WHAT IS A VISIONTYPE?
I paired the visiontype with some written guidelines built into the prototype to essentially not let that message fall through the cracks.
Guidelines
Level 1 - Baseline rules
This prototype is a communication piece, a flag in the sand, something that can be used as a guide for Commerce R&D teams.
This is NOT what we are going to build in the next X months.
This prototype also has opinions , and those opinions might or might not change.
Level 2 - Details
In this vision, there are two guiding constructs: Baseline & Campaigns.
A campaign is a group of configuration: anything that’s going to need targeting or a deadline.
Baseline is what is permanent, and won’t need targeting.
Level 3 - Reminders
This prototype, like others, has cracks - that’s how the light gets in ☀️.
INCREASING DEPTH
& BREADTH
While building the foundations right and setting a vision is important, it was just as important to work on capabilities that would bring the customers value, and convince them to adopt this new product.
In order to achieve this, I played the role of Staff Product Designer, and joined the teams whenever a user-facing problem is tackled and helped build the right solution in the right way. For this case study, I'd highlight two examples: Properties research with the Implement team & Scheduling with the Engage team.
MINI CASE STUDY:
PROPERTIES
One thing we didn't want to take as is when building the product was the notion of organizations at Coveo. Each client had a flat, single organization where every feature was visible to every user. This approach would have been problematic given our Commerce customers and the concept of "Merchandising teams" which based on our previous user feedback.
For that reason, I created a research document with two different approaches to what the new level of control could look like.
During first research round, customers had some trouble understanding the concept so I made a quick iteration to simplify it further (see below).
MINI CASE STUDY:
SCHEDULING
Work In Progress..
Thanks for reading so far! As you can see, this case study is a work-in-progress and is regularly updated until I deem it to be a complete one.
In the meanwhile, if you have any questions, don't hesitate to reach out via email.