1. Key Design Decisions

1.1 WhatsApp as primary delivery channel

Field research showed newcomers were excluded by BankID and personnummer requirements on 1177 during exactly the weeks they most needed care. We chose WhatsApp — no download, no account, no credentials, already trusted through daily use. The Random Word Association technique, using the trigger word Bridge, crystallised the principle: the solution had to be a crossing point the user already stood at.

1.2 Freemium model with the newcomer as paying customer

We began with a B2G model and revised it after journey mapping separated product–value fit from product–market fit. Three motivations drove the shift:

• Municipal procurement cycles run 6–12 months, preventing early revenue validation.
• Voluntary conversion at 49kr is direct evidence of product–market fit no contract can match.
• Freemium reduces single-point-of-failure dependency; the service launches through community word of mouth.

Premium targets high-stakes moments — official letters, prescriptions, appointment scripts — priced at 49kr/use or 99kr/month, calibrated to feel trivial against the cost of misreading a Försäkringskassan letter.

1.3 Utveckling migration och hälsa as clinical anchor and human escalation inside WhatsApp

Our journey map identified this specific cross-professional unit whose mandate is knowledge development, not procurement. Their quarterly triage review provides clinical defensibility; in return they receive anonymised aggregate outcome data for their own health equity KPIs at no cost. Escalations stay within WhatsApp to preserve context continuity — users should not re-explain their situation on a different channel. Defining the agent role as a welfare coordinator (social science background, not clinical) makes it fundable from existing cross-professional budgets. Arabic and Somali were prioritised based on Malmö's newcomer demographics.

---

2. Prototyping Decisions

2.1 Prototype as hypothesis-testing tool

We built the Vård Guide HTML chatbot to answer specific questions before committing development resources. The free tier tested: does a language-matched first response generate return use? The premium flow tested: does a user pay at the first high-stakes moment if trust was built in the free tier? These are sequential hypotheses; the prototype was structured to test them in that order. The storyboard — developed alongside the prototype — made the trust–conversion logic visible as a narrative, stress-testing whether the emotional journey matched our design assumptions.

2.2 Fake door for payment validation and escalation as scoped experiment

Before building payment infrastructure, we designed the premium gate as a fake door: presenting the full feature list and a payment link with unlock via demo code. Observed tapping behaviour is a more reliable signal of conversion intent than survey responses, particularly for users unfamiliar with Swedish digital payment services. We included the 1177 escalation feature not as a finished capability but as a measurable experiment: if users escalate frequently for simple queries the staffing model is not viable; if escalation concentrates on complex situations it confirms the model. The first live deployment generates the staffing data before scaling, rather than requiring that assumption to be made in advance.

---

3. Assumptions, Feasibility, and Ethics

3.1 Core assumptions

medium riskAssumption 1: Newcomers will trust a WhatsApp number shared by a peer without official endorsement. Both research participants described peer networks as their primary source of guidance. The risk is that trust depends entirely on who shares the number — a single fraudulent actor could destroy the community layer. Mitigation: the free tier must be genuinely useful on first contact and transparent about what the bot can and cannot do.

high riskAssumption 2: Newcomers will pay 49kr at a high-stakes moment without prior experience of Swedish digital payments. Many lack Swedish bank accounts, eliminating Swish; card and PayPal must function as primary paths. This is the highest-risk dependency in the commercial model and the fake door test must validate it before payment infrastructure is built.

3.2 Feasibility

The model is viable if approximately 5–8% of active free users convert to 99kr/month — conservative by freemium standards. Recruiting a bilingual welfare coordinator with Arabic or Somali language skills in Malmö is realistic but cannot proceed until the Region Skåne partnership is confirmed.

3.3 Ethics

The most significant risk is clinical harm from incorrect triage. We addressed this through three layers: Utveckling migration och hälsa content review, automatic 112 routing for emergency-classified symptoms, and the explicit escalation path. Quarterly governance is a safety requirement, not an optional process. On the payment side, the free tier is kept genuinely functional so no newcomer in a healthcare emergency is blocked by inability to pay — premium gates only convenience and depth, never emergency routing or basic triage. A third consideration is data sovereignty: the service runs on Meta infrastructure (WhatsApp Business API), creating GDPR tension over health-related conversations. We mitigated this by ensuring no personal health data is stored server-side; the bot processes symptom keywords in memory only. This architecture, made explicit in the service blueprint, was one of several backstage dependencies invisible to the user but essential to legal defensibility.

3.4 Reflection on the design process

The journey map proved decisive in two ways we did not anticipate. First, it forced separation of the user (the newcomer) from the customer (the paying entity), exposing the weakness of the B2G model and driving the freemium revision. Second, it surfaced the specific unit within Region Skåne whose mandate matched the service's actual needs, shifting our first outreach from a procurement conversation to a research collaboration. The service blueprint was most valuable not for mapping what existed — very little does — but for making visible the backstage dependencies the free-tier user never sees: clinical content review, GDPR architecture, human escalation. Making them explicit distinguished structural risks from manageable uncertainties and shaped every prioritisation decision in the prototype. Across the project, our prototyping decisions followed a consistent principle: test the riskiest assumption first with the lowest-fidelity method that generates credible evidence. Question before answer, evidence before investment.