My Framer Site

Catawiki's object tree

Designing the foundational structure for Catawiki’s taxonomy platform

Catawiki's object tree

Designing the foundational structure for Catawiki’s taxonomy platform

Catawiki's object tree

Designing the foundational structure for Catawiki’s taxonomy platform

Employer

Catawiki

Areas

Design, Systems thinking

Platform

Web

Year

2022

Employer

Catawiki

Areas

Design, Systems thinking

Platform

Web

Year

2022

Employer

Catawiki

Areas

Design, Systems thinking

Platform

Web

Year

2022

Background

Catawiki was preparing for a major structural shift, moving from a category-driven system to an object-centric data model. This change would allow sellers to list objects more accurately and enable better search, discoverability, and automation across the marketplace. Enabling this shift meant redesigning the internal systems that managed the object taxonomy.

Background

Catawiki was preparing for a major structural shift, moving from a category-driven system to an object-centric data model. This change would allow sellers to list objects more accurately and enable better search, discoverability, and automation across the marketplace. Enabling this shift meant redesigning the internal systems that managed the object taxonomy.

Background

Catawiki was preparing for a major structural shift, moving from a category-driven system to an object-centric data model. This change would allow sellers to list objects more accurately and enable better search, discoverability, and automation across the marketplace. Enabling this shift meant redesigning the internal systems that managed the object taxonomy.

1

Experts, who curate auctions

2

Commercial teams, who manage the taxonomy and object attributes

3

Sellers, whose submission experience depends on this structure

1

Experts, who curate auctions

2

Commercial teams, who manage the taxonomy and object attributes

3

Sellers, whose submission experience depends on this structure

1

Experts, who curate auctions

2

Commercial teams, who manage the taxonomy and object attributes

3

Sellers, whose submission experience depends on this structure

The challenge

Design a taxonomy tool that could support a shift from a small category tree to more than 10,000 objects, while making it faster and easier for the commercial team to manage object attributes.

The challenge

Design a taxonomy tool that could support a shift from a small category tree to more than 10,000 objects, while making it faster and easier for the commercial team to manage object attributes.

The challenge

Design a taxonomy tool that could support a shift from a small category tree to more than 10,000 objects, while making it faster and easier for the commercial team to manage object attributes.

My role

I led the design across the commercial and expert tools, and ultimately the seller-facing experience as well. This case focuses on the taxonomy tool for commercial teams.

My role

I led the design across the commercial and expert tools, and ultimately the seller-facing experience as well. This case focuses on the taxonomy tool for commercial teams.

My role

I led the design across the commercial and expert tools, and ultimately the seller-facing experience as well. This case focuses on the taxonomy tool for commercial teams.

Problems with the existing tool

Interviews with the commercial team and Catawiki experts revealed three main problems:

1

Slow and difficult to manage

Editing object specifications required navigating deep into the category tree. Even small updates meant drilling through multiple layers, and adding new objects or attributes had to be done manually one by one. The commercial team often spent days completing tasks that should have taken hours.

2

Not designed for scale

The system was originally built for 16 categories, but the shift to an object-centric structure meant managing 10,000+ objects and their attributes. The existing tool had no way to apply changes across multiple items or manage attributes centrally, making it difficult to maintain.

3

Rigid structure

Objects were tightly tied to categories, which created downstream problems. Experts couldn’t easily move items between auctions if they were miscategorized, and sellers often had to resubmit objects entirely. As the taxonomy grew, this rigidity would only become more problematic.

Problems with the existing tool

Interviews with the commercial team and Catawiki experts revealed three main problems:

1

Slow and difficult to manage

Editing object specifications required navigating deep into the category tree. Even small updates meant drilling through multiple layers, and adding new objects or attributes had to be done manually one by one. The commercial team often spent days completing tasks that should have taken hours.

2

Not designed for scale

The system was originally built for 16 categories, but the shift to an object-centric structure meant managing 10,000+ objects and their attributes. The existing tool had no way to apply changes across multiple items or manage attributes centrally, making it difficult to maintain.

3

Rigid structure

Objects were tightly tied to categories, which created downstream problems. Experts couldn’t easily move items between auctions if they were miscategorized, and sellers often had to resubmit objects entirely. As the taxonomy grew, this rigidity would only become more problematic.

Problems with the existing tool

