Anastasiia Iakovleva    •   Contact

VintedGO · MVP


Summary

Redesigned Vinted’s internal shipping tool from the ground up to support the company’s shift toward Shipping-as-a-Service. Improved usability, reduced errors, and laid the foundation for scalable operations.

Role: Lead Product Designer

Business opportunity

The long-term goal is to offer Shipping as a Service to other marketplaces (both owned and third-party). This strategy will facilitate growth and competitor acquisition while creating additional revenue streams.

Expected outcome

  1. Information architecture for a new tool;
  2. Addressing various usability issues;
  3. Prototypes to test with the users;
  4. Final concept to hand-off to junior designer to pick up.


My process


First, I examined what I had:
  • New data model;
  • Existing tool (Admin tool);
  • List of problems collected by the users;

Excels, docs, raw data that’s being used along with the tool. In order to make sense of it all and understand the processes I’ve decided to talk to the users.




1. User interviews, roles and jobs-to-de-done


I conducted 1-2 individual 1h sessions with all the users (~10 sessions in total):
  • Product managers of the Business unit domain (Contracts);
  • Product managers of Discounts domain (shipping campaigns),
  • Localisation managers (resp. for communications to all markets)

Since this is an internal tool where users come to complete specific tasks, I applied the Jobs-to-be-Done (JTBD) framework. This approach helped me identify 3 key user roles with distinct behaviours:

2. Scope, redefined


It became obvious that in given timeframe it’s impossible to cover all the problems;

We conducted several meetings with the stakeholders to limit the scope to essential functionality: discounts and localization - out.

We applied Okkam’s razor principle to the new tool: with competing theories or explanations, the simpler one, for example a model with fewer parameters, is to be preferred.

3. Information architecture



4. Key use cases


Together with the users we mapped all the key use cases and mapped the existing flows vs. suggested ones. We set up on a calls altogether to work the flows out. Then together with a PM we worked on “ideal’ user scenarios. Knowing the IA and the brief structure of a new tool - it was a next building block for common understanding within the team

I presented and discussed them with the Head of Product Design.






5. Prototypes


Based on the IA and data model, the basic frame for the interface came natural: 3 key sections: Countries, Carriers, Rates;
  • User experience for the key actions: Create, Edit, View.
  • Design system -> Hybrid
  • Show and tell user testing format.




6. User feedback


WE gave users Figma prototypes and simple tasks to perform there, while observing their actions. Not all worked out as planned: some flow optimisation points were not clear to the users;

It was sometimes hard to shift their mindset from being attached to the existing platform: not all features remain on the new prototypes;

However, duplication reached minimum, time to task decreased significantly. Overall user satisfaction increased by just interacting with the prototype.







7. Demo and hand-off

After the first round of feedback I made changes to the designs;
Preparing the hand-off to the designer to take over and continue refining the mock-ups for development: Figma files, flows, IA, roles in Whimsical;

Writing a post for internal usage to spread a word about the work that had been done.


Success metrics


As this project was the kick-off of the new business direction for the company and wasn’t launched yet, we could only measure the qualitative side of things: user satisfaction, speed to task, accuracy (less mistakes made) and overall productivity.

We measured those metrics with Maze tests;

When launched and certain amount of users acquired, there’s a possibility to track platform’s performance, number of tasks completed per hour / day / week and user satisfaction (NPS)


What’s next

  • Prioritise localisation and pricing tracks features;
  • Scale existing functionality to external users;
  • Optimise UI components to ensure high performance and flexibility.


What I’ve learned

  • It’s clear that it’s impossible to build a product that solves all the user problems at once: prioritise and conquer!
  • Users that you can reach 5 days a week via Slack, priceless.
  • Users of internal tools always suffer the most because of poor user experience.

What I’d do differently in 2025

  1. Focus on validation (automatic rules for certain selectors);
  2. Version history (due to high human error, there has to be a way to revert);
  3. Save as draft / Publish / Duplicate (more action types);
  4. Restrictions (overlooked back then).