Waasla is a Supplier Relationships Manager that helps SMBs gain control of their supplier lifecycle. We took a different approach than most SRMs, deciding to focus on basic tasks and do those well instead of building as many features as possible.
I’ve designed Waasla as an external contractor, working with a Business Analyst, Product Manager, and the Engineering team on the client side. This was a three months remote engagement.
Waasla wanted to launch a new Supplier Relationships Manager (SRM) aimed at small and medium businesses trying to simplify their procurement process and nurture relationships with their suppliers.
One of the aspects of Design that I enjoy the most is helping companies get off the ground by launching early iterations of their products. What I like particularly about B2B projects is being able to tackle industries that are not historically known for user-friendliness, and put a dent in that market. That’s why this project was exciting.
I began by interviewing stakeholders to understand their pain points, needs, and which gaps the product could fill in the market. Since I didn’t understand the industry well enough, I spent time looking into what value these tools are adding and what the industry is all about. I booked demos for competitor products and created a market landscape analysis together with the client, on which I plotted our desired placement as well.
During this stage it became clear that our product had to be designed not with one, but with two audiences in mind. On one hand we had the procurement/supplier managers (we’ll call them managers from here on) — these are the people who need to manage campaigns, tasks, do reporting, and track the performance of their suppliers. On the other hand we had the suppliers themselves. They needed an easy way to onboard and communicate with the companies they supply goods and services to.
As with any other MVP, the product roadmap is often created off the back of multiple trade-offs, whether in the interest of time, budget, or initial serviceable market. After discussing the full requirements and constraints with the client, we’ve made the decision to focus on managers initially. Since they were going to be the main audience for the product, we wanted to create an optimal experience for them. While this didn’t mean we completely ignored the suppliers flow, it did lack some basic functionality that was not deemed to be critical.
Diverging to understand
During interviews with managers in the Middle East and Europe I uncovered many opportunities based on their workflow. Two main cohorts stood out to me:
- people using complex CRMs — they were often frustrated with the clunky software requiring extensive training for each new employee
- people using third-party tools (Excel, AirTable, WhatsApp, email) – they struggled to keep an overview of each supplier since everything was so scattered.
The biggest pain points we uncovered
Based on these interviews I also created a persona, to get a shared understanding of who we were designing for. This also helped with recruiting participants for testing, since we had a clear picture of what we needed. The research pointed us to the fact that we were designing for a narrow niche — this helped us focus on their specific needs instead of aiming wide.
Converging to focus
Since the research showed that managers spend most of their time performing four main tasks, we’ve made the call to build the MVP around them:
Onboarding suppliers and editing their information
Creating, assigning, and managing tasks
Capturing and tracking supplier performance
Exporting and sharing data with stakeholders
With the main goals of the product set, I moved onto the next step to create the information architecture. Since we knew the MVP was focused mostly on managers, but that at a later point we would have to optimise the flow for suppliers, we created a scalable IA to accommodate for the expansion later down the road.
Many of the decisions below were backed by conversations we had during our interviews. First off, we had to give users a useful overview of their suppliers, to which we added basic customisation features. We’ve introduced tasks and notes, all assigned to users and attached to specific suppliers, so teams can see updates, progress, and what’s left to do at a glance.
Adding a supplier in an SRM is usually a pain since it’s a manual process. We’ve simplified the flow for the users who prefer the manual work, but we’ve also added ‘batch import’ features so multiple suppliers can be added from an Excel file.
To speed up most common workflows, we’ve implemented platform-wide search functionality, critical notifications, and ‘quick add’ capabilities. Last but not least, we’ve made creating and sending performance tracking campaigns a breeze, borrowing good practices from Google Forms and Mailchimp. We also removed the need for other tracking tools by making reporting part of the product.
Wireframe of the supplier list
Adding a supplier in a step-by-step flow
Creating teams in the Settings screen
Wireframe of the report list
After finishing the wireframes I created an InVision prototype, recruited participants working in the industry on Askable, and tested remotely using Zoom. Since most participants were using software not entirely known for its affinity to design, we were confident our approach would stand out.
The participants who tested our prototype confirmed we were on the right track, barely raising any concerns along the way. While we didn’t have the features some of our competitors did, what we kept hearing was how people would prefer a tool like ours because it’s simpler and allows them to get the job done, rather than being full of features but clunky. This validated our design approach, but also our wider product strategy, and gave us green light to continue.
Testing the task functionality
Testing reports and filtering
The design for the app is clean and lightweight. We knew that some customers will have hundreds of suppliers, tasks, and campaigns, so we saw a minimal design as the best way to reduce the potential cognitive overload.
You’ll notice the visual design is nothing out of the ordinary; that was a choice. We took inspiration from the likes of Stripe and Atlassian, which despite not following the latest trends in shadow-usage and gradients, are still thriving. I also wanted a design that won’t need a make-over in two years because the trends have shifted. Choosing a simple and conservative visual language built on solid design practices, instead of buying into shiny visual design that requires more investment over time, was the right choice for an enterprise tool.
The dashboard of Waasla
Step-by-step to creating a supplier manually
Managing teams and users
Quick add menu available throughout the whole app
Outcomes and lesson learned
There has been a positive response to the MVP, and the company is onboarding customers as we speak. Just like we’ve seen in testing, Waasla simplifies supplier management, saves time, and allows managers to keep on top of their teams.
This was one of the first time I’ve tested a product entirely remotely, and while it does come with extra challenges, it’s not the last time I will do this. The logistics are much simpler, it’s cheaper than a live session in a professional lab, and although you’re not sitting in the same room as the participants, their facial expressions and reactions are just as clear.