Interviews with the commercial team and Catawiki experts revealed three main problems:

1

Slow and difficult to manage

Editing object specifications required navigating deep into the category tree. Even small updates meant drilling through multiple layers, and adding new objects or attributes had to be done manually one by one. The commercial team often spent days completing tasks that should have taken hours.

2

Not designed for scale

The system was originally built for 16 categories, but the shift to an object-centric structure meant managing 10,000+ objects and their attributes. The existing tool had no way to apply changes across multiple items or manage attributes centrally, making it difficult to maintain.

3

Rigid structure

Objects were tightly tied to categories, which created downstream problems. Experts couldn’t easily move items between auctions if they were miscategorized, and sellers often had to resubmit objects entirely. As the taxonomy grew, this rigidity would only become more problematic.

Designing for scale

The new tool to prioritize speed, clarity, and scalability.

Designing for scale

The new tool to prioritize speed, clarity, and scalability.

Designing for scale

The new tool to prioritize speed, clarity, and scalability.

Searchable tree

I replaced the existing progressive navigation with a split tree view. Users could browse the object hierarchy on one side while instantly viewing the specifications attached to each object on the other. This eliminated constant back-and-forth navigation and gave the team a clearer overview of the structure.

Searchable tree

I replaced the existing progressive navigation with a split tree view. Users could browse the object hierarchy on one side while instantly viewing the specifications attached to each object on the other. This eliminated constant back-and-forth navigation and gave the team a clearer overview of the structure.

Searchable tree

I replaced the existing progressive navigation with a split tree view. Users could browse the object hierarchy on one side while instantly viewing the specifications attached to each object on the other. This eliminated constant back-and-forth navigation and gave the team a clearer overview of the structure.

Objects inheriting properties

Inspired by component systems in tools like Figma, object types were nested under parent groups that automatically inherited shared properties. The team could update attributes once at the parent level and apply the change across all child objects. It significantly reduced repetitive work.

Objects inheriting properties

Inspired by component systems in tools like Figma, object types were nested under parent groups that automatically inherited shared properties. The team could update attributes once at the parent level and apply the change across all child objects. It significantly reduced repetitive work.

Objects inheriting properties

Inspired by component systems in tools like Figma, object types were nested under parent groups that automatically inherited shared properties. The team could update attributes once at the parent level and apply the change across all child objects. It significantly reduced repetitive work.

Designing for speed

Users could paste lists of object names to generate multiple entries at once instead of adding them individually. They could also add or remove properties in a deactivated state, allowing the team to prepare changes without affecting the live seller experience.

Designing for speed

Users could paste lists of object names to generate multiple entries at once instead of adding them individually. They could also add or remove properties in a deactivated state, allowing the team to prepare changes without affecting the live seller experience.

Designing for speed

Users could paste lists of object names to generate multiple entries at once instead of adding them individually. They could also add or remove properties in a deactivated state, allowing the team to prepare changes without affecting the live seller experience.

Designing for volume

We introduced smarter tools for bulk operations. Users could search for strings of attributes and activate or deactivate them in bulk. Engineering also introduced the concept of traits ; rules that override default properties for groups of objects. I designed an interface that made these rules visible and editable within the tree, allowing the team to manage large groups of objects efficiently.

Designing for volume

We introduced smarter tools for bulk operations. Users could search for strings of attributes and activate or deactivate them in bulk. Engineering also introduced the concept of traits ; rules that override default properties for groups of objects. I designed an interface that made these rules visible and editable within the tree, allowing the team to manage large groups of objects efficiently.

Designing for volume

We introduced smarter tools for bulk operations. Users could search for strings of attributes and activate or deactivate them in bulk. Engineering also introduced the concept of traits ; rules that override default properties for groups of objects. I designed an interface that made these rules visible and editable within the tree, allowing the team to manage large groups of objects efficiently.

Process

Mapping the system

Before designing the tool, I worked with product and commercial teams to map how the systems would change. In the new structure, object attributes shown in the seller listing flow would be tied to objects instead of categories. The tool therefore needed to manage a much wider set of attributes and relationships. Mapping these connections helped define the capabilities the tool needed to support.

Mapping the system

Before designing the tool, I worked with product and commercial teams to map how the systems would change. In the new structure, object attributes shown in the seller listing flow would be tied to objects instead of categories. The tool therefore needed to manage a much wider set of attributes and relationships. Mapping these connections helped define the capabilities the tool needed to support.

