Interaction design for environments that break the rules
Thesis
A research-led set of principles for XR in industrial settings — where gloves, noise, and physical load make most interface assumptions wrong.
Good morning, I’m
Harri Halonen
I design complex digital products that make business operations, data, and decision-making easier to understand and scale.
I work from discovery into UX architecture: mapping the messy parts, shaping flows, turning repeated UI decisions into design-system patterns, and checking accessibility early. I stay close to engineers, product teams, and stakeholders so AI and data workflows become interfaces people can understand, use, and maintain — watching design quality as it gets built.
Areas I work across
- Product discovery
- B2B & internal tools
- Design systems
- AI & data-heavy workflows
- UX architecture
- Implementation support
- Accessibility
- Design QA
- Stakeholder alignment
Work
Where the work concentrates
Three threads run through most of my projects. Each one lists what’s documented today and what’s still being written up — so the labels stay honest.
Systems
Operational products with many roles, uneven permissions, and workflows that live partly in tools and partly in people’s heads. I make that complexity legible first — workflow maps, role and state models — then help decide what the product should absorb, and in what order.
Proof today
- From ambiguity to shared direction — methods case — artifacts in progress
- Kiva Kaupunki — archive — civic reporting concept and MVP
- How I work — the loop and its artifacts, on this page
In progress
An anonymized operations-platform case is being written up as evidence is cleared. Read the case shell.
Research
Design decisions that trace back to evidence: field observation, interviews, synthesis — and honest limits on what the findings can claim. This is the oldest thread in the work and the best documented one.
Proof today
- Interaction design principles for industrial XR — master’s thesis
- Classroom robot study — archive research case — observation to evaluation
- Aikakone — concept work — field inquiry and service blueprinting
- Writing — research notes
In progress
Recent discovery artifacts — interview synthesis, assumption maps — are being anonymized for the direction-setting case.
AI & Data
A current focus, labelled as such: designing AI as decision support inside real workflows — visible uncertainty, easy override, a fallback path that works. No shipped AI product is claimed here; the framework I design against is the evidence so far.
Proof today
- AI as decision support — design framework — concept shell
- Classroom robot study — human-in-the-loop behavior under speech-recognition limits
- Industrial XR thesis — emerging-tech interaction research
In progress
Anonymized AI-workflow artifacts attach to the framework page as they are cleared — nothing gets published before that.
From ambiguity to buildable output
The same loop on most projects, end to end — I stay past the handoff, through the build, design QA, and back into the system.
Discovery
Sit in the real workflow: interviews, support threads, and the spreadsheet someone quietly runs everything from.
What this produces: A map of how the work really happens — not how the org thinks it does.
Framing
Name the actual problem and what we are deliberately not solving, so scope stops sliding mid-project.
What this produces: One sentence everyone agrees on: the problem, and the non-goals around it.
Concept models
Map the objects, states, and relationships underneath before drawing a single screen.
What this produces: An object model the whole team can point at and reason about.
Prototypes
Put clickable flows in front of real data and real users to find where the idea breaks.
What this produces: Evidence — where the flow holds, and where it quietly falls apart.
Design specs
Hand over buildable detail: every state, empty view, error, and edge case engineers will hit.
What this produces: A spec engineers can build from without guessing.
Implementation support
Stay in the build, answer the questions Figma cannot, and adjust as real constraints surface.
What this produces: Decisions made in the moment, in context — not weeks later in a thread.
Design QA
Check the built UI against intent and catch spacing, state, and behavior drift before users do.
What this produces: A build that matches intent, down to the empty and error states.
Measurement
Watch it in use and ask the honest question: did this make the work easier, or just different?
What this produces: An honest read on whether the work actually got easier.
System contribution
Fold the patterns that held up back into the design system so the next team starts ahead.
What this produces: Patterns, hardened and handed forward for the next team.
What the loop leaves behind
The same set of artifacts on most projects, whether it’s a public service, an internal tool, or a data-heavy product. The sketches are illustrative, not real project data.
Discovery → Framing
Workflow map
How the work actually moves — every step, handoff, and the spreadsheet nobody mentions until week three.
Framing
Role model
Who owns what, where the decisions sit, and the handoffs that quietly go missing.
Concept models
State model
The objects underneath the screens, and the states they move between — named before anything gets drawn.
Design specs
Design spec
Buildable detail: default, empty, loading, error, and the edge cases engineers hit at 4pm on a Friday.
Design QA
QA checklist
What “done” means, checked against intent before users find the gaps for me.
Throughout
Decision log
Dated calls, the reason, and the tradeoff — so “why is it like this” has an answer months later.
What engineers get from me
I came to product design through front-end work, so I spec the way engineers read: every component arrives with its states, validation rules, responsive behavior, and accessibility expectations written down — not discovered in a code review. That background changes the questions I ask, not the work I do: I flag what the backend can’t promise before it becomes a UI bug, and I’m in the pull requests when a state I drew meets data I didn’t expect.
It’s still design work — the spec exists so the intent survives the build. Here’s the shape of one, end to end.
Design spec · one component, in full
Filter field + results list
Illustrative example — the structure is how I actually spec, the project is not real. Where a design system exists, each rule below points at named tokens and components instead of raw values.
States
- Field: default · focus-visible · disabled
- Results: loading (skeleton rows)
- Empty: “No matches — clear the filter?”
- Error: retry action, input preserved
- No view ships blank — every state has words
Validation
- Validate on blur, not per keystroke
- Error names the fix: “Use format YYYY-MM”
- Failed submit keeps what the user typed
- Disable submit only while a request is in flight
Responsive
- ≥ 60rem: filter sits beside the results
- < 45rem: filter stacks above, table becomes cards
- Touch targets stay ≥ 44px at every width
- Truncation rules named per column, not improvised
Accessibility
- Label always visible — never placeholder-only
- Error tied to the field with aria-describedby
- Result count changes announced politely
- Focus order follows reading order, focus visible
Say hello
If any of this sounds like what your team is working on — product design roles, complex product systems, design systems, or AI and data workflows — I’d be glad to hear about it. A short note on what you’re building is plenty; no pitch required.
Email works too — my first name, here at this domain.