KI Innovations AB wanted to understand what Sweden's ADHD medication titration process looks like for the people living through it. Not just clinically, but from the perspective of school staff, patients, and relatives.

I planned and conducted two of the interviews myself, transcribed them, and helped turn the raw material into three personas. I also explored using AI to help organize the qualitative data, mainly to speed up first-pass theme-spotting. The analysis and recommendations still came from the team as a whole.

The clearest lesson came from the interviews themselves: I used to fill silences too quickly, worried a pause meant the question hadn't landed. Learning to just wait and let someone finish forming what they wanted to say got me noticeably better answers than any follow-up question would have.

I built the system before touching a single screen. Colors first: a primary and secondary palette, a neutral gray scale tinted toward my primary hue for cohesion, and semantic colors for error, success, and warning states. Then type: a five-style scale, each with a defined job rather than picked by feel. Only then did I build components: a status row with Live/Offline variants, a button with Primary/Secondary/Disabled states, a search bar, and a toggle. Each one had real interactive states, not just static shapes. That became three screens: a home feed, a creator detail page, and settings.

The Follow/Following button: two states built from the same component, not a "disabled" look, because the action needed to stay reversible. A truncation fix on the games-played field, after I noticed long game names were breaking row height across the list. Small thing, but easy to miss if you're not actually testing with real content. Probably what matters most, though: every color, spacing, and type value in the file traces back to a defined system, not something I eyeballed.

Not following

Following

Flatwave AB gave our class the brief. Our team chose to study pub quiz hosts, people who run quizzes weekly and professionally, with real stakes if a night falls flat. We used netnography, scraping and analyzing real Reddit discussions instead of relying on review data for existing quiz tools, since that data turned out to skew toward hobbyists rather than our actual segment. The question we were answering was blunt: is there a real enough gap here to justify building something, or not?

I led the AI-assisted filtering process, which narrowed roughly 700 scraped evidence points down to 33 across four iterations, and wrote up that section of the report. I also ran one of six comprehension tests. The part I'd flag: AI tends to agree with whatever framing you feed it, so I deliberately wrote prompts that invited pushback instead of confirmation, and ran a parallel manual pass to sanity-check what it surfaced.

The comprehension tests turned up something we hadn't expected — an adjacent segment (hobbyist quiz-makers) responded to our value proposition differently than our core segment did, and the real differentiator turned out to be frequency and time pressure, not just interest in quizzes generally. Six people tested it: three said yes to our value proposition and three said no, and one thing came up again and again: nobody wanted pre-written questions handed to them. They wanted scaffolding to build their own, faster.

Wingspan, a B2B platform, had a website that wasn't converting the way they needed it to. An earlier, lighter evaluation happened as part of coursework. This case is about round two, which happened afterward, running parallel to school.

I led the moderated usability tests: I wrote the test script with three task scenarios, used the think-aloud protocol, and kept my mic muted while people worked through the tasks so I wasn't accidentally leading them. Alongside that, the team ran a heuristic evaluation against Nielsen's 10 usability heuristics, a competitive analysis (each of us analyzed one competitor), a survey, and a card sort, before we synthesized the findings through affinity mapping and thematic analysis.

That synthesis became five priority recommendations, mapped on an impact/effort matrix so Wingspan could see what was worth doing first.

The part I'm proudest of shows on their live site. The old homepage leaned on headline numbers and short quotes, and we argued that figures alone don't earn trust: for the social proof to work, visitors need real customer case studies they can dig into before they believe the numbers. Wingspan's launched homepage now leads its results section with customer case studies, each with a starting point, results, and a quote, plus a link to the full story.

During my third year in Game Design, I was project manager and game designer in a team of three, on a project commissioned by Region Gotland. The goal was to develop an app that combined surveys with engaging mini-games to better understand students' aspirations and address low interest in higher education.

Before designing anything, Region Gotland's head of education briefed us on why the project mattered. After that we had regular stakeholder meetings with her and the region's project leader. It was also the first project we'd had with a real budget, so the scope had to fit it. We playtested in classrooms with students aged 10–18. The final product let administrators create surveys, followed by a rotating "mini-game of the month" to keep students coming back. Due to time constraints, the games were inspired by existing successful concepts, with original art and gameplay tweaks.

The two user flows above are what I'd point at. I mapped the app screen by screen for each role, a student answering a survey and an administrator building one, and noted what had to be on every screen. With a real budget to fit, those flows were also how we argued over the backlog: what shipped, what waited, what got cut.

One thing in scope was a high-score list for each game. We ran out of time and budget before building it, and looking back I'm not sure it belonged. In an app meant to get students to answer surveys properly, it pulls attention toward the game and away from the questions, so I'd want to test that before building it.

None of this was called UX at the time — it was a game design degree — but user flows, a prioritized backlog and testing with real users are the core of UX work.

This was one of my earlier projects, from a few years back, and my role was split between project management and design. We worked in Scrum, and I planned our daily stand-ups, sprint planning and sprint reviews, managed the backlog in Trello, and helped source sound design. Most of my time went into playtesting, and that's where the design side came in: running the game myself and with others to find where the mechanics needed tightening, and catching bugs along the way.

My goal was to make the game feel as good as possible while staying accessible to casual players, our target audience. That meant deliberately playtesting as a casual player would, which got harder the better I got at my own game. Most of what came out of that work were concrete design recommendations, each one built on spotting where the game's difficulty or feel didn't hold up for someone playing casually.