A tale of two problems
The small one was mine. I joined an engineering-only team building fulfilment, the new strategic pilot service, and the priorities were set by the most painful incident of the week, whether or not that issue would repeat in the next month or even quarter, when so many basic things were still pending to be built.
The big one belonged to the whole company: the focus was on what competitors shipped, and much less on the pains of our own users.
I set out to solve the small problem. What I didn't know yet is that the same tool would end up fixing the big one too, once everyone else came on board.
The shift
My biggest contribution was laying the foundation of the system: how to count a pain point and how to quantify the pain level. Then, as more and more colleagues jumped on board, each one of them brought new uses, and adoption expanded to all levels and departments of the company: from the Customer Service agent to the CEO.
-
My first pain points database started as a result of mapping the fulfilment user journey and identifying the pain points along the way. The breakthrough came when the logistics team worked with me on building and maintaining this map. It was the first example of a smooth cross-functional collaboration across departments.
Stage 01 One squad + the logistics teamMy role designed the method and the first map, facilitated cross-functional collaboration.Collaborators -
I spread the methodology across the product team, which meant other parts of the user journey started getting mapped. At first it was only three of six squads, but at this stage I got on board two key allies: Marcelline (UXR) and Lydie (Sr PD).
Stage 02 Three of six product squadsMy role taught the method, ran the workshops, mapped alongside other designers.Collaborators -
The insights database was born. As the value of keeping track of user pain points became clear, multiple sources of user feedback were connected as inputs for pain points: NPS and PMF survey responses, user interview insights, and a Slack channel open to the entire company. Instead of a mishmash of Notion databases, Miro maps and Google spreadsheets, the system was centralised into a Sigma dashboard, available for anyone in the company to explore the data.
Stage 03 Research and data join inMy role proposed linking insights to pain points and scoring; handed over the lead.Collaborators -
The Slack channel that transformed the company. Giving everyone in contact with clients an input point to add new insights to our database was transformational. Suddenly the system was visible: people saw what others posted, talked about it, collaborated on it. It allowed leadership to truly soak in the user pains.
Stage 04 Everyone in contact with clientsMy role Tagging insights into pain points. Promoting internally the use of the slack channel.Collaborators -
The company strategy becomes user centric. At an All Hands, about two years after the first pain point was formulated, the CEO was sharing the latest strategy, and I couldn't believe what I was seeing: the pain points system was its foundation. He declared us a user centric company: first and foremost, we solve our own user base's pains.
Stage 05 Leadership team gets on boardCollaborators -
Automation & business as usual. Once leadership formalised the system as a key tool, prioritising quarterly roadmaps by "pain level solved" became common practice for Product & Tech squads. The system was receiving thousands of insights every quarter, far too many to tag by hand. So we planned agentic AI flows specialised in tagging the data, trained on the insights we had already categorised. I helped plan it and did the handover; engineering brought it to life after I left.
Stage 06 Tech team adopts itMy role co-planned the automation, handover.Collaborators
Nowadays, the system is still in use, supported by AI.
How it works
To move the discussion from opinion-led to evidence-based I mapped the user journey and systematically identified pain points and opportunities, together with the logistics stakeholder.
A pain point is a part of the user journey that causes frustration and confusion. A friction adds unnecessary steps along the way. A blocker doesn't allow the user to do what they expect to do.
Brands have to type in the size of every parcel, on every order
Pain level 9/25
An opportunity is a business opportunity to improve the offering, or an initiative that would improve an existing painless user flow in order to delight or automate.
Suggest parcel sizes from the ones a brand has used before
Both the pain point and the opportunity have been solved.
See how in UX galleryMy user flow mapping process
One pain, many voices
The insights came from very different places:
Sources of insights
- Slack channel open to everyone in contact with clients
- NPS & PMF surveys open answers
- User research interviews, usability tests, surveys
- In-app surveys Hotjar responses
- Journey maps the maps themselves
How insights map to pain points
“negotiate decreasing prices depending on the quantities ordered”
“The impossibility of offering discounts depending on variations or quantities”
Missing discount on volume
“It would be time saving to be able to have 2 prices for the same product. If I have 1 product sold by one at X EUR and sold by 5 at Y EUR for example instead of having to create a whole new product.”
“Offering tiered based discounts would be good. Or guiding brands on how to activate these discounts to us manually. I was going to order from [a brand] with you because they were happy to give me a tier based discount based on my spending but the brand didn't know to do it & it didn't appear on the platform so I assumed it wasn't possible via AKS and I ordered with them direct because it was easier”
The challenge was that each insight had to be cleaned and categorised. At first this was completely manual, and the people in charge (me and my colleague Marcelline) became the bottleneck.
Putting a number on pain
Not all pain points are created equal. Some happen once in a while, others every single time a user tries something. Some are easy to overcome, while others cannot be overcome without a lengthy email thread, three spreadsheets and a phone call.
So I scored each pain point by frequency and intensity. The frequency was the hardest one, as we had to dig for data, and sometimes for proxies, that could inform the rating. Keeping the scale very rough helped us not get muddled into this. Later on, once pain points were connected to insights (stage 3), we added the number of clients mentioning each pain to the formula as well.
Out of 100% of cases, how often does this behaviour happen?
| Score | Share of cases |
|---|---|
| 1 | 0–20% |
| 2 | 21–40% |
| 3 | 41–60% |
| 4 | 61–80% |
| 5 | 81–100% |
How easy is it to overcome?
| Score | Meaning |
|---|---|
| 1 | Mild inconvenience, easy to overcome |
| 2 | Painful, but there are workarounds |
| 3 | Intense pain and no way to overcome it |
How many individual clients mentioned this issue?
| Weight | Clients |
|---|---|
| 1 | 1 |
| 5 | 2–4 |
| 8 | 5–10 |
| 9 | 11–50 |
| 10 | 51+ |
Pain level equals frequency (1 to 5) times intensity (1 to 3), plus insights (1 to 10): up to 25.
Adding a number to a pain point turned out to matter more than I expected. It gave us a common language with the more data-oriented stakeholders, and it gave us in product the arguments to take back the prioritisation.
What it changed
Settling debates with data. Back in my squad, there was one topic that our operations colleagues considered the number one priority. When it happened, it was really painful for them, so it felt urgent. When we looked at the data, it affected maybe 2–3 clients a month. Instead of building for it, we agreed that they would handle it operationally when it happened, and we moved on to pains that affected most of our users. That conversation would have been an argument a few months earlier.
- High intensity / Low frequency Best served by the Logistics operations team
- High intensity / High frequency Best served by the tech and product team
- Low intensity / Low frequency Best solved with other root causes by either team that gets it first
- Low intensity / High frequency Best served by the tech and product team
Roadmapping. Within an area that was obviously painful for the users, we could see which pain points were more urgent than others (higher frequency, more user complaints). This reduced internal debates significantly.
Quarterly OKRs. For problems we knew had to be solved to unblock other revenue-making initiatives, several squads had the reduction in pain level as their quarterly goal. It became the user-centric fallback when no other KPI made sense.
Tracking progress. The rhythm of a squad was made visible in the pain points dashboards, which showed the pain level solved month after month.
Long term strategy. The overview of user pains was used by the CEO and leadership team to plan the company direction.
Closing the feedback loop. Going back to the same clients who had asked for a fix and letting them know it was now live significantly increased their satisfaction and trust.
That is really great news! Small sellers in particular will be glad that individual products can now be listed much more quickly. I'm looking forward to trying out the new feature.
Thank you so much for this message, we're thrilled! This is going to save us time!
That's brilliant!!! Well done to the team, we'll try the feature asap. Thanks!
The users noticed. About three years after the first pain point was mapped, and a year after the product team adopted the system seriously, the tone at trade fairs changed. We stopped hearing complaints about the app and started hearing: "ah, you solved my issue! Thanks so much."
Legacy
On my first week at Ankorstore, I could never have imagined how much a company can change in such a short time. As a designer, seeing it go from competitor focus to user centricity, with the help of a system I laid the foundations of, makes me both proud and hopeful.
Looking back, it worked for three reasons.
- It was adopted at company level.
- It was taught, not guarded; I spent as much time showing others how to use it as I spent building it.
- It spoke in numbers, which is the language that got leadership to listen.
The biggest lesson I take with me is that systems don't work in isolation. Transformation happens with adoption, and when others adopt something you built, they will change it. That's how you know it worked.