Milano Contract District · via Teoresi · 2026

From analyst tool to sales aid for in-store consultants

  • B2B
  • Web app
  • Information architecture
  • Design system

An internal web platform where furniture consultants search past kitchen, wardrobe and bathroom projects to show clients something real in minutes. I joined in phase two and turned a tool that read like an analyst's dashboard into one a salesperson can use with a client in front of them.

Client
Milano Contract District, part of Contract District Group
Role
UX/UI Designer, sole designer, via Teoresi
Period
October – November 2026
Team
Six people at Teoresi, three stakeholders on the client side

Result

The client approved the direction and the team chose to restart from this proposal, leaving the previous interface behind. Development is planned for the next phase.

56
filters for wardrobes alone, now grouped and collapsible
107
filter cards pre-sorted for the client to validate

“It feels like something made today.”

Client, design review

The product

MCD is a high-end furniture contractor working for residential real estate, design brands and retail. Its consultants need to find similar past projects fast and show them to clients as a concrete starting point, instead of starting from zero.

  • Consultants, the main users: little time, not technical, a client in front of them
  • Designers, who upload projects with files, renders and attachments
  • Admins, who configure the brief questions and the complexity score

The problem

The first version had been approved screen by screen, then rejected once the product owner joined the project. In review the client was clear: the issue was usability, not colours. No consultant had ever used the tool.

  • A technical, analyst-style interface with long scrolls and small type
  • A filter sidebar with 13 shared filters plus up to 43 per product type
  • Prices formatted inconsistently, with the average shown twice
  • Filters ordered by the data model, not by how a salesperson thinks

Decisions

Decision 01

Fix the information architecture, not the colours

I kept every feature, flow and data field and worked only on hierarchy and presentation. The archive became a sortable table with renders, supplier, numeric prices and layout icons. Project details moved to two columns with a render carousel and grouped attachments, and the brief opened in a side panel instead of a modal.

Decision 02

Make 56 filters navigable

Filters went into accordions that summarise their values when closed, with a badge per section, a global counter and removable chips for the active filters at the top. To settle order and categories, I prepared a board of 107 pre-sorted filter cards for the client to validate.

Decision 03

Familiar patterns, quiet brand

Consultants need to learn the tool fast. I used standard patterns and an almost neutral brand: white background, red only on the active navigation item. I explored and dropped a pink background taken from the website and a version with red on every interactive state.

What shipped

Delivered as Figma mockups and a client presentation. Development follows in the next phase.

  • Project search for kitchens, wardrobes and bathrooms, with empty and no-result states
  • Project detail with modules and grouped attachments
  • Brief and history in a side panel
  • New project and configuration of the brief questions
  • A design system with 14 text styles, palette, light and dark themes

Feedback

“Much more usable. Very tidy.”

Client, design review

“I can read a thought behind it.”

Client, on the kitchen layout icons

Next steps

  • Usability tests in person with four or five consultants
  • Agree order and categories of the filters with the client
  • A single price value and a dimensions column in the archive
  • The design system in code, ready for development

What I learned

When a client says an interface “doesn’t look good”, the problem is often usability, not colour. Start from who uses it and in what conditions: here, a salesperson with little time and a client sitting in front of them.

A deep revision does not have to reopen the whole project. Keep features and flows, and explain the reasoning behind every change.