Research-Driven UX/UI Designer
Designing clarity inside complex systems.
Every design decision supported by evidence, established UX principles and real user behaviour — not intuition alone. From complex regulated systems to high-impact digital experiences.
Experience across
Safety-Critical Systems
Defence & Radar Applications
Enterprise Design Systems
Consumer Web Products
UX Research & Audits
Background
Rheinmetall Air Defence
UX Designer · Zurich · 2024–2026
Professional Diploma in UX
UX Design Institute · 2022
UI Professional Certificate
UX Design Institute
BSc Informatics
Juraj Dobrila University · Pula
// What people say
Recommendations
MD
LP
// Selected Work
Case Studies
5 case studies · Rheinmetall & Brainest
01 —
Mission-Critical Decision SupportNDA
UX for radar-based air defence — designing what to build before how to build it
→
02 —
Complex Planning SystemNDA
Designing clarity into a constraint-heavy workflow — >50% fewer interactions in selected flows
→
03 —
Hardware Input Device MappingNDAIn progress
Bridging physical controls and software behaviour for low-error operation
Available soon
04 —
Cloud Away — Mindfulness AppIn progress
Breathing & mindfulness app — design lead, in collaboration with Brainest
Available soon
05 —
Dentist App — Patient CareIn progress
Patient-facing dental app — design lead, in collaboration with Brainest
Available soon
// Field Notes
Notes
Thinking on UX, complexity & systems
Complex Systems — Featured
Designing in Constraints: What Safety-Critical UX Taught Me About Good Design
When every design decision is reviewed against military standards and validated through on-site testing with real operators, you learn quickly that good UX isn't about preference — it's about precision, clarity, and zero tolerance for ambiguity.
UX Thinking
Cognitive Load Is Not the Enemy — Misplaced Cognitive Load Is
The goal isn't to reduce how much users think. It's to make sure they're thinking about the right things at the right moment.
Real-world Lessons
From SME Websites to Complex Systems: What the Gap Taught Me
I designed websites for local businesses. Then I designed interfaces for defence operators. The contrast was sharp — and the lessons went both ways.
Research
On-Site With Specialist Users: What Lab Research Can't Prepare You For
Running usability tests in a lab is one thing. Observing operators in a regulated environment is another discipline entirely.
// Who I Am
About
I'm Benjamin — and my path into UX started with a question about people, not pixels.
I was studying computer science when I wrote my bachelor's thesis on how culture shapes the way people experience design. That was the moment it clicked: I didn't just want to build systems — I wanted to understand the humans using them.
Where it started
"Cultural Influence on User Experience Design"
Bachelor's thesis · BSc Informatics, University of Pula
Since then I've stayed a researcher first — I want to understand before I design. My technical background means I speak both languages: I can sit with engineers and with users, and translate between them.
How I work
I don't design based on intuition alone. Every design decision should be supported by evidence, established UX principles, domain knowledge and an understanding of user behaviour.
I'm also a genuine technology enthusiast with an innovative streak — I like pulling new ideas apart to see how they work, and asking what they could mean for the people who'll actually use them.
A few things about me
CurrentlyOpen to new roles
Started asA CS student who fell for design
Best atMaking complexity feel obvious
Based inAarau, Switzerland
What drives me
Research-first
Technical mind
Innovation-driven
Precision over polish
Human-centered
Right now
Exploring how AI and emerging tech reshape UX research and design — and looking for my next challenge in complex, meaningful product work.
"Complexity is not the problem. Unexplained complexity is."
"The best interface for a constrained system isn't the simplest — it's the most precise."
"Good design works the same whether the stakes are low or someone's life depends on it."
Core Skills
UX Research & Testing
Information Architecture
Interaction Design
UI Design & Prototyping
Design Systems
UX Audits
Enterprise Design
Prototyping (Figma)
Education & Certifications
BSc Informatics
Juraj Dobrila University of Pula · UNIPU
Professional Diploma in UX Design
UX Design Institute · 2022
UI Professional Certificate
UX Design Institute
Open to
Complex & regulated systems
Health & med-tech
Enterprise SaaS
Product teams & agencies
// Experiments
Playground
Side explorations & ongoing thinking
Concept
⬡
Error State Taxonomy
Cataloguing how different industries handle error messaging — from consumer apps to regulated medical interfaces.
Research
◈
Hardware + Software Mapping
Exploring the design challenges of physical input devices mapping to software in high-stakes environments.
Writing
◎
The UX Audit Checklist
A personal, evolving checklist built from freelance audit work — going beyond Nielsen's heuristics.
Exploration
⬟
Information Density Study
When is a dense interface the right choice? Comparing operator interfaces across domains.
In Progress
▣
Regulated UX Pattern Library
Collecting UI patterns that recur across regulated industries — how constraints shape interaction decisions.
Prototype
◉
Alert Priority Framework
A model for alert hierarchy that reduces fatigue without hiding critical information.
Case Study 01 · Rheinmetall
Mission-Critical Decision Support
Designing UX for Mission-Critical Decision Support
Overview: Mission-critical operational software for radar-based air defence — an enterprise environment where a design decision has to support clarity, reliability and confident decision-making under strict technical, regulatory and operational constraints. This is a fundamentally different problem from optimising for engagement or conversion: the measure of success is whether an operator can understand a situation and act on it with confidence.
My Role
UX/UI Designer — research to implementation
Context
Enterprise · mission-critical · NATO-related standards
Timeline
2024–2026
// The Challenge
Complex systems can't be designed screen by screen. In this environment, every workflow, interaction and interface is connected to a much larger ecosystem — a seemingly small change can ripple across multiple user journeys, technical dependencies and operational procedures. On top of that, operators work under conditions where a misread value or an ambiguous control isn't an inconvenience; it carries real operational consequence.
So the real challenge was never simply "design a good interface." It was deciding what should be designed at all, then reducing the effort required to understand inherently complex information — without removing the information operators depend on. Every request first raised a larger question: should this functionality exist, and does it solve a real problem?
// Understanding the Domain
Before I could design a solution, I had to understand the environment it would become part of. I never treated research as a single phase at the start of a project — understanding the domain became a continuous activity that evolved alongside the design. My first objective was to understand how people actually worked before thinking about how the interface should work.
To build that understanding, I combined multiple sources
Existing system analysis
to understand current workflows and identify dependencies.
Technical specifications
to understand system behaviour, requirements and constraints.
Stakeholder workshops
to understand business objectives, engineering considerations and operational expectations.
User research
to validate assumptions and identify real user needs.
Task analysis & workflow mapping
to understand how individual actions contributed to larger operational goals.
Whiteboarding sessions
to visualise complex processes, challenge assumptions and explore alternatives.
Each activity answered a different question, but together they gave a far clearer picture of the problem than any single method could. There is no universal research process — the methods I selected depended on how risky the decision was, how much time remained before implementation, whether we had access to end users, and what research already existed. The goal wasn't to perform more research. It was to make better decisions.
"I don't think the quality of my work came from producing better interfaces. It came from making better-informed decisions before those interfaces existed."
PrincipleStrong design decisions are built on strong domain understanding.
// From Request to Decision
One of the most important lessons on this project was that a stakeholder request should never be treated as a validated requirement. Every request represented someone's perspective on a problem — but not necessarily the problem itself. So I rarely started by asking "How should we build this?" I started by asking "Why do we need this in the first place?" That single question often changed the direction of the entire discussion.
I challenged the assumption, never the person
Whenever someone proposed a solution, I tried to understand the thinking behind it before forming my own opinion — why they believed it was the best solution, what problem it solved, how we knew that problem existed, and what evidence supported it. These questions rarely created conflict; they encouraged discussion and often surfaced information that hadn't been considered. Understanding someone's mental model was usually far more valuable than immediately evaluating their proposed solution.
Turning research into decisions
Research has little value if it doesn't influence decisions. Once a problem was validated, every solution was evaluated against user needs, business objectives, technical feasibility, operational constraints and system consistency simultaneously. The strongest solution was rarely the one that optimised a single perspective — it was the one that balanced all of them while protecting the user's primary goal. Over time this became a repeatable sequence:
1Understand the request
2Identify the underlying problem
3Validate assumptions
4Build domain understanding
5Explore multiple solutions
6Evaluate trade-offs
7Validate the approach
8Support implementation
9Review the outcome
PrincipleA stakeholder request isn't a requirement. It's the starting point of an investigation.
// Designing for Cognitive Clarity
One of the biggest misconceptions about designing complex systems is that simplicity comes from removing information. In mission-critical environments, operators often depend on a large amount of information to understand the situation and act with confidence — removing it to create a "cleaner" interface can be as harmful as showing too much. The challenge wasn't reducing complexity. It was reducing the effort required to understand it.
So I didn't start from layout — I started from decisions. Every screen exists to help someone complete a task or make a decision, so instead of asking "where should this component go?" I asked "what does the operator need to notice first?" That question became the foundation for every hierarchy I designed. To set priority, I continuously evaluated:
Task criticality
How important is this information for the user's next decision?
Interaction frequency
How often will the operator need it?
Position in workflow
At what stage does it become relevant?
Mental models & context
Does it match how users expect information to appear — always visible, or only when relevant?
Rather than removing information, I presented it more intentionally: highlighting the most critical first, progressively disclosing the secondary, grouping related information, and reducing visual competition so every element had a clear purpose. I aligned new interactions with the mental models operators had already built — consistency reduces thinking, familiarity reduces hesitation, and both reduce cognitive effort. This mattered most when introducing new functionality into an established enterprise system, where users relied on predictable behaviour during demanding tasks.
PrincipleDon't reduce information. Reduce the effort required to understand it.
// Creating Alignment
Designing complex products isn't just about making good design decisions — it's about helping people with different perspectives make good decisions together. I worked closely with product owners, developers, system architects and fellow UX designers. Each discipline viewed the product through a different lens, and none of those perspectives were wrong. The challenge was ensuring they all contributed to the same solution.
Whenever someone questioned a design decision, my first instinct wasn't to defend my work — it was to understand why they saw the problem differently. Those conversations often revealed something more valuable than the proposed solution: the stakeholder's mental model. I grounded discussions in evidence — research findings, user needs, business objectives, technical constraints, domain standards and existing workflows — so the focus shifted from defending ideas to understanding which solution created the most value.
Every compromise has a cost
In projects of this complexity, compromise is inevitable. The question was never whether to compromise — it was "what are we sacrificing?" If a compromise protected the user's primary task while respecting technical realities, it was usually reasonable. If it reduced clarity, increased cognitive effort or added friction, we needed to keep looking. Compromise should never happen by default; it should happen consciously.
PrincipleThe strongest design decisions aren't defended. They're understood, challenged and validated together.
// Decision Frameworks
The thinking behind the screens. These are the reusable, NDA-safe frameworks I use to decide what to build and how — the same logic that shaped this project.
Framework 01
Request → Decision
How I evaluate every request before designing — from objective to approved solution, with feedback loops.
⤢ View framework
Framework 02
Research Strategy
How I select the right research method to reduce the most uncertainty within real constraints.
⤢ View framework
Framework 03
Information Prioritisation
How each element earns its visual weight — and how cognitive load drops as noise is removed.
⤢ View framework
Framework 04
Design Validation Loop
The continuous cycle from research to implementation and back — design is never "finished".
⤢ View framework
Framework 05
Stakeholder Alignment
How I balance business, engineering, users and standards into one evidence-based outcome.
⤢ View framework
Framework 06
Cognitive Load Reduction
How complex system information is progressively simplified into a clear experience.
⤢ View framework
// Validation & Implementation
A common misconception about UX is that the work ends when a prototype is approved. In my experience, that's where a different phase begins. A validated concept still has to survive implementation — without clear communication, even well-designed solutions can drift from their original intent as they move from design to development. So I never treated implementation as a hand-off. I treated it as a continuation of the design process.
From prototype to product
A prototype demonstrates the experience; a specification explains how it should behave. Rather than documenting only what an interface looked like, I documented why it behaved the way it did — component behaviour, interaction rules, component states (default, active, disabled, loading, contextual), edge cases outside the primary flow, design-system references, and how individual elements composed into one complete interaction. The objective wasn't to document the design. It was to remove uncertainty before development began.
Developers had direct access to me throughout implementation. When technical limitations surfaced that hadn't been visible during design, the discussion wasn't about protecting the original design at all costs — it was about understanding the consequences of every compromise, returning again to the same question: what are we sacrificing? Every implementation discussion resulted in documentation: decisions were recorded and prototypes updated, so the prototype remained the team's single source of truth. Ideas that couldn't be built immediately weren't discarded — they were documented as future improvements so valuable thinking wasn't lost.
Before considering a feature complete, I reviewed the implemented solution against the validated design. The objective wasn't pixel-perfect implementation — it was ensuring the experience users received reflected the reasoning, behaviour and interaction principles that had already been validated.
PrincipleA prototype is only a promise. UX is complete when that promise is delivered in the final product.
// What This Work Enabled
Because of the nature of the project, I can't share specific product metrics or implementation details. But I can describe what the work enabled. Rather than measuring success through a single feature, I measured it by the quality of the decisions that reached implementation: every solution had to solve a validated problem, integrate naturally into an existing enterprise system, and support operators without adding unnecessary cognitive effort.
For the product
Each capability became part of a larger ecosystem rather than an isolated feature — grounded in research and system understanding, so it integrated consistently with existing workflows instead of adding complexity.
For users
Every decision was tested against one question — does this make the user's job easier? Success meant operators completing tasks with greater confidence and less cognitive effort, not visual polish.
For the team
Documenting both what was built and why produced clearer design-to-engineering communication, implementation-ready specs, shared understanding and transparent, consistently validated decisions.
Beyond features
The biggest contribution wasn't individual interfaces — it was helping establish a repeatable way of approaching complex UX problems that still shapes how I work.
PrincipleThe most valuable outcome of design isn't the interface itself — it's a better way of making decisions.
// Reflection
When I first joined this project, I expected the biggest challenge to be understanding a highly specialised domain. I was wrong. The real challenge wasn't learning how the system worked — it was learning how to make confident design decisions in a system where every decision had consequences. Very quickly, I realised designing interfaces was only a small part of my role: before proposing solutions, I needed to understand the environment people worked in, the constraints they faced, and the decisions they were expected to make. Only then could I tell whether a request solved a genuine problem or simply reflected an assumption.
That experience changed how I approach UX. I no longer see design as a sequence of deliverables — I see it as a process of reducing uncertainty. I also stopped searching for the "perfect" solution: real products are shaped by business goals, technical constraints and time, and a successful design is the one that understands those constraints and finds the strongest solution within them. The biggest surprise was how much I enjoyed working in such a constrained environment — instead of limiting creativity, the restrictions forced me to think more critically and justify every decision with evidence rather than instinct.
"Great UX isn't defined by how polished an interface looks. It's defined by the quality of the thinking behind every decision that shaped it — great interfaces are built on great decisions, not the other way around."
Case Study 02 · Rheinmetall
Complex Planning System
Designing clarity into a constraint-heavy workflow
Overview: A planning system where complexity couldn't simply be removed. It had to support highly variable scenarios, interconnected decisions, mandatory domain information and strict technical and military constraints — without overwhelming the person using it. My role was to make necessary complexity manageable, not to make a complex system look simple.
My Role
UX Designer → end-to-end UX ownership
Scope
Research · interaction design · validation · stakeholder alignment · implementation review
Environment
Mission-critical · multi-system · highly constrained
>50%
fewer required interactions in selected flows
Higher
process execution success
Lower
cognitive load across the flow
Modernised
and automated key parts of the experience
// The Challenge
The challenge wasn't removing complexity. It was making complexity manageable. Complexity was not fixed — it grew with the user's scenario. A relatively simple plan and a highly complex one had to coexist inside the same product, while the interface preserved required graphical representations, domain-defined hierarchy, system behaviour and NATO/military standards.
That created a difficult constraint: removing information was often not an option, and showing everything with equal emphasis was not an option either. The existing experience exposed much of that complexity directly — important information could require unnecessary navigation, related actions weren't always positioned around the user's flow, and dense visual information could quickly increase cognitive load.
So the UX had to continuously answer four questions: what does the user need to understand right now? What must remain present even when it isn't the current focus? What does the system consider important regardless of the user's attention? And how does the next step stay clear as the scenario grows more complex?
Diagram 01
The complexity model
Complexity can't be removed — only understood, then made manageable.
Sources of complexity
User-created complexity
System constraints
Domain standards
Mandatory information
Cognitive-
load risk
load risk
→
UX Response
Hierarchy
Context
Grouping
Guidance
Automation
Necessary complexity is preserved — the interface just stops amplifying it.
PrincipleDon't just cut out complexity. Understand it, then optimise it.
// My Role & Evolution
I joined the project as a UX intern, working alongside another designer. As my product and domain knowledge grew, so did my responsibility — I gradually took ownership of the majority of the UX work and eventually became responsible for the project from the UX side.
That meant owning the process end-to-end: understanding and challenging requirements, planning UX work and deadlines, facilitating stakeholder alignment, exploring and comparing design directions, defining interaction and information hierarchy, planning and running targeted user testing, translating validated decisions into component and behaviour specifications, and reviewing the implemented experience against the intended design.
The work remained collaborative. Ownership meant being accountable for the UX direction — not designing in isolation. The biggest shift wasn't from fewer screens to more screens; it was from contributing to decisions to being accountable for the quality of the decision-making process itself.
Diagram 02
From intern to end-to-end ownership
UX Internalongside another designer
→
UX Designermajority of UX work
→
End-to-end ownershipaccountable for UX direction
Learn the domain
→
Shape the experience
→
Drive the process
Ownership meant being accountable for the UX direction — never designing in isolation.
// Learning From Existing Software
The project did not begin with a blank canvas. We analysed existing software and known scenarios to understand why earlier approaches created so much friction. The recurring issue wasn't a lack of capability — it was the cost of reaching and using that capability.
Users could encounter too many steps for relatively simple actions, static information positioned far from the moment it was needed, fragmented functionality that forced unnecessary navigation, high cognitive load from dense graphical and system information, and workflows structured around system logic rather than user behaviour.
That changed the design question from "How do we add the required functionality?" to "How do we preserve the required capability while reducing the cognitive and interaction cost of using it?" That distinction became central to the project.
// Designing Around the User Flow
One of the most valuable discoveries was that information architecture couldn't be based only on categories or technical relationships. I needed to understand the flow well enough to predict where the user would naturally look next — visually and interactionally. Where would their eyes go? Where would their cursor move? What would they expect to find at that moment?
Flow-Driven Proximity
Place information and actions where users naturally look for them within the flow — not simply where the system structure says they belong. Grouping was only useful when it supported orientation; if a group had to be learned as an artificial concept, it wasn't helping enough. In several flows, information that previously required significant navigation could be brought closer to the action it supported. Combined with restructuring and automation, this reduced required interaction by more than 50% in selected flows — not by removing capability, but by understanding which information and actions belonged together.
Diagram 03
Restructuring around the user's flow
Before · 6 steps
Action
Navigate away
Locate information
Return
Change
Continue
Restructure→
After · 3 steps
Action
Relevant information + controls in context
Continue
>50% fewer interactions
The capability didn't shrink — the distance between decision and action did.
PrinciplePlace information and actions where users naturally look for them within the flow — not simply where the system structure says they belong.
// Decision-Centred Information
Reducing the number of elements on screen was not the goal. The goal was to control attention. Information hierarchy was driven by what the user needed to understand at a particular moment in order to continue confidently to the next step. At the same time, some information had to remain visible because of system behaviour, military hierarchy, NATO-related standards or other fixed requirements.
That meant visual priority came from two places — importance imposed by the system, and importance created by the user's current focus. The interface had to preserve both.
"Good information architecture is not about reducing information. It is about orchestrating attention."
Diagram 04
Two sources of priority, one hierarchy
System-defined
Fixed by system, domain & standards — can't change
→
User-defined
What the user needs to focus on right now
Visual attention
orchestrated, not maximised
Good IA isn't less information — it's orchestrated attention.
// When Constraints Cannot Move
In this environment, some constraints were simply fixed. A system-defined priority couldn't be redesigned away. A military or NATO-related rule couldn't be ignored. A technical dependency could make an otherwise elegant interaction impossible.
The useful question was therefore not "How do we remove the constraint?" but "Where else in the experience can we compensate for it?" If one part of the flow had to remain complex, I looked for opportunities to reduce friction elsewhere — through clearer hierarchy, fewer interactions, better grouping, contextual information or automation.
PrincipleWhen a constraint cannot be changed, optimise around it.
// Working With Requirements
Stakeholder requirements were important inputs, but they were not automatically design solutions. Some proposed approaches would have produced poor UX if implemented literally. In those situations, the UX team challenged the implementation rather than the underlying business or system need.
The process was direct: understand the actual need, evaluate UX impact, explore alternatives, test, present evidence, recommend a direction. I didn't see stakeholder communication as a persuasion exercise — my responsibility was to show what we evaluated, what we learned and which solution the evidence supported. If new information proved our assumption wrong, the design changed. If evidence supported the UX direction, that evidence became the basis of the recommendation.
"My job is not to persuade stakeholders to like a solution. It's to show what we evaluated, what we learned, and which solution the evidence supports."
// Designing More Than One Answer
I rarely wanted the team to evaluate only one solution — a single concept can work and still be far from optimal. When possible, I developed multiple viable directions, then challenged them against known scenarios, system dependencies, UX principles, technical limitations and domain standards.
The goal was not to vote for a favourite. It was to eliminate weaker options as new information emerged. A solution could fall away because of technical feasibility, a wider system dependency, excessive edge cases, domain or standards requirements, a new client constraint, or unnecessary cognitive cost. What remained wasn't "my idea" — it was the most informed solution available to us at that point.
Diagram 05
Weaker options fall away under pressure
Not a linear process — a filter. The path is set by what survives.
ConstraintsStress-testEvidence
A
passes constraints→passes stress-test→evidence supports
Most informed
solution
solution
B
passes constraints→✕ falls away at stress-test
C
✕ falls away at constraints
A solution survives not because it was the favourite — but because it withstood the constraints, scenarios and evidence the others couldn't.
PrincipleIdeas are not solutions. An idea becomes a solution only after it survives the problem, the constraints and the evidence used to evaluate it.
// Validation: Intentional Research, Open Learning
Every user test had a defined purpose. We started with a specific research objective and created scenarios, tasks, questions and metrics around what we wanted to learn. Depending on the question, we measured areas such as time, task success, process side-effects and unexpected behaviour, and user perception.
But targeted research didn't mean ignoring everything outside the original objective. Unexpected behaviour often became just as valuable as the metric we intended to measure. A test should know what it is trying to learn, while remaining open to insights nobody predicted before the session began.
When multiple directions were available, users could compare alternatives through structured comparative testing. When time or access didn't allow direct testing, we used the strongest combination of existing research, known user behaviour, established patterns, UX principles, domain knowledge and system constraints — but I don't treat those foundations as proof. Without evidence, I can't guarantee an outcome; they increase the probability of success until direct validation becomes possible.
Diagram 06
Intentional research, open learning
Intentional
planned before
Objective→Tasks & metrics→Observe
Open
during & after
Unexpected behaviour→New questions
Research should be intentional. Learning doesn't have to be.
PrincipleResearch should be intentional. Learning doesn't have to be.
// Performance Over Preference
User preference is useful evidence — but it isn't the same as usability evidence. If users prefer the appearance of one solution but complete the task more successfully with another, the decision should follow the actual objective of the product. If reliability matters most, success may outweigh speed; if speed matters most, time may carry greater weight. There is no universal metric hierarchy: the problem defines success, and metrics tell us whether we achieved it.
This prevented us from choosing a solution simply because users liked it more visually when another better supported task performance. A modern interface still mattered — I wanted the experience to feel contemporary and work naturally with modern devices whenever the context allowed — but visual quality had to reinforce usability, not compete with it.
"The purpose of UX isn't to win a preference contest. It's to solve the problem."
And when direct validation wasn't possible, I said so. If data supports a decision, I state what the data supports; if direct validation is missing, I don't pretend UX theory creates certainty. Confidence should match evidence.
// From Validated Design to Implementation
My ownership continued after design approval. Developers received specifications for components and expected behaviour. Once implemented, I reviewed the experience to verify that the interaction behaved as designed. If implementation changed the intended logic, hierarchy or behaviour, it went back for correction.
This mattered because a good design decision has little value if the implemented product no longer preserves the reasoning that made it good.
Diagram 07
Ownership continues through delivery
Validated design
→
Component &behaviour spec
→
Development
→
UX reviewagainst intent
→
Finalshipped
corrections loop back if implementation drifts from intent
A good decision loses its value if implementation quietly changes the reasoning behind it.
// Outcome
The redesign improved the way users could move through complex planning processes without removing the capability or information the domain required. The work contributed to higher success in executing the process, reduced cognitive load through clearer hierarchy and grouping, automation of previously manual parts of the workflow, modernisation of the interaction model and interface, more direct access to relevant information and actions, and more than 50% fewer required interactions in selected flows.
The strongest outcome was not that the system became "simple." It became easier to understand and operate as complexity increased.
Due to confidentiality, detailed product metrics and operational workflows cannot be disclosed. The >50% figure refers to required interactions in selected flows.
// Reflection
I entered this project as an intern and eventually became responsible for its UX direction end to end. It changed how I approach complex product work in several ways: I check constraints before designing, because a strong concept can collapse when a system dependency or domain rule is discovered too late. I treat alignment as sharing knowledge, not deciding who is right — engineering, system experts, stakeholders and UX each see a different part of the problem, and better decisions happen when that knowledge becomes shared. I keep asking whether something can work better, because a solution can function and still be unnecessarily difficult. And I watch cognitive load across the whole flow, not just how crowded a single screen looks.
Most importantly, I stopped seeing complexity as something UX should automatically remove. Some complexity belongs to the problem. The job is to distinguish necessary complexity from unnecessary friction and optimise accordingly.
Diagram 08
What this project taught me
Check constraints first
Alignment is sharing, not winning
Watch cognitive load across the whole flow
Optimise complexity — don't erase it
and always —Can it work better?
Some complexity belongs to the problem. The job is to tell it apart from friction.
"This project isn't here to show I can design a planning interface. It's here to show how I work when the product is too complex for obvious answers. Most importantly, I learned not to confuse 'working' with 'optimal.' The question I still carry into every product is simple: can it work better?"
Case Study 03 · Rheinmetall
Hardware Input Device Mapping
Where muscle memory meets software behaviour
Overview: Research and interaction mapping for physical input devices at Rheinmetall Air Defence — bridging hardware ergonomics and software behaviour so the mapping between a physical control and its function is intuitive and near-impossible to get wrong.
My Role
Led research & interaction mapping
Context
Physical devices · regulated env.
Timeline
2024–2026
// The Problem
When operators use physical input devices, the mapping between a control and its software function has to be intuitive and near-impossible to get wrong. A mismatch between what a control feels like it does and what it actually does creates hesitation and error — costly in a time-pressured, safety-critical setting.
// Research
I ran hardware-based usability tests with specialist users to observe where physical and digital expectations diverged. You can't A/B test your way to this — it takes structured observation of trained users on real equipment, watching for the moments where muscle memory and on-screen behaviour disagree. Findings are under NDA, but they directly drove the mapping decisions.
Method
Hardware-based usability sessions with real devices and trained operators.
Focus
Where does muscle memory diverge from what the software actually does?
// Design Decisions
Match the mapping to the mental model
Controls map to functions the way operators expect, not the way the system is wired. Why: when the model matches muscle memory, error drops.
Optimise for eyes-up, low-error operation
Layout follows task frequency and priority. Why: operators shouldn't need to look down to trust what a control does.
Iterate the mapping, not just the feedback
The physical-to-digital mapping itself was the object of iteration. Why: fixing on-screen feedback alone can't repair a mapping that fights the user.
// Visuals
// Outcome
[Add a qualitative outcome — NDA-safe] — e.g. validated a control mapping that reduced hesitation in operator testing.
// What I'd carry forward
"Working across hardware and software reminded me that interaction design doesn't stop at the screen — the whole loop between hand and system has to feel like one thing."
Case Study 04 · Brainest
Cloud Away — Mindfulness App
Cloud Away — A Calmer Way to Breathe
Overview: Cloud Away is a mindfulness and breathing app built in collaboration with Brainest. I led the design end-to-end — from research and information architecture to the final UI — with one goal: make the interface itself feel like a breath out.
My Role
Design Lead — UX, UI, prototype
Team
Brainest · developers & product
Timeline
~3 months, concept to handoff
// The Problem
Most mindfulness apps add friction to the very calm they promise — cluttered onboarding, endless content libraries, visual noise competing for attention. Users open them to slow down and are met with decisions. The core challenge: design an experience where reaching a moment of calm takes as little effort as possible, and where the interface never becomes another thing to manage.
// Research
Before designing anything, I looked at how people actually use calming apps and where they drop off. I reviewed competing products, mapped their onboarding flows, and gathered informal feedback on what made people abandon them. A few patterns stood out clearly.
Too much
People abandoned apps that asked for too much before delivering any value — long sign-ups, quizzes, permissions.
3 taps
The fewer steps between opening the app and the first breath, the more likely someone was to stay.
Calm > features
Users consistently wanted less, not more — a quiet space, not a content catalogue.
Evening peak
Most sessions happened at night, before sleep — which shaped tone, contrast, and motion choices.
// Design Decisions
Every decision was measured against one question: does this help the user let go, or does it get in the way? That framing made trade-offs easier — and gave me a clear reason to say no to features.
Reduce onboarding to almost nothing
A first-time user reaches a breathing session in three taps. Rejected: the usual account-first, quiz-driven onboarding — it protected retention data at the cost of the calm the app promised.
One choice per screen
Each screen asks for a single decision, with generous space around it. Why: choice overload is the opposite of calm — so depth is available through progressive disclosure, never forced upfront.
Soft motion as a guide
The breathing animation paces the user rather than instructing them. Why: a gently expanding shape communicates "inhale / exhale" without text, working even at night with the phone at arm's length.
A restful visual system
Muted palette, rounded forms, high legibility. Why: consistency lets the user stop noticing the interface — which is exactly the point.
// The Flow
The core loop is deliberately short: choose a session, breathe, see gentle progress. Progress is present but never gamified into pressure — no streaks that punish, no guilt.
// Design System
To keep the experience coherent, I built a small, calm design system — a restful palette, soft rounded components, and consistent spacing — so every screen felt like part of the same quiet space.
// Outcome
[Add your result here] — e.g. delivered a complete, developer-ready design and prototype; positive reception from Brainest and test users; the calm-first onboarding became the defining feature of the product.
// What I'd carry forward
"Designing for calm taught me that restraint is a feature. The hardest — and most valuable — work was deciding what to leave out."
Case Study 05 · Brainest
Dentist App — Patient Care
Dentist App — Care Without the Anxiety
Overview: A patient-facing dental care app built in collaboration with Brainest. I led the design end-to-end. The goal: make appointments, records, and communication feel clear and reassuring — for people who are often anxious about the dentist in the first place.
My Role
Design Lead — UX, UI, prototype
Team
Brainest · developers & product
Timeline
2023
// The Problem
Dental care touches people who are often anxious, wrapped around information that is inherently clinical. Most dental apps make it worse — burying the tasks patients actually need behind cold, confusing interfaces. The app had to make booking, records, and communication feel clear and reassuring rather than clinical or stressful.
// Research
I looked at how patients actually interact with dental services and where existing apps let them down. The findings pointed clearly at emotion and clarity, not feature count.
Anxiety
People arrive stressed — the app has to reassure, not clinicalise the experience.
Booking
Rescheduling was the most common task, yet buried in most dental apps.
Clarity
Patients couldn't read or understand their own treatment history.
Trust
A warm, professional tone mattered more to users than any extra feature.
// Design Decisions
Put the common tasks first
Booking, rescheduling, records, and reminders lead the home screen. Why: research showed these are 90% of why patients open the app — everything else is secondary.
Plain language over clinical terms
Treatment history is written to be read by non-experts. Why: people can't act on information they don't understand.
Warm, professional, calm
A tone that reassures without feeling unserious. Why: trust reduces the anxiety many people bring to dental care — and trust is a design choice.
// The Flow
The primary journey — book, confirm, review — is short and legible, designed so an anxious first-time user never feels lost.
// Design System
A clear, calm design system keeps the clinical content approachable — trustworthy colour, legible type, and consistent components across every screen.
// Outcome
[Add your result here] — e.g. delivered a complete, developer-ready design; positive reception from Brainest; the calm, task-first approach differentiated it from typical clinical apps.
// What I'd carry forward
"Designing for anxious users showed me that tone is a usability factor. Reassurance isn't decoration — for healthcare, it's part of whether the product works."
Complex Systems
Designing in Constraints: What Safety-Critical UX Taught Me About Good Design
Most UX designers learn their craft in environments where iteration is cheap and mistakes are recoverable. And then I started working on interfaces where that loop doesn't exist. Where a confusing interface isn't an inconvenience — it's an operational risk.
What changes when constraints are real
In safety-critical work, the constraints aren't design constraints — they're system constraints. Regulatory validation requirements. Hardware limitations. These don't flex. Your design has to work within them, not around them.
The discipline of having to justify every decision made me a better designer — not because justification is the goal, but because it forces you to actually know why you made a choice.
What it gave me
Working in regulated, constrained environments built three things: systems thinking, research rigour, and engineering fluency.
UX Thinking
Cognitive Load Is Not the Enemy — Misplaced Cognitive Load Is
Reducing cognitive load has become one of UX's most repeated principles. But in complex systems, "less is always better" is wrong — and designing for it can make interfaces genuinely dangerous.
What cognitive load actually is
It's not inherently bad. The problem is not that users are thinking. The problem is if they're thinking about the wrong things.
A user who has to think hard about what a label means is spending cognitive resources that should go toward the actual decision. That's misplaced cognitive load. That's the enemy.
Real-world Lessons
From SME Websites to Complex Systems: What the Gap Taught Me
My first UX work was for small businesses. Then I joined a company building complex regulated systems. The contrast was significant.
What didn't change
The fundamentals. Users have mental models. Interfaces either match them or create friction.
Good UX principles are domain-agnostic. The application changes radically. The principles don't.
Research
On-Site With Specialist Users: What Lab Research Can't Prepare You For
On-site research with specialist users was a different discipline entirely. Lab research happens in a controlled environment. In an operational context, the environment is set — and you are the visitor.
The most valuable research data I collected was never in response to a question I asked. It was in watching what happened when the user did something the interface didn't expect.
What this changes in your design process
On-site research teaches you to design with humility. The interface has to meet users where they are — fitting into their mental model, their terminology, their operational reality.