How I Work

How I Approach Design

Over 18 years, I've learned that good design isn't about following a fixed process—it's about asking the right questions and adapting your approach to fit the situation.

Design as Questioning, Not Just Answering

I believe design starts before anyone asks for a mockup. It starts
with questioning the problem itself. Are we solving the right thing?
Who's this actually for? What would success look like?

The double-diamond model represents this well: you need space to
explore the problem before narrowing to a solution, then explore
possible solutions before narrowing to implementation.

This isn't just theory. At Ebury, questioning assumptions about what
finance teams actually needed led us to redesign workflows that seemed
"fine" but created hidden friction.

→ See how this played out: Building Ebury's Design System
→ Read more: Not a single design process

Research: Understanding People and Context

Understanding people means going beyond demographics and personas. It
means watching how they work, what frustrates them, what workarounds
they've invented. Context matters as much as the person—a great design
for a calm office can fail completely on a factory floor.

I use whatever research method fits the question:

  • User interviews for understanding motivations and mental models
  • Usability testing for finding friction points
  • Analytics for seeing patterns at scale
  • Contextual inquiry for understanding actual workflows in real environments

At Ebury, I combined behavioral analytics with user interviews. The
data showed us where people struggled; the conversations told us why.

→ See the approach: Data-Driven Design at Ebury
→ Read articles: Visualizing User Experience Data (Part I & II)

Prototyping: Everything is a Prototype Until You Prove It

I prototype to learn, not to show off. The fidelity should match what
you need to learn:

Low-fidelity prototypes for discussing direction, proposing ideas,
exploring possibilities. Quick sketches and flows that take minutes,
not days.

High-fidelity prototypes for testing realistic interactions,
communicating to developers, demonstrating actual product behavior.

Code prototypes when you need to test technical feasibility,
performance, or integration with existing systems.

The goal isn't perfection. It's learning enough to make the next decision.

At Monoceros, prototyping Fonos meant building functional voice
interactions early to test if the editing model actually worked.
At ITRS, I prototyped the direct manipulation of data visualizations
to prove the concept before committing engineering resources.

→ See examples: Fonos TTS Editor case study
→ See examples: Valo real-time analytics case study

Testing: Reduce Uncertainty, Don't Just Validate

Usability testing isn't about proving you're right. It's about finding
out where you're wrong while it's still cheap to fix.

Based on ISO 9241-11, usability means:

  • Effectiveness: Can people complete their tasks?
  • Efficiency: How much effort does it take?
  • Satisfaction: How do they feel about the experience?

I combine techniques based on what I need to learn:

  • Moderated testing when you need to understand thinking and decision-making
  • Unmoderated testing when you need scale and natural behavior
  • Analytics for understanding patterns across many users
  • A/B testing for comparing specific alternatives

The point isn't just to find problems. It's to understand why they
happen so you can fix the root cause, not just the symptom.

At Ebury, we tracked task completion rates and error patterns, then
followed up with users to understand what caused the friction.

→ Read my article: Measuring UX using your own tools
→ See application: Data-Driven Design at Ebury

Strategic Design: Create Products with Purpose

At the senior level, design isn't just about making things usable—
it's about making things worth building in the first place.

My strategic approach:

  1. Research: Understand the audience, competitors, and market opportunities
  2. Speculate: Envision your ideal audience and how your product would help them
  3. Prototype: Test ideas quickly and cheaply to identify what works
  4. Build: Move into tactical design and implementation
  5. Facilitate: Build empowered teams that can execute autonomously

The hardest part of strategy is saying no to good ideas to focus on
great ones.

At Honest, when the initial customer service assistant didn't validate,
we had to restart research and find the real problem worth solving.
That led to Skate's email collaboration approach.

→ See the pivot: Skate case study (team chat for email)

Team Leadership: Empowered People Make Great Products

Products are built by people, so team health directly affects product
quality. As a manager of designers and developers, I focus on:

  • Regular 1-on-1s for reviewing personal goals and addressing issues early
  • Clear career paths so people know how to grow
  • Conflict resolution that addresses root causes
  • Team building that actually brings people together
  • Visibility of people's work and successes across the organization

My philosophy: Trust people to solve problems, but give them the
context and support to do it well.

At Ebury, I grew the design team from 1 to 6 people, creating career
frameworks and establishing design culture within an engineering-led
organization. At CSC, I managed a team of 6 designers and 4 developers
working on healthcare systems.

→ See team leadership: My experience at Ebury
→ See team leadership: My experience at CSC

Interaction Design: Making Things Real

I call it "Interaction Design" rather than "UX Design" because UX is
too broad. Every touchpoint with a company affects user experience.
What I focus on is the specific interaction between a person and a
digital interface.

This field has solid foundations in cognitive science, human-computer
interaction research, and decades of practical learning. I build on:

  • Universal principles of design
  • Established design patterns
  • Industry standards and best practices
  • Understanding of how people think and behave
  • Knowledge of front-end technologies and constraints

I have experience designing:

  • Graphical User Interfaces (fintech, healthcare, developer tools)
  • Voice User Interfaces (Lingokids Alexa Skill)
  • Multimodal Interfaces (combining voice, visual, and gesture)

Having a technical background helps. I can prototype my own ideas
when needed and understand the technical implications of design
decisions.

→ See GUI examples: Ebury, Valo, healthcare systems
→ See VUI examples: Lingokids Alexa Skill, multimodal interfaces
→ Watch talk: Multimodal Interfaces (T3chFest 2023)
→ Read article: Designing browser extensions

What Makes Me Different

Most designers come from visual design or research backgrounds. I
came from software engineering. This means:

  • I understand technical constraints and can design within them
  • I can prototype interactions with code when needed
  • I speak the same language as engineering teams
  • I naturally think about scalability and systems

But I also invested years learning design craft: studying cognitive
science, conducting research, building design systems. The combination
is useful when you need someone who can think strategically, design
tactically, and bridge between disciplines.

I started as a web developer at Trevenque, moved into design at CSC,
and have been bridging both worlds ever since.

→ See my background: Experience & CV
→ Read my journey: About page

When We Work Well Together

I work best when:

The problem is complex with competing constraints (not obvious solutions)

  • You need someone who can think at both strategic and tactical levels
  • Technical feasibility is a major consideration
  • Cross-functional collaboration is critical
  • You're building something that needs to scale
  • There's ambiguity and no obvious "right answer"

I'm probably not the right fit if you primarily need:

  • Pure visual design or branding work (I can do it, but specialists are better)
  • Execution on predefined specs without problem-solving
  • Deep specialization in one narrow area

The projects I've enjoyed most: Ebury's design system (complex,
cross-functional, scaled), Valo's direct manipulation (ambiguous,
innovative), Fonos (0-to-1 product with technical constraints).

→ See examples of complex problems: View my work
→ See what drives me: About page
→ Get in touch: Contact page