How I approach design across different environments, products & constraints.
My design process is not a fixed sequence of steps. It is a framework that adapts to the context — the type of company, the maturity of the product, the complexity of the domain, and the constraints of the team. Over 14 years of working across corporate enterprises and early-stage startups, I have learned that the best process is one that serves the situation rather than the other way around.
What stays consistent is the underlying principle: understand the real problem before designing anything, involve the right people at the right moments, and validate with evidence rather than assumption.
Startup vs Corporate
In a startup environment, speed and focus matter above everything. At Metrosoft, a 20-person company building fund management software, there was no design process when I arrived. The team needed structure, but not bureaucracy. I introduced a weekly design sprint — a five-day rhythm from problem definition through to client-ready deliverable — that gave the team enough structure to solve problems consistently without slowing them down with heavyweight process.
In a corporate environment like Metso, with a design team spanning two countries and products serving 15,000+ users across mining and process industries, the process needs to accommodate more stakeholders, longer timelines, and greater technical complexity. Research cycles are longer. Design system governance matters. Cross-functional alignment requires deliberate coordination. The fundamentals are the same — understand the problem, explore solutions, validate, deliver — but the cadence and depth at each stage scales up significantly.
New Product vs Redesign
Designing a new product and redesigning an existing one require fundamentally different starting points.
When I joined the Fishtail trade finance platform project, the product was being built from scratch. The process started with deep domain research — understanding trade finance workflows, conducting 30+ user interviews, and building personas for both trade finance managers and borrowers. From there, I moved through user flows, wireframes, and into high-fidelity designs, with the IBM Carbon design system providing the foundation. The emphasis was on getting the information architecture and core workflows right before investing in visual detail.
When I worked on Metrics 2.0 at Metso, the challenge was different. Metrics 1.0 already existed, with a live user base and an established design system. The process started with evaluating what was and was not working — conducting remote usability sessions, speaking with product owners on-site, and auditing the existing design system. The redesign was not about starting over but about evolving what was there: improving the onboarding experience, introducing role-based default views, and refining the design system to support new interaction patterns. Respecting what already worked while fixing what did not required a more careful, evidence-led approach than a greenfield project.
For Crusher Mapper at Metso, I inherited a product that had been designed and built entirely by engineers with no designer involvement. Before I could propose any changes, I spent two to three months simply learning the domain — the machinery, the sensor technology, the operating environment. Only after I understood what the product was doing and why could I identify where design could add value. The lesson here is that redesign sometimes starts with deep listening rather than immediate action.
The Core Phases
While the depth and duration of each phase varies by context, my process generally moves through the following stages.
Discovery and Research
Every project starts with understanding the problem space. I use a combination of qualitative and quantitative methods depending on what the project needs.
Qualitative research — user interviews, contextual observation (remote or in person), stakeholder conversations, and journey mapping. At Metso, this meant regular conversations with product owners on-site who had direct visibility into engineering workflows. At Metrosoft, it meant speaking with the client relations manager and developers to understand where communication was breaking down.
Quantitative research — surveys, usability metrics, task completion analysis, and support ticket data. At Metso, comparing manual report generation times against automated workflows gave us the 35% task completion improvement figure for Crusher Mapper.
I use Dovetail as my primary research repository — tagging, classifying, and organising findings so they are accessible to stakeholders and can be revisited as the project evolves. For the Employee Experience initiative at Metso, the Dovetail repository became a living resource that managers across the organisation could access, explore, and contribute to.
AI-assisted research — I use Claude to help design interview question sets, refine survey structures, and accelerate the initial synthesis of qualitative data. After conducting interviews, I feed transcripts and notes into Claude to identify emerging themes and contradictions across participants. This reduces the time spent on first-pass synthesis and allows me to focus on the interpretive work that shapes design direction.
User Flows and Information Architecture
Before any visual design work begins, I map the user flows and information architecture to ensure the product structure reflects how users actually think and work — not how the organisation is structured internally.
At Fishtail, this meant mapping distinct flows for trade finance managers and borrowers, ensuring each user type had a clear, intuitive path through the platform without unnecessary complexity. At Metso, it meant understanding how field engineers, product managers, and product owners each needed to access the same underlying data in fundamentally different ways.
I use Figma for all flow mapping and architecture work, keeping it alongside the design files so the rationale behind structural decisions is always visible to the team.
Design Exploration and Iteration
This is where ideas become tangible. I work through wireframes first — quickly and collaboratively — to establish layout, hierarchy, and interaction patterns before investing in visual detail. Wireframing is where the most important decisions happen, and I involve engineers and product managers at this stage to catch feasibility issues and alignment gaps early.
From wireframes, I move into high-fidelity design in Figma, working within or evolving the project’s design system. I design for all relevant breakpoints — desktop, tablet, and mobile — and account for edge cases and error states from the outset rather than treating them as afterthoughts.
AI-powered variation — I use Claude Code connected to Figma via MCP to generate design variations more rapidly than manual iteration alone allows. This is particularly valuable during exploration phases where I need to present multiple directions to stakeholders. More options create better conversations, even when not every variation is an improvement. The goal is to broaden the design discussion before converging on a direction.
Prototyping and Validation
I validate design decisions through a combination of usability testing, stakeholder review, and where appropriate, coded prototypes.
At Metso, remote usability sessions where engineers shared their screens and completed tasks in the live platform were a primary validation method. At Fishtail, user testing with trade finance managers and borrowers against prototype versions of the platform provided direct feedback on usability and workflow efficiency.
For rapid prototyping, I use Cursor and Claude Code to translate designs into working code quickly — allowing me to test interactions in a real environment rather than relying solely on static mockups or click-through prototypes. This is especially valuable for complex data interfaces where the feel of an interaction matters as much as its layout.
Design Systems and Documentation
I build and maintain design systems as a core part of my process, not as a separate workstream. At Metso, I led the evolution of the existing design system from Metrics 1.0 to 2.0, evaluating which components were working, which needed redesigning, and where gaps existed. At Fishtail and Itriom, I built design systems from scratch using IBM Carbon as a foundation with custom components layered on top.
A design system is only valuable if it is adopted and maintained. I invest in documentation — component specifications, usage guidelines, interaction notes — and use AI tools to help keep this documentation current without it becoming a time sink. Claude Code with Figma MCP supports this by helping generate and update component documentation as designs evolve.
Delivery and Handoff
I work closely with engineering teams throughout the process, not just at handoff. By involving engineers early — in wireframe reviews, feasibility discussions, and prototype evaluations — the transition from design to development is a continuation of an ongoing conversation rather than a cold handover.
At Metrosoft, the structured weekly sprint meant that engineering review happened every Thursday, with solutions refined based on technical feedback before being finalised on Friday. At Metso, I worked directly with both the in-house engineering team and the external Swedish agency responsible for Crusher Mapper to ensure design decisions were implemented faithfully.