SaaS Multi-vendor Marketplace Builder
Dokan, weDevs
Multi-vendor, SaaS
Product Designer
Dokan Cloud is a SaaS application that allows users to build marketplaces like Amazon, eBay, Etsy, and more. With this application, users can easily access all the necessary functionalities to create a multi-vendor marketplace, along with a drag-and-drop website builder similar to Elementor. Recently, it launched a standalone marketplace feature, enabling users to run an eCommerce business and build a single marketplace for themselves. It’s an all-in-one solution for eCommerce
business owners.
My core responsibilities for this project included designing interfaces, contributing to the design system, creating wireframe iterations, and conducting competitive and functional analyses. I collaborated with two product analysts, a design lead, a product manager, the development team, and the marketing team.
Since the entire product is huge and I won’t be able to show it thoroughly, I will still try to share my overall experience while working on it. Before diving into the details, let’s take a sneak peek at the platform.
Creating a SaaS application for building a multi-vendor marketplace is highly complex due to numerous functional dependencies. With so many features, it can be challenging to simplify the platform for users, ensuring they don’t feel lost while using it and keeping the learning curve manageable.
There are many functionalities and customizations required to build a multivendor marketplace. However, if users feel overwhelmed by these features and struggle to find what they need, the platform may become redundant for them.
Example: The Payout tab in the multivendor marketplace builder allows vendors to withdraw their money. Additionally, the payout section includes other settings. If these are combined, the module can become cluttered and difficult to understand.
As it’s a huge SaaS platform, many modules have cross-functional dependencies, which create numerous edge cases. Despite this, all the modules were designed and developed separately, leading to a high probability of conflicts between functionalities and the emergence of new edge cases.
Example: If a user configures an omni sales channel like Amazon, additional fields are added to the product details. If these fields are not properly filled out, the user cannot sell the product on the Amazon marketplace through the omni sales channel. This creates several new edge cases, such as determining which platform will fulfill an order arriving from the Amazon marketplace and how the order will be fulfilled.
As this SaaS platform has many modules, and all the modules have been designed separately, it is crucial to maintain a consistent user experience throughout the platform to prevent users from feeling confused when navigating between modules. If the learning curve varies significantly from one module to another, there is a high chance users will stop using the platform.
For a particular module, a developer has their own vision of it, as they understand how the API will be handled and what can be developed within a specific scope. Therefore, while designing a module, it is crucial to stay aligned with the developer. If I design something that is not feasible within the given scope or has limitations, it can create conflicts with the developers and lead to delays in delivery. Ultimately, this will impact the entire team.
It’s a great issue in all the big products such as the first idea about a particular module and the released fully functional module have a huge difference between them. And between this a lots of iteration happens which causes delays in product release.
Example: The initial idea was to create a theme library. The released version is a theme library featuring multiple themes across various categories, with demo preview options where users can check the responsive versions of the themes and customize them according to their needs. The gap between the initial idea and the final version costs a lot of time and effort if it happens team by team rather than collaboratively with everyone working together.
It’s always great to draw inspiration from other teams for design and problem-solving ideas, but it’s not always easy to adapt those ideas to our platform since every design addresses a different problem.
Sometimes, it takes significant time and effort to modify those ideas to make them suitable for our platform. And at times, it becomes quite challenging to help others understand why a particular idea won’t work for us.
Grouping the functionalities, arranging them step by step, and finally providing a guide to make these complex functionalities easily accessible and understandable for users.
Analyzing group by group can be time-consuming and complex, so why not do it together? While it’s not always possible, I still push to make it happen during the research and analysis phase. Even if that doesn’t happen, I try to address it during the design stage by collaborating with developers, analysts, and PMs to stay on the same page and resolve as many edge cases as possible. After that, I send the design for final review. And that helps reduce iterations and development delays.
Most of the conflicts happen with the developers when there are changes in the design or when a new component appears that they are unaware of. The only solution to solve this is a design system. Although we haven’t named it, we can refer to it as the Dokan Design System. The design lead was responsible for building the design system, but my role was to request updates to the system or add new components used in a module.
This is the most difficult part to follow or perform. On this platform, as many ideas were being discussed, sometimes fellow designers were designing different modules. With all of that happening, it was quite difficult for me to focus fully on my own design. I made a lot of mistakes, but it’s something I tried to follow in order to maintain a consistent experience across the platform and fix design errors as needed.
As this is a huge project, we have designed module one by one as per the roadmap and requirements. For confidentiality purposes, I have excluded the actual metric.
Before we started designing, we have give a deep dive into user who will be using our platform. And we have divided our users into 3 major categories,
And we have defined and tried to map what job they want to done with our platform.
Our main user is the person who will build the marketplace and invite sellers/vendors to sell on the platform. They will also target customers who can purchase from the platform.
Additionally, this user will set up everything and customize the marketplace’s outlook.
Those who are invited by the admin or attracted to the platform will want to sell their products on it.
These individuals will have their own stores on the platform to run their businesses.
Those who purchase from the platform/marketplace can also create an account to track their orders and receive exclusive offers in the future.
When I was appointed to the role for this product, I received some initial platform outlook concepts from the design lead and the CTO. They were rough, but they provided a good direction on where we needed to go and what type of design we needed for the platform. Although it gave some boundaries for how the platform might look, the direction had already been selected.
As I have worked on this product for a long period of time, and many things appeared and faded throughout the timeline. Similarly, while designing for this product, our PM and product owner tried different methods to achieve faster results. I will describe how I adapted to each method and the obstacles I faced.
In the initial timeline, PM and product owner thought to provide heavy focus on the initial research and ideation. So they shared what feature/module they want to develop with the analyst team. And after that analyst team tried to come up with some documentation and mockup regarding how might that feature will work.
As an example, while working on the shipping module, I adapted to this method and tried to stay aligned with the analyst team.
After the analyst team completed their mockup, they gave us a brief about the functionality and flows, explaining how it would work. After understanding it, I tried to gather some resources from competitors like Shopify, BigCommerce, Wix, Squarespace, and others.
After gathering these resources, I started designing the functionalities while keeping development accessibility in mind.
From the initial phase of design to finalization, extensive ideation took place. Feedback and edge case scenarios emerged, which we needed to address to make the module functional and user-friendly. First, we identified these issues, brainstormed different solutions to resolve them, and implemented the most optimal solution.
The focus of the customer checkout flow is to allow customers to complete their purchase with minimal distractions and obstacles while giving them the freedom to update their credentials before completing the order.
As the Admin sets the type of shipping, vendors can create shipping profiles in which they can define rules for calculating shipping. For instance, they may ship different types of products, such as fragile items, refrigerators/TVs, or jewelry. Since different products require distinct shipping approaches, vendors can create specific profiles and set tailored rules for each type.
Many functionalities have been moved from the shipping settings page to the profile details page to give vendors additional control over their shipping.
On the admin settings page, the admin can specify which regions or countries the marketplace will provide shipping to. Additionally, the admin sets up the types of shipping vendors can offer to customers. Instead of defining specific rules for each shipping type, the admin configures generic options that customers will see
at checkout.
After completing a few modules, we identified significant flaws in this process. The iterations are taking a lot of time because different teams are working on the same module at different stages. As a result, at each stage, we encounter various limitations and feedback. Collecting and addressing this feedback is consuming a significant amount of extra time. This could be minimized if all the team members involved in the module collaborate, discuss, and share their insights together upfront.
Pros: Greater scope for research, initial iteration, and ideation.
Cons: A significant amount of time was wasted while building a single feature or module because not everyone was collaborating simultaneously.
I will update soon how I have adopted the process and make it fruitful … 🥹🥹
Before releasing the first version of the platform, I didn’t have the scope for user testing and company also was rushing for the early release. But after we release the early version of the platform, we start performing quantitively research and we got some great feedback.
After collecting the research data, we separated the tasks required to resolve the identified issues. The development team focused on issue resolution, while the quality assurance team concentrated on thoroughly testing all functionalities. On our side, we began noting down UX and responsiveness issues as comprehensively as possible and started designing the necessary functions and responsive screens.
As users were facing issues, we provided them with a live consultancy option to ensure they received the guidance they needed. This also allowed us to gather more information and valuable feedback. Additionally, we gained great insights into their desired functionalities and expectations during the year-end review.
After receiving feedback regarding the responsive design, we quickly made progress. Interestingly, we have completed the responsive design for our storefront, which is the interface customers interact with. Additionally, the responsive design for our admin and seller interfaces is 80% complete.
Along with implementing responsive design, I also worked to identify UX issues on the platform and documented them. I then communicated with the lead to address and resolve those issues as quickly as possible
For a project of this scale, even though we have already fixed plenty of bugs before public release, there are bound to be minor bugs.
This is a crucial next step for every UX improvement or product launch. With informed, actionable insights, we are able to design a better experience for our consumers.
To follow through our product roadmap and continue to stick to our design principles.
Huge kudos to our product analysts and development team—without their dedication and effort, achieving iterative development and gathering information at lightning speed wouldn’t have been possible. Additionally, thanks to the support from our marketing and support teams, we were able to collect pre-release bug and issue data much faster.
Finally, thank you for reading! I hope you enjoyed learning about my design and thought process. 🙂
Feel free to reach out for projects, collaborations, or just to say hello! Currently seeking new opportunities.