For more than a year and a half, I designed a product that worked exactly as intended. It was structured, scalable, and thoughtfully crafted. Users could onboard, create listings or requests, track orders, and manage their activity through a dedicated dashboard.
And yet, almost no one used it.
This project forced me to confront a deeper question: Not whether the product worked, but whether it should exist in that form at all.
Defining user flows and system structure
Designing the dashboard and key interactions
Creating prototypes and validating ideas
Iterating based on feedback from internal teams and users
Collaborating closely with product and engineering
Contributing to product direction as insights emerged
Figma (Figma Make)
Miro
Lovable
A little bit of Context
Metycle operates in the scrap metal industry, connecting buyers and sellers across global markets. This is not a digital-native environment.
Transactions are built on:
Long-term relationships
Personal trust
Direct communication
Users often rely on tools such as WhatsApp, email, and phone calls to conduct business. Many are not highly technical, and even those who are prefer human interaction over self-service systems. This context shaped everything that followed.
The goal was to digitize the trading experience. I designed a platform where buyers and sellers could:
Create listings and requests
Track orders and statuses
Manage transactions through a dashboard
The assumption was simple:
Given the right tools, users would prefer autonomy and transparency.
Before diving deeper into the design process, here is a link to Figma, in case you are interested in seeing more screens
The platform was centered around a dual-sided dashboard.
Core components:
Listings for sellers and requests for buyers
Order tracking across multiple states
Status visibility and updates
Role-based interactions depending on user type
The system was designed to simplify a complex process. It aimed to bring clarity, reduce manual coordination, and create a scalable digital workflow.From a design perspective, the solution was coherent and complete.
What happened was:
Users onboarded and showed intent.
But they did not use the dashboard.
Instead, they:
Contacted traders directly
Continued using familiar communication channels
Relied on human intermediaries
The product was not rejected. It was bypassed.
We were designing for efficiency, while users were optimizing for trust.The platform attempted to replace human interaction.The business depended on it.
Iteration: Marketplace and Bidding
We introduced a marketplace with public listings and bidding.
Traffic increased
Engagement improved
But behavior did not change. Users still wanted to speak to a trader after submitting a bid.
While focusing on user-facing products, another issue surfaced internally.
Traders managed deals through spreadsheets
There was no centralized system for tracking transactions
Tools like Pipedrive were introduced but proved difficult to use
The people responsible for closing deals lacked tools that fit their workflows. This created inefficiencies that directly impacted the business.
The opportunity was not to replace traders. It was to support them.
We shifted focus toward:
Internal tools for deal tracking
Simplified workflows for non-technical users
Designing around human-led processes
Evolving Our Approach
To better align stakeholders and reduce ambiguity, we introduced Lovable into the workflow. This allowed us to move beyond static design and prototype real scenarios.
Internal Platform
We designed a system for traders and operations teams to track transactions from negotiation to completion. Prototypes reflected real workflows and were used directly with stakeholders before development.
Website Redesign
I led a redesign of the marketing site to reposition the company around trust and expertise. Prototyping helped align messaging and structure early.
Both projects were delivered to developers through a “vibe coding” approach, preserving intent from design to implementation.
What I learnt
This project reshaped how I think about product design.
1. Adoption is the metric that matters
A product can be complete, usable, and well-designed. If people choose not to use it, none of that matters. Adoption is not a consequence of good design. It is the validation of it.
2. Behavior reveals truth faster than research
We could have continued refining flows and adding features. Instead, user behavior made the problem obvious. People consistently chose humans over interfaces. That signal was stronger than any feedback.
3. Trust is not a UX problem
We initially approached this as a usability challenge. It was not. Trust operates outside the interface. In some industries, the role of design is not to replace trust, but to respect and support how it already exists.
4. The most important user is not always the end user
We focused on buyers and sellers. The business depended on traders. Once I shifted my attention to the people actually closing deals, the product direction became clearer.
5. Simplicity is contextual
Tools like Pipedrive failed not because they were inherently complex, but because they did not match how users think and work. Simplicity is not about reducing features. It is about aligning with mental models.
6. Prototyping is a strategic tool
Using Lovable changed how I worked. It allowed me to communicate ideas through interaction instead of explanation. It reduced misalignment and made product decisions more tangible for everyone involved.
This project changed my role as a designer. I started by focusing on interfaces. I ended by focusing on systems.
I used to believe that good design could guide users toward better behavior. Now I understand that behavior is often fixed, especially in industries shaped by trust and relationships. The role of design is not to fight that, but to work with it.
If I approached this problem today, I would not start with a dashboard. I would start by mapping how trust flows through the system. Who people rely on, when they need reassurance, and where digital tools can support rather than replace those moments.
The most valuable outcome of this project was not the product we built.
It was learning where not to build.
And that has changed how I approach every problem since.
© 2026 Nasim Raeesi