Kris Haamer · Product portfolio

How I turn uncertain problems into working products.

I connect user research, product strategy, interaction design, data, and implementation so important decisions survive the journey from ambiguity to production.

20+ years

Building for the web

675

Valid research responses

32 + 32

Interviews and prototype tests

3 continents

Work across Europe, Asia, and Africa

Selected product work

Four cases, chosen for the decisions they reveal.

These are not the only projects I have made. They are the clearest examples of research, systems thinking, cross-functional delivery, cultural context, and honest learning.

01

Financial AI research · Taiwan

Green Filter

Turning a broad sustainability problem into a testable product direction.

My role

Researcher, product strategist, interaction designer, prototype builder

Evidence

900+ survey responses, 675 valid responses, 32 interviews, 32 prototype tests

Context

MA Interaction Design research with young adults across Taiwanese universities

Situation

Young adults were expected to make sustainable shopping choices while also managing limited money and beginning to think about saving and investing. The initial concept tried to connect all three behaviours through one AI companion.

Evidence

The research combined a large survey, interviews, classroom engagement, self-guided testing, and prototype sessions. It revealed distinct eco-friendly, moderate, and frugal patterns, while health and safety concerns often felt more immediate than abstract sustainability claims.

Important decisions

  1. 1Use financial consequences to make sustainability choices more concrete.
  2. 2Prototype support at the moment of shopping rather than only in a later report.
  3. 3Treat user segments as different decision contexts, not as cosmetic personas.
  4. 4Test web, wearable, and browser-extension interactions before committing to one product surface.

Result

The work produced a research-backed product direction and a set of functioning prototypes. More importantly, it exposed a scope problem: shopping, saving, and investing should not be treated as one validated product merely because they share a long-term financial story.

What I got wrong or learned

I framed three related behaviours as one product too early. The next iteration should narrow the repeated decision, prove retention around that moment, and only then expand into a broader financial companion.

02

Public data product · Estonia

WiFi.ee

Rebuilding a public utility around trustworthy location data, not feature volume.

My role

Product owner, design engineer, data and technical architecture

Evidence

1,225 location records, verification fields, map and search behaviour, contributor needs

Context

A long-running public Wi-Fi service being rebuilt as modern digital infrastructure

Situation

A public Wi-Fi directory is only useful when people can find a nearby network and trust that the record is recent, understandable, and genuinely usable. A larger database can create false confidence when freshness and ownership are unclear.

Evidence

The rebuild exposed the real product materials: geospatial records, verification dates, safety criteria, owner permissions, contributor workflows, permanent poster URLs, storage, and recovery. A major data-loss incident also made operational resilience part of the user experience.

Important decisions

  1. 1Make destination and nearby-location search the primary action.
  2. 2Use PostGIS and Mapbox for geographic discovery rather than treating locations as a flat directory.
  3. 3Separate content operations, relational data, and static assets across Directus, Supabase, and Cloudflare R2.
  4. 4Shift the north-star metric from total records to recently verified, useful locations.

Result

The project now has a clearer product architecture for maps, search, scoring, owner claims, contributor updates, and durable assets. The deleted database was recovered, but the incident changed the roadmap by elevating backups, permissions, and recovery checks from technical housekeeping to product requirements.

What I got wrong or learned

I initially focused too much on rebuilding the visible service. The failure showed that a public-data product also needs an explicit operating model: who can change what, how mistakes are reversed, and how users can judge freshness.

03

Multilingual cultural service · Helsinki

Viirus Theatre

Helping audiences decide, orient, and reach tickets under real time pressure.

My role

Product and interaction design, frontend delivery, analytics and accessibility improvements

Evidence

Audience and staff feedback, high-intent paths, schedule-scanning problems, mobile constraints

Context

A bilingual theatre with frequent programme changes and mobile-heavy pre-show traffic

Situation

The site needed to express an artistic identity without slowing down the basic audience ritual: see what is on, confirm the time, understand the production, and reach ticketing. The publishing team also needed to update changing information without one-off interventions.

Evidence

Feedback and product signals pointed to hesitation around date and time scanning, programme navigation, and ticket actions. The work also surfaced instrumentation gaps, unstable mobile presentation, keyboard issues, and an editorial structure that made routine updates harder than necessary.

Important decisions

  1. 1Rebuild the information architecture around Tonight, Calendar, and Archive.
  2. 2Treat schedule typography and spacing as interaction design, not decoration.
  3. 3Reduce decorative motion where it competed with stability or mobile performance.
  4. 4Place ticket actions in the production context and instrument progression toward them.

Result

The audience journey became more direct and the publishing structure more repeatable. Accessibility and performance checks became part of the release rhythm, while outbound and scroll tracking created a basis for later product decisions.

What I got wrong or learned

Historical conversion baselines were incomplete, so I cannot honestly claim a precise uplift. The stronger outcome is a measurable journey and an operational system that allows the theatre to compare behaviour over a full season.

04

Cross-cultural social impact · São Tomé and Príncipe

Elsa Figueira

Building a participation and media system without importing a European campaign template.

My role

Co-creator, digital platform, campaign design, production and distribution

Evidence

Local collaborators, audience context, entertainment-education models, partner and media response

Context

A Portuguese-language campaign and documentary addressing domestic violence

Situation

A sensitive social issue needed a form that could create recognition and discussion without reducing local people to statistics or turning an outside team into the centre of the story.

Evidence

The project drew on local creative partnerships, public participation, youth-oriented entertainment-education precedents, and the practical media landscape around São Tomé and Príncipe. The platform connected a literary character, documentary, cast, creators, partners, and public coverage.

Important decisions

  1. 1Use the fictional character Elsa as a shared narrative entry point rather than a didactic campaign voice.
  2. 2Combine film, public participation, events, and a digital archive instead of relying on one media format.
  3. 3Build with local production partners and Portuguese-language distribution from the beginning.
  4. 4Let the website document the collaboration structure, not only promote the finished film.

Result

The campaign launched in 2016 and extended through coverage and interviews from VOA Português, RDP Africa, Deutsche Welle, RTP África, and Rede Angola. Its value was not a single interface metric, but a connected cultural system that could carry the issue across film, conversation, events, and media.

What I got wrong or learned

Cross-cultural work must alter the method, ownership, and distribution, not simply the language. Local collaboration and context were core product inputs, while the outside team's role needed to remain visible and accountable.

How I work

Keep the problem connected from research to reality.

My advantage is not performing several disciplines independently. It is keeping user evidence, business intent, technical constraints, and delivery decisions in the same conversation.

  1. 01

    Investigate

    Find the uncertainty that could make the whole project wrong.

  2. 02

    Frame

    Turn symptoms, incentives, constraints, and evidence into a shared problem.

  3. 03

    Prioritise

    Choose the smallest consequential decision, not the longest feature list.

  4. 04

    Prototype

    Make assumptions testable through flows, content, interfaces, and code.

  5. 05

    Ship

    Stay close to implementation so product intent survives technical reality.

  6. 06

    Measure

    Use behaviour, operations, support signals, and failures to choose the next move.

The next product problem

Bring me the part that is still ambiguous, political, cross-functional, or hard to measure.

I am most useful before the team has reduced the problem to a screen request, and I stay involved long enough to see whether the decision survives production.

Email kris@haam.coWhy hire KrisRead product writing

Help improve this website?

Optional Google Analytics and Microsoft Clarity measure content performance and usability. They load only if you allow them. Form values, email addresses, and chat messages are never included in analytics events.