
Data Intelligence Platform
UX Design, Design Systems, Leadership
_
Ten teams, seven cities, three frameworks, and a style guide everyone technically followed. I found that better guidelines were not the fix, documented reasoning was.
What I'd Do Differently
Getting buy-in to validate before building took longer than building the design system itself, because "test it first" read to some engineers as an extra step rather than a way to avoid rework. In hindsight, I would have led with the speed argument from day one rather than the completeness argument: the whole point of recruiting consultants closest to our Beta customers was that their feedback was fast and cheap, and that is a stronger opening line than "we need to validate this properly".
What I would keep exactly as it was: the written reasoning. Rules people can ignore under deadline pressure. Reasoning they have actually seen is harder to argue past, even from seven time zones away.
Outcomes
Questions people usually ask
Expand all
What does complex, large-enterprise B2B SaaS experience actually give me, and would I still move fast enough for a smaller team?
How do I work when the brief isn't clear yet, and what part of the job do I enjoy most?
How do I actually strengthen a team, and will I get hands-on or mostly direct from a distance?
What did I do with the time between roles, where do I stand on AI, and what am I looking for next?
How has living abroad shaped me, both as a person and as a principal design lead?






