دايرتنا · Da'eratna

The opportunity

Mental health platforms in the Arab world face a unique constraint: clinical language carries stigma, but vague language carries liability. Da'eratna was built around a cultural insight — Arabic speakers seek support for emotional struggles long before they're willing to use medical terms.

I started with the design system, not the features. Before designing a single screen, I built a foundation that supports two languages (Arabic, English), two platforms (desktop, mobile), and two color modes (light, dark) — eight contexts for any single component.

This let one junior designer ship the web portal under my review while I own mobile (Flutter) end-to-end. We work in parallel on the same features without colliding because the system carries the consistency, not us.

The hardest problem: designing a system that serves real psychological care without ever calling itself one. Every screen, every label, every notification had to walk the line between accessibility and clinical responsibility — across all eight contexts.

Context

Da'eratna ("our circle" in Arabic) is a wellness platform for the Saudi and Egyptian markets. Providers — coaches, psychologists, counselors, peer leaders — use it to create and run support "circles" focused on specific emotional themes (anxiety, grief, parenting, life transitions).

Inside each circle, providers can run one-time sessions, ongoing weekly sessions, structured programs over multiple weeks, or workshops with registration tiers.

Both providers and participants have full access to the platform on both web and mobile — they choose where they want to work.

The product makes one cultural decision that shapes everything else: the platform's user-facing language avoids medical terminology. A circle is "دائرة القلق" (the anxiety circle) — not "anxiety treatment". A session is "جلسة" — not "therapy". This isn't softening; it's a deliberate boundary.

Medical terminology only surfaces inside the provider's own private workspace, where it belongs to their clinical responsibility, not the platform's.

System first, features second

Most projects start with feature design, then extract a system later. Da'eratna started the opposite way: I built the system before designing a single user-facing screen.

The reason was practical. The product had to ship in eight contexts:

Languages × Platforms × Modes — (Arabic, English) × (Desktop, Mobile) × (Light, Dark) = 8

Designing each feature eight times wasn't realistic — not with one junior designer and an active development team waiting. The system had to do the heavy lifting.

With the system in place, the team could split: I own mobile (Flutter) — provider and participant; the junior designer owns web (Vue) — provider and participant. Both of us pull from the same components, the same tokens, the same patterns. Same feature, two surfaces, two designers — but one consistent product.

This is the workflow that lets a small design team ship a four-surface product. Without the system-first approach, we'd be a bottleneck instead of a team.

Semantic tokens cascade across light and dark modes

One component, two languages, identical rhythm

The bilingual challenge

Most Arabic apps are designed in English first, then translated. The result is predictable: layouts that break under longer Arabic words, English numbers in Arabic dates, mirror-flipped icons that suddenly mean something different, and "RTL support" that's really just CSS direction reversal.

Da'eratna serves users in Saudi Arabia and Egypt — markets where Arabic isn't a localization, it's the primary language. Treating Arabic as a translation layer would have failed the product before it shipped.

Arabic and English designed as siblings, not as a translation

Numerals chosen by context, not by language

Cultural sensitivity in mental wellness

The non-medical language constraint shaped how the product talks to users. Saudi and Egyptian users searching for support don't type "I have anxiety" — they type "أحس إن قلبي مش مرتاح" or "تعبان نفسياً". The platform's content, discovery, and search had to respect that vocabulary.

Browse by feeling, not by diagnosis

Design system: built for two languages, two platforms, two designers

I'm building this with a junior designer. I needed a system that supported both Arabic and English without doubling maintenance, worked across web (provider portal) and Flutter (participant mobile app), and was clear enough that a junior designer could ship features without me reviewing every spacing decision.

The system is structured in three layers. The foundation layer holds tokens, semantic naming, and strict reference rules. The component layer documents each component with both Arabic and English usage examples, plus edge cases (long Arabic strings, mixed content) shown explicitly so the junior doesn't discover them in production. The pattern layer captures common flows — registration, circle joining, session booking — as standardized patterns the junior composes from instead of redesigning each time.

In practice: she owns web portal screens; I review weekly. I own mobile (Flutter) end-to-end. Once a month we audit the system together — what's missing, what's broken, what needs revision. This split lets her grow ownership without overwhelming her, and lets me focus deep on the harder mobile interactions.

What I'd do differently

Status

The design system is shipped and in active use. High-fidelity flows are complete for provider and participant — on both web and mobile. Mobile (Flutter) is in active development; web (Vue) is in late-stage build.

Pilot launch with selected providers in Saudi Arabia and Egypt is planned for 2026.

Specifics about the company, providers, and metrics are confidential. Available to discuss in interviews.