MinForskning

I joined the project conversation before the client had committed. The team needed to understand what a rebuild could realistically take, how quickly we could move, and how to make the proposal feel concrete enough for stakeholders to trust.

I had not worked professionally in Angular at that point, so the interview included a very direct question: how would I learn it? My answer was straightforward: read the docs, build hands-on proof of concepts, and lean on the fact that product logic transfers even when framework syntax changes. The more decisive part of the conversation became Figma. When the project lead showed me the old system, we started discussing improvements immediately, and the meeting shifted from interview mode into first-day project mode.

The old product was mainly an admin tool, with limited functionality and no meaningful patient-facing experience. To understand it, I opened the existing app and worked through it like a brand-new user: mapping core flows, identifying friction points, and questioning which features were essential for hospital staff versus what could be clarified for patients.

That exploration helped us avoid treating the work as a simple screen-for-screen rebuild. The admin app still needed to be practical and budget-aware, but the bigger opportunity was to show how the platform could support the full consent journey: from staff administration to patient communication, digital consent, messaging, and follow-up.

We had about two weeks to prepare the estimate and wanted to go further than a spreadsheet. I created Figma designs for the minimal admin rebuild, then added selected patient-facing flows to show what the product could become if the client invested beyond the bare essentials.

The goal was not to over-design the project. It was to make the proposal easier to evaluate, reduce uncertainty around scope, and give stakeholders a shared picture of the user experience they were actually buying.

The work was shaped closely with the project lead and stakeholders. We kept the fixed budget in view while still making room for better product thinking: what must exist for the first delivery, what would make the system more usable, and what could justify a broader investment from the client.

That balance mattered. The Figma work gave the client something specific to respond to, while the estimate stayed grounded in an incremental delivery path rather than a polished fantasy version of the product.

• The client chose AFRY after the estimate and Figma presentation.
• The patient-facing concept helped expand the conversation beyond a narrow admin rewrite.
• The budget increased because stakeholders wanted the broader product direction included.
• What was initially discussed as a 4-month project became a nearly 2-year collaboration.

Internally, it was a meaningful win for the team and a strong start to my consultant work at AFRY. For me, the case still stands out because it combined frontend adaptability, UX research, visual communication, and product judgment in a moment where trust had to be earned quickly.