Mapping out the user needs
Milkywire, 2025
Role
Lead Designer, project lead
Duration
2 weeks
Team
1 designer, 1 PM
Context & challenge
In the spring of 2025, I was assigned a project. "We need to re-package our B2B platform, focus on the low-hanging fruits." Milkywire had pivoted quite a bit, and the new platform was a bit of a mess. I'm not a fan of re-inventing the wheel every time, I still argued that our product wasn't serving the needs of the current users, and picking some fruit wasn't going to solve the problem.
Goals
- Find out what the users actually need to do their jobs.
- Focus on added value, not added
features.
The process
Starting off with what we know
During my time at Milkywire, we've done quite a bit of research. We've talked to users, had long qualitative interviews with sustainability managers and partners. From all of this information we've created quite information heavy partner insights.
As Milkywire has grown and pivoted, the insights had become a bit outdated, and fuzzy. While the impact product (our funds and expertise within sustainability) had seen a lot more traction, the tech product was still not up to par.
So I gathered all of the insights we had, which was quite a bit, and structured the most important jobs to be done into four categories.
Our current users are looking to Find, understand and use:
- Their impact
- Communicate about it in an easy way
- Learn and educate, both internal and external stakeholders
- See where their money is going
What do we have?
Based on the insights, I then mapped out our current product, and categorized the features into the four categories.
The current state of the product was barely scratching the surface of the user needs. Leaning heavily into the Learn and Contribution categories, which isn't really surprising since it's the easiest part to implement. It's also the part that's the least important to the users, and maybe hardest to productify.
Feature and information prioritization
We now know what the users want, and what we have today. The next step was to prioritize the features and information that would add the most value to the users. I started out with some open card sorting sessions, where the users sorted the features into categories of their own choosing. After two sessions, I decided it was enough, open card sorting might work well for an e-commerce site, but not really for a B2B sustainability platform.
Instead I ran closed card-sorting sessions, where I presented the same features and information to the users, and asked them to sort them based on importance for each job to be done. With that we had a clear picture of what information and features are important for each job to be done.
Each user was told to mark all relevant/helpful features and information, and 5 must-have cards.
- What do you need to understand your impact?
- What do you need to understand your impact?
- What do you need to learn about the fund that your supporting?
- What do you need to be able to report and communicate your impact?
Cleaning and wireframing
From the card sorting sessions, I cleaned the data and structured it. I then created a list of features and information that would be most important to the users. I then cleaned up the information architecture, and created wireframes for the most important features and information. What is connected to what user need, and how does a user best achieve their goals.
Informed decisions
With the new wireframe I set out to create a product plan for the MVP, I wanted to make sure I was covering all the bases, and that I was prioritizing the right things. With the new learnings and user insights, we decided to move focus away from the portal, and towards improving and optimizing our impact product instead.
Although it might not sound like it, I really like the outcome. Instead of trying to polish something that's clearly not providing the value it should, we're now able to put our efforts into a product that users are asking for and need.
It's important to step back and evaluate the product every now and then, and not just keep pushing features out without validating that they're actually needed.
Next project