Mapping the system

Before designing the tool, I worked with product and commercial teams to map how the systems would change. In the new structure, object attributes shown in the seller listing flow would be tied to objects instead of categories. The tool therefore needed to manage a much wider set of attributes and relationships. Mapping these connections helped define the capabilities the tool needed to support.

A simplified category and object mapping

A simplified category and object mapping

A simplified category and object mapping

Early exploration

I started with quick sketches to explore different ways of structuring the information. Benchmarking other tree management tools helped simplify these ideas into a nested tree model that balanced overview with depth.

Early exploration

I started with quick sketches to explore different ways of structuring the information. Benchmarking other tree management tools helped simplify these ideas into a nested tree model that balanced overview with depth.

Early exploration

I started with quick sketches to explore different ways of structuring the information. Benchmarking other tree management tools helped simplify these ideas into a nested tree model that balanced overview with depth.

Inspiration and architecture exploration

Inspiration and architecture exploration

Inspiration and architecture exploration

Identifying key scenarios

Because the tool was complex, I defined a set of key scenarios with the commercial team and engineering leads. These scenarios focused on the most critical workflows; adding new objects, editing attributes, and managing large groups.

To accelerate alignment, I facilitated a week-long design sprint with stakeholders to shape the first version of the tool.

Identifying key scenarios

Because the tool was complex, I defined a set of key scenarios with the commercial team and engineering leads. These scenarios focused on the most critical workflows; adding new objects, editing attributes, and managing large groups.

To accelerate alignment, I facilitated a week-long design sprint with stakeholders to shape the first version of the tool.

Identifying key scenarios

Because the tool was complex, I defined a set of key scenarios with the commercial team and engineering leads. These scenarios focused on the most critical workflows; adding new objects, editing attributes, and managing large groups.

To accelerate alignment, I facilitated a week-long design sprint with stakeholders to shape the first version of the tool.

Examples of pre-defined scenarios from the sprint

Examples of pre-defined scenarios from the sprint

Examples of pre-defined scenarios from the sprint

Iterative development

As engineering began building the tool, we reviewed and tested features continuously with the commercial team. This allowed us to adjust the design quickly and resolve issues as they surfaced. The tool is currently used as Catawiki’s main inhouse taxonomy tool.

Iterative development

As engineering began building the tool, we reviewed and tested features continuously with the commercial team. This allowed us to adjust the design quickly and resolve issues as they surfaced. The tool is currently used as Catawiki’s main inhouse taxonomy tool.

Iterative development

As engineering began building the tool, we reviewed and tested features continuously with the commercial team. This allowed us to adjust the design quickly and resolve issues as they surfaced. The tool is currently used as Catawiki’s main inhouse taxonomy tool.

Impact

- 7hrs

Manual work per week

- 7hrs

Manual work per week

- 7hrs

Manual work per week

Reflection

Something that worked well

Involving stakeholders throughout the design process helped uncover critical edge cases early. Bringing senior stakeholders into the design sprint at key checkpoints accelerated decision-making and helped maintain alignment.

Something that worked well

Involving stakeholders throughout the design process helped uncover critical edge cases early. Bringing senior stakeholders into the design sprint at key checkpoints accelerated decision-making and helped maintain alignment.

Something that worked well

Involving stakeholders throughout the design process helped uncover critical edge cases early. Bringing senior stakeholders into the design sprint at key checkpoints accelerated decision-making and helped maintain alignment.

What I'd do differently

In hindsight, I would have started with the seller experience first and then designed the tooling around it. We began with the internal system because it was foundational, but once the seller flow evolved we had to revisit parts of the tool to adapt. Starting from the customer journey would have reduced some back-and-forth later.

What I'd do differently

In hindsight, I would have started with the seller experience first and then designed the tooling around it. We began with the internal system because it was foundational, but once the seller flow evolved we had to revisit parts of the tool to adapt. Starting from the customer journey would have reduced some back-and-forth later.

What I'd do differently

In hindsight, I would have started with the seller experience first and then designed the tooling around it. We began with the internal system because it was foundational, but once the seller flow evolved we had to revisit parts of the tool to adapt. Starting from the customer journey would have reduced some back-and-forth later.