Patrik Jensen

With Aida, our AI website builder, we shifted focus away from designing individual screens. Instead, we defined the principles, components, and constraints an interface is built from, so the right interface can be assembled rather than hand-drawn screen by screen. This means research, clarity, and judgment matter more than ever, since AI cannot do that thinking for us. I've also set clearer principles and feedback systems, so people feel more ownership of their work, and I partner closely with our director of product design and the leads for design ops, commercial design, and content design to keep our practice consistent company-wide.

After launch, the usual playbook is to watch analytics, read support tickets, interview customers, and prioritize from there. For Aida, we added two new sources of evidence: AI agents that interview customers right after they use the product, and analysis of the conversations customers have with Aida itself. Analytics show where people struggle, but rarely why. The interviews and sentiment analysis gave us that why, in people's own words, including from people we could never have reached before: outside office hours, during team holidays, and in languages none of us speak.

With these new methods, we've made our research more efficient without adding headcount. Less time now goes to recruiting, more goes to analysis, and instead of research happening at fixed intervals, we get a continuous stream of findings we can act on with more confidence.

These changes raised our employee engagement scores (eNPS) and made the design culture stronger. I also shared design thinking through talks, including one at UX Camp CPH on trust, uncertainty, and decisions, and joined several workshops with our CEO. And I made sure user research was part of the roadmap from the start, instead of being added later.

Capture One used to ship four big releases a year, in a way of working inspired by SAFe (a rigid framework built around fixed release windows). As we moved toward shipping features as soon as they were ready, that model stopped making sense, so I drove the shift to a more agile way of working. Part of that shift was introducing hypothesis-driven design: instead of ideation starting from a product manager's brief or a developer's idea, every team began by writing a hypothesis of what we wanted to achieve. That turned ideation into something collaborative, built around a shared goal from day one, with designers facilitating the process.

I initiated Airtame's first internal design system, which one of my designers brought to life. It made our product teams more consistent and faster. This was also my first time working closely with hardware designers, connecting their work with the daily experience of our users. It was a new and challenging field, but a very rewarding one.

When I joined, our design team was just me and one midlevel designer, coming out of a turbulent startup period with a lot of change in both people and process. My main goal was to professionalize and stabilize the team, so over time I grew it to four: myself as lead, two senior designers, and one midlevel, through a mix of hires and promotions. Getting there took close collaboration with other stakeholders, but just as much internal work: putting the prerequisites in place for an efficient design team, our design system among them.