Mina Damnjanović

Client handed us a massive Excel file with 400+ entries from 100+ countries, each packed with dozens of attributes.

Researchers and total newcomers. Now used in university lectures.

Grew the prioritization thinking (the Core Issues direction), proposed the fix for the overcrowded map, and co-designed the map and filters.

Interactive world map where users could browse every case, all of it visible, clickable, and filterable. But that's the trap. Do that and you get a product that technically works and is just as unusable as the spreadsheet it came from.

We dug into the dataset and audited how similar platforms handle this kind of data. The pattern was clear that most fail in the same ways: too much data → people bounce. Maps → overlapping pins, endless zooming, no overview. Filters too shallow for researchers, or too jargon-heavy for everyone else. Academic terminology → a wall for the general public.

Every protest, wherever and however it happened, started with a core struggle. So instead of organizing around how people protested, we organized around why. I pulled out nine Core Issues as the backbone so it can be emotional enough for a newcomer to connect with but also precise enough for a scholar to trust.

Most similar platforms fell apart here. I proposed clustering by country instead of one pin per protest: one pin per country, showing the number of actions, colored by that country's most common Core Issue. Result: the whole world readable at a glance. Clicking a cluster opens a light tooltip (the feel borrowed from Figma comments) that drops you into the cases.

Cut filters to five, hide the rest — Core Issue, Tactic, Opponent, Time, Country up front. Deep-search experts can still go all the way down, and everyone else isn't scared off on arrival.

Growing each day, CANVAS keeps adding new cases and they rely on it. It's been used in university lectures and seminars, and became a shared reference point, not just a database. What I'd do differently: stay closer to the build.

Designed the entry point that brings Stocks & ETFs trading into N26's banking app & made it safe for first-timers and not limiting for the pros.

Beginners and experienced traders.

Research and in-house testing (~20 participants), explored the entry-point flows, and wrote the in-flow microlearning copy.

Bring trading into a banking app in a way that feels safe and simple for beginners with low financial literacy (who find trading intimidating), and experienced investors (who don't want to be over-protected). Unlike N26's existing crypto feature, securities trading came with stricter rules and higher stakes, so safety steps and disclosures had to be built into every part of the flow.

Trading feels scary to most people, so I started by understanding that fear using surveys, competitor research, and prototypes tested on UserTesting.com. We also ran cross-functional workshops (designers, PMs, engineers, data, brokers) so the whole team felt the user's fear and confusion firsthand, not just read about it. The pain points clustered around:

• Scary jargon and complex terminology that discouraged exploration.
• Confusing processes for beginners.
• Flows and options too basic for advanced users.

The key insight: beginners need guidance, but over-protecting them frustrates experienced users. So we started simple, and then let people unlock depth as they grow into it. One product that meets the needs of a nervous first-timer and a confident trader.

The hardest question was how to pull in users into the trading while making them (and their money) feel safe and making sure they are aware of the risks. We explored three entry flows: a dedicated space that builds buying power first, a separate fundable trading portfolio, and a direct path from the main account. Narrowed down to the two worth testing, with structured tasks and hypotheses on UserTesting.com.

Instead of a manual, inline microlearning explained terms right as they appear.
Slide-to-confirm before a trade that prevents slips, and quietly reinforces that trading carries risk.
Always-visible account cues so you can always see how much you have and how much is at risk.
A set of starter options/fewer choices that helped beginners, but still not so few that it would frustrate experts.

Paused before launch for business reasons, but the learnings live on in N26's current trading feature.

Rebuilt a confusing internal CMS into something Calendly's editors can actually navigate. Clear flow, fewer steps, real control over their content.

Calendly's internal editors and content teams. Shipped March 2026.

Led the redesign (direction, decisions, and handoff).

It worked technically but it was confusing. And the catch was that it's built on Payload (a headless CMS), where even small changes ripple through the whole flow, so there were limitations. Better UX had to fit inside Payload's structure, and in a short timeline. Clear flow, fewer steps, real control over their content.

Auditing the old CMS, the problems stacked up fast:
No clear hierarchy. The flow, the copy, the layout were all confusing. It was never clear what a page was for, or what the editor was supposed to do on it.
Too many steps and clicks, and weak control over the actual content.
Underneath it all, small quirks in the Payload build had an effect on the whole experience.

With limited time and a rigid system, I focused on what mattered most. Make it obvious where you are, what the page is for, and what you're meant to do, and make moving to the next step easy. Clarity over cosmetics: when an editor always knows their place and their next action, half the confusion disappears on its own.

Some components genuinely weren't user-friendly but couldn't be changed, because of Payload's limitations. Where I couldn't fix the component, I fixed everything around it (hierarchy, labels, contrast, the path through it) so they did less damage. Designing within the system, not pretending it wasn't there.

Still early but first impression is that editors got real control over their content (editing, translations, uploading..) with a flow that makes sense. What I'd do differently: get to grips faster with the components Payload won't let you touch. If I'd mapped those constraints sooner, I'd have had more time to find better workarounds instead of accepting a few compromises just to make the deadline.

A B2B platform that manages vehicle-fleet servicing invoices and requests flow in from garages, get checked against agreed rules, and get verified by a human. I worked where incoming requests are reviewed, and the place where the pricing rules behind those checks are set.

Internal reviewers, who process incoming requests and catch errors fast, and garages, who need a clear view of the conditions that apply to them in their own terminology, not internal codes.

Owned features end-to-end, from picking apart dense info and rough prototypes to shipping the final UI and staying during the build.

The operator's screens are overflowing with information, alerts, actions and numbers all firing at once, everything screaming for attention at the same time. On the review side they had little room to actually manipulate the data they were checking, on the pricing side there was no clear way to set discounts ahead of time and plan. I designed two features to calm that down: clean the screens up, put things away until they're needed, and give operators just what they need at the right moment. One makes reviewing and reorganising a request flexible and direct; the other lets them set conditions in advance with a clear view to plan around.

I designed features to calm that down: clean the screens up, put things away until they're needed, and give operators just what they need at the right moment. One makes reviewing and reorganising a request flexible and direct, and the other lets them set conditions in advance with a clear view to plan around. Features are in development, and the early signal is good: operators have said they're satisfied with the updates so far.