As the sole product designer on Uni-ce, I mainly…
- Worked closely with the client and key stakeholders to understand how the platform was supposed to operate, where the product was breaking down, and what the business actually needed from it.
- Conducted interviews with end users to learn how employees were navigating the platform, where they were getting stuck, and which parts of the experience were creating confusion.
- Audited the existing designs created by the previous agency, identifying structural flaws in the product flows and resolving them before moving forward with new design decisions.
- Designed and structured the core backend modules for the platform, covering both the employee side of the product and the administrative tools used by the platform operators.
- Broke down the messy product structure and reorganized it into clear modules so the platform could actually scale as more services were added.
- Worked closely with developers to make sure the product logic and backend modules made sense and could be realistically implemented.
When we first reviewed the project, the biggest issue wasn’t the UI itself. It was the structural chaos inside the design file.
The previous agency had built the entire platform directly in high-fidelity screens without any proper foundation. There were no wireframes, no system thinking, and no shared structure agreed on with the client before jumping into final designs.
With more than 100+ screens, even the smallest change would ripple through the entire file.
Without reusable components or consistent layout structures, simple updates became painful. Changing something as basic as the navigation bar would break dozens of screens, forcing manual fixes everywhere.
There was no design system, no reusable components, and no consistent layout rules. Many screens had floating elements and inconsistent spacing, making the entire file fragile and difficult to maintain.
Because everything was built directly in high-fidelity designs, each change required reworking multiple screens instead of adjusting a structured system. What should have been a small tweak could take hours.
Without a clear process or structured iterations, feedback became chaotic. The Figma file ended up with hundreds of comments from the client’s team, reacting to every small change.
What initially looked like a messy UI turned out to be a deeper structural issue. Without a clear system, components, or process, the design file had grown into a fragile set of screens where small changes could easily break multiple flows.
The previous design process had left the client pretty frustrated. Small changes often broke parts of the design, so trust in the workflow was very low. Since the product was already built on this e-commerce platform, our focus wasn’t creating new screens but stabilizing and fixing the existing design while introducing a more structured process.
Before moving to the backend modules, the first priority was stabilizing the existing e-commerce platform design. The client had already lost confidence in the process, so the goal wasn’t redesigning everything, but making controlled improvements that fixed the most problematic areas and showed that changes could be handled in a predictable way.
- Focused on stabilizing the existing e-commerce module rather than redesigning the whole product.
- Fixed key structural issues that were breaking layouts and flows.
- Prioritized areas where developers struggled with implementation.
- Made small controlled adjustments instead of large redesigns.
- Cleaned up parts of the design to make future changes safer and easier.
- Used each iteration to show clear progress and rebuild client confidence.
- Prepared the product structure so we could move to designing the backend modules next.
About a month after stabilizing the e-commerce design, we shifted focus to the platform’s backend. The existing system already had administrative modules, but they had grown into an outdated and cluttered environment that was difficult to maintain or expand. Instead of trying to patch the old system, the decision was made to rebuild the platform structure from scratch while learning from what already existed.
Before designing new modules, we first needed to understand how the current platform actually worked and what the teams operating it needed on a daily basis.
- Reviewed the existing backend platform to understand how the current modules operated.
- Identified pain points and limitations in the old system’s structure and workflows.
- Mapped how different administrative functions were handled across the platform.
- Conducted interviews with key project stakeholders to understand operational needs.
- Gathered insights on where the platform was slowing teams down and where improvements were most needed.
We conducted multiple workshops to review the current Users module and map out its main issues, creating boards for each main section to capture the key observations and insights that will guide the redesign.
Once the initial flows were ready, we went back to our participants from the generative research to evaluate how the product actually felt in use. We walked through key scenarios together, observed where confusion happened, and gathered feedback on clarity, trust, and ease of navigation. a usability test on our initial prototype was the key to moving forward.
As expected, some ideas that worked well in theory felt different once people interacted with the product...
One clear example of this appeared while testing, several users struggled to understand how services were organized and how to manage them, which revealed a structural issue in the vehicle services flow that needed to be reworked:
Completed and recurring services were mixed in one list, which confused users. Managing entries required extra steps through dropdown menus.
The screen was split into Service Log and Upcoming Services. Actions became directly accessible, recurring services were clickable, and adding or deleting entries became simpler and clearer.
it was time to bring visual consistency to the project. We built a dedicated design system for Qetae to ensure clarity, scalability, and consistency across services, parts, and logistics experiences.
As we were building it, we made a few decisions to keep the product consistent as it grows:
- We fixed clear placement rules for actions so users don’t have to search for buttons across different screens.
- We reduced variation in layouts to avoid redesigning patterns for every new flow.
- We kept interactions straightforward and avoided overcomplicating components.
After refining the flows and locking the design system, we moved to figma to work on the high-fidelity screens. This was about making decisions final and ensuring the product felt modern, clear and consistent across every touchpoint.
Here are selected screens from the final product alongside the prototype canvas we worked on.
Once the high-fidelity screens were finalized, we connected them into a fully interactive prototype. Rather than reviewing isolated screens, this allowed us to experience the product as a complete journey, moving from discovery to action and confirmation.
With the full flow in place, we ran another round of usability testing to evaluate how the product performs in realistic scenarios. The focus this time was on overall clarity, decision-making moments, and how smoothly users could move through the marketplace.
With the final prototype in place, we tested the full experience end to end with the same participants involved earlier in the process. The goal was to measure how clearly users could complete key tasks and whether the product reduced the friction we initially identified.
The decisions been taken showed up clearly in how users moved through the product and completed key tasks.
And some of the results were:
of participants successfully completed a full service booking without external help.
of vehicle owners used filters or vendor comparison before confirming a service.
faster, the users reached a relevant garage or part option compared to the initial V.1 wireframe prototype testing.
of participants reported feeling confident in their final decision before checkout.
Qetae started with a simple question: why is something as common as finding a garage still so manual and outdated? Through conversations, testing, and iteration, the product slowly became clearer and more structured with every step. This project reminded me that good products aren’t built from assumptions, but from listening, refining, and testing until the experience actually works in real life.