I work where product complexity, customer decisions and digital implementation meet.

I help product companies make complex product lines easier to understand, compare and choose.

My work sits between diagnosis and implementation. I investigate how a product system actually works, identify the decisions customers need to make, and determine where the current digital experience supports — or fails to support — those decisions. When implementation is justified, I carry that work into information architecture, UX, product content systems, frontend development and verification.

The identity details on this page are supplied directly by the practitioner and verified before publication.

Advice that stops at a document rarely survives implementation. Priorities shift, details get lost, and the shipped result quietly diverges from the diagnosis.

Implementation without diagnosis has the opposite failure: it starts with a guess — a template, a feature list, a redesign — and hopes the decision problem was real.

This practice exists in the gap between the two. The same person who establishes what is true about the products also designs the system, builds it, and verifies the result — so nothing is lost in a handoff, and nothing is built before it is understood.

I don't assume a redesign is the answer.

I don't prescribe a finder because a catalog looks complex.

I don't treat more information as automatically better.

I first establish what is true, what matters, and what customers actually need to decide.

Diagnosis remains independent from the desire to sell implementation. If the existing system already solves the important decision effectively, unnecessary complexity is not added.

Thule’s rack system asks one question before it shows any product: what do you drive? The answer determines everything that follows — which racks fit, which attachments are possible, whether the whole setup carries the intended load.

The compatibility decision is not left for the buyer to reconstruct across product pages. It is resolved at the entry point, and every later choice inherits it.

Product data, commercial information, internal documentation and project deliverables are treated as confidential by default. I do not publish client names, screenshots, internal findings or project materials for marketing purposes without explicit permission.

Client work is not treated as marketing inventory.

Public examples on this site are intentionally limited to method demonstrations and material cleared for public use. What a company sells, how it struggles, and what it asked me — none of that becomes public content here.