How I work
I’ve hired designers myself, and know that if you’re reading this, you’ve probably seen your fair share of portfolios full of post-its and jargon. So I’ll skip the fluff and just tell you how I actually work, what I believe in, and how that’s helped teams ship better across products.
I’ve broken it down by phase, but like any real project, these often overlap.
TL;DR
There’s no one right process and perfect conditions rarely exist. Every product, team, and timeline is different. My job is to adapt, but also to use good judgment: knowing where to go deep, when to move fast, and how to make the most of the time available to create something that works for the user and the business.
Brief
I’ve both written and received a lot of briefs. The best briefs frame the problem and define success but leave the solution open. That’s where creativity and team insight comes in and leaves room for autonomy and better outcomes.
When I lead or scope work, I push for clarity of purpose: what are we solving, who are we solving for, and why does it matter now?
Ideation & Design
Once the brief is established and agreed upon, I zoom out, talk to stakeholders and explore the edges. That includes reviewing data, analysing competitors, talking to users and identifying edge cases. I will more often than not jump into rough visuals as soon as possible as from my experience that unlocks better conversations, faster
That might be a quick sketch or a flow in Figma. If there’s a design system, I’ll use it to move quickly and stay grounded in reality. The goal at this stage isn’t polish, it’s momentum and alignment.
For example; at Matchday, I often delivered rough prototypes to execs within 24-48h of the brief. Some of these reframed the original pitch entirely, unlocked leadership buy-in, and defined the roadmap.
Feedback
I don’t wait for perfection; I share early and guide feedback. Lately, I’ve leaned into async feedback loops, like video walkthroughs, to speed up validation when availability is tight.
Good ideas can risk dying in the weeds, so I guide feedback sessions to focus on what matters most at that time. When needed, I’ll step in with “Let’s park that and revisit later” to keep momentum and focus. When feedback conflicts, I frame it around user goals and product priorities, keeping us focused on what matters most.
Over time, I’ve developed a strong sense for when and how to bring in stakeholders, and what kind of input is actually useful at each stage.
Collaboration
I work closely with PMs to shape problem definitions and clarify scope, and with engineers early to understand what’s feasible - or help make it so. Sometimes the best solution isn’t the ideal one; it’s the one we can ship today and build on tomorrow. I like working closely with engineers and producers to find those tradeoffs without compromising user value.
I’ve also partnered with analysts, QA, and marketing teams to make sure what we design makes sense beyond the screen. Good design happens between disciplines.
Iteration
Iteration starts from day one. I trust my instincts to set the early direction, but stay flexible and adapt as the work evolves.
Things break in testing and and that’s expected. What matters is having a strong foundation and a fast path to iterate. I usually have a Plan B (and C). The goal is progress, not perfection.
For example; we were struggling with first-time user retention at Matchday. I designed a dynamic system inspired by Instagram Stories, making it easy to test onboarding variations quickly and improve how and when we surface info. This system helped us iterate and push D1 retention from 33% to 48%.
Prototyping
I love a good Figma prototype for exploring flow and getting early feedback. But when things get complex, I’d rather build something real. When tools get in the way, I find paths forward that enabled reaching the required fidelity; whether that’s pairing with a dev or coding a quick prototype myself.
I’ve been building HTML/CSS/JS prototypes since the start of my career, and I still do when it helps speed things up. Tools like Cursor or Claude Code have only made that faster.
For example; at Sports Interactive, I built full interactive prototypes for each major UX overhaul - giving us a way to validate ideas before implementing them at scale.
Implementation
I stay close to engineers during implementation - pairing, giving feedback, and helping fix issues when needed. Handoffs help set direction and getting things started, but real alignment comes from staying involved and pushing for the best possible outcome within constraints.
For example; at Sports Interactive I often worked in the game’s custom XML based engine helping fix front end bugs and ensuring polish during critical phases.
Validating
Design isn’t done until it’s tested. I’ve run structured usability tests, community- and internal play sessions - whatever helps us see how things actually land.
Every type of test gives us something. I value feedback over ego; if something breaks, I distill the findings it to clear next steps, fix it fast and move forward.
For example; one of my earliest usability wins was in Football Manager 15 years ago. Users struggled to find the Save button in a menu, so I tried replacing it with the FM logo as the entry point. There was initial skepticism, but in testing, it just worked. That same pattern is still in the game today.