AmanAkses

AmanAkses is an accessible digital support prototype for people who have experienced, are worried about, or are trying to understand a situation involving sexual violence or sexual abuse.

The project does not treat sexual violence as a simple reporting problem. It starts from a harder reality: someone who experiences or fears sexual abuse is not always ready to make a formal report right away. Before reporting, they may need to understand what happened, remember details slowly, keep private notes, organize possible evidence, look for a trusted person, or learn what kinds of help are available.

That preparation stage is often not supported well by digital systems. Many platforms jump straight into formal complaint forms, while the user may still be in the middle of processing what happened.

For disabled users, the barriers can become even more layered. Support information is often written in long legal language. Some websites are difficult to use with keyboard navigation. Interface labels may not be readable by screen readers. Communication options can be limited. Reporting procedures can also force users to retell painful experiences repeatedly to different people.

Users with cognitive or psychosocial needs may need simpler language, smaller steps, time to pause, and control to stop the process without losing their work.

AmanAkses was built around this gap.

It is a calm preparation space before formal action: a place to understand sexual violence, write safely, organize synthetic evidence, build a draft chronology, choose trusted support, and review an early report with explicit consent.

Background

Sexual violence is a serious problem that needs prevention, handling, protection, and recovery to work together. In practice, the first step is not always a formal report.

A person may still be asking:

• What happened to me?
• Is this sexual violence?
• What details should I remember?
• Where can I write this down safely?
• Who can I trust first?
• What kind of help exists?
• What happens if I am not ready to report yet?

That early stage matters.

If a digital system only gives the user a complaint form, it can miss the moment where the person needs preparation, understanding, and control the most.

For disabled users, the problem is not only emotional or procedural. It is also technical and accessibility-related. A support flow can fail because the language is too legalistic, the buttons are too small, the labels are unclear, the screen reader experience is broken, the website cannot be used by keyboard, or the process expects the user to explain a painful experience again and again.

AmanAkses responds to that by focusing on inclusive documentation and early support before formal reporting.

It is not an emergency service, therapist, legal advisor, diagnostic tool, or automatic reporting system. It is a prototype for safer preparation: understanding options, journaling, organizing possible evidence, building a timeline, and reviewing an early report while keeping the user in control.

Why this matters

The social urgency behind AmanAkses is not abstract.

Komnas Perempuan has highlighted that women with disabilities still face systemic discrimination and risks of gender-based and disability-based violence. CATAHU 2024 recorded 105 cases of violence against women with disabilities, including 38 cases reported directly to Komnas Perempuan.

Those numbers do not represent every case. Many experiences are never formally reported. But they show why more inclusive mechanisms for information, documentation, and referral are needed.

AmanAkses was designed with that urgency in mind.

The goal is not to make a product that speaks louder than human support. The goal is to make a digital preparation space that is easier to access, less intimidating, and more careful about consent.

The problem

Sexual violence support tools often start too late in the user journey.

They assume the user is already ready to report. They assume the user can explain what happened clearly. They assume the user can fill long forms, understand legal language, upload files, and submit everything in one flow.

But the reality is not that clean.

Someone may only remember fragments. They may be afraid of being blamed. They may not know whether what happened counts as sexual violence. They may need to write one small note today and continue later. They may want to prepare information without sending it anywhere yet.

For disabled users, the product requirements become even more serious:

• information about sexual violence must be written in simple, non-blaming language;
• the interface must support keyboard navigation, screen readers, clear labels, and readable layout;
• the user must not be forced to repeat traumatic experiences unnecessarily;
• every note, draft, evidence item, and report preview must stay under user control;
• AI must never decide truth, blame, legal status, diagnosis, or what the user should do next.

This is the core design challenge of AmanAkses:

How can a digital product help someone prepare information about sexual violence without taking away their control?

The product position

AmanAkses is not designed as a “submit report now” product.

It is designed as a consent-first preparation workspace.

The product helps users move through the early support process at their own pace:

1. understand sexual violence and available options;
2. write private notes in a safe journal;
3. organize possible evidence;
4. choose which notes may be processed by AI;
5. generate a draft chronology;
6. review, edit, accept, or reject AI output;
7. prepare an early report preview;
8. decide whether to share anything with a trusted person or support institution.

The important part is that nothing is treated as final by default.

Notes are not automatically turned into reports. Evidence is not automatically submitted. AI-generated timelines are not treated as proof. The user remains the decision-maker at every step.

Why Expo became important

Although AmanAkses also has a web prototype, the Expo mobile prototype became one of the most important parts of the project.

A support tool for sexual violence documentation is likely to be used in private, urgent, or emotionally heavy moments. In those moments, a phone often matters more than a desktop. It is closer to the user, easier to carry, easier to hide, and more realistic for writing short notes, checking help, or exiting quickly.

That is why I explored AmanAkses as an Expo app.

Expo helped turn the product from a dashboard-like prototype into something closer to a real support companion: mobile-first navigation, tab-based flows, calmer screens, local state, safe-exit behavior, and server-side AI routes without exposing model keys in the client.

The mobile prototype is not just a smaller version of the web app. It changes the product thinking.

On mobile, every screen has to be calmer. Every action has to be clearer. Every step has to respect that the user may only have a few seconds, one hand, or limited emotional capacity.

The Expo mobile experience

The Expo version is structured around the main actions a user might need first: home, journal, timeline, assistant, and more.

The product is intentionally broken into small spaces instead of one heavy form.

Expo app
    |
    |-- Beranda
    |-- Jurnal Aman
    |-- Kronologi
    |-- Asisten Aman
    |-- Lainnya
        |-- Pahami Kekerasan
        |-- Brankas Bukti
        |-- Pendamping
        |-- Laporan Awal
        |-- Pusat Bantuan
        |-- Aksesibilitas
        |-- Safe Exit

That structure matters because AmanAkses is not trying to force one linear path. Some users may only want to read. Some may only want to write one sentence. Some may want to prepare a timeline. Some may need to leave quickly.

The Expo prototype makes those choices feel reachable from a phone.

The product

AmanAkses is organized around a few careful spaces.

• Pahami Kekerasan — non-graphic learning content about sexual violence, user rights, and available support options.
• Jurnal Aman — a private writing space for gradual notes, prompts, and reflection without forcing the user into a report.
• Safe Timeline Assistant — an AI-assisted chronology builder that turns selected notes into draft events for review.
• Asisten Aman — a support assistant for navigation, grounding, and confirmed tool actions.
• Brankas Bukti — a simulated evidence organization flow for files, metadata, and review status.
• Pendamping Tepercaya — a place to think about trusted support contacts and access boundaries.
• Laporan Awal — a report preview that stays in draft until reviewed.
• Aksesibilitas — easy read, larger text, reduced motion, larger controls, and calmer interaction preferences.
• Safe Exit — a quick escape route into a neutral-looking screen.

The goal is not to make the user finish a report as fast as possible.

The goal is to make every step understandable, reversible, and clearly owned by the user.

AI boundary

The most important design decision in AmanAkses is also its simplest boundary:

AI can help arrange information, but it must not decide truth.

The Safe Timeline Assistant uses Gemini to turn selected synthetic notes into a structured chronology. The assistant receives only the selected note data needed for the task. It then returns draft timeline events in a structured format.

But the AI does not decide whether sexual violence occurred. It does not decide legal status. It does not infer blame. It does not diagnose trauma. It does not recommend final legal action. It does not submit anything automatically.

Every AI output stays in review.

Each timeline event keeps source references, uncertainty status, and a draft label. The user can inspect the source, edit the event, accept it, reject it, or leave it pending. Only reviewed events can move toward a report preview.

That boundary matters because a clean timeline can look authoritative. AmanAkses avoids that by making uncertainty visible and keeping human review inside the interface.

Selected notes
    |
    v
Safe Timeline Assistant
    |
    |-- Gemini live response
    |-- deterministic fallback
    v
Structured draft events
    |
    v
Validation
    |
    v
Human review
    |
    |-- pending
    |-- accepted
    |-- rejected

Asisten Aman

Asisten Aman is not designed as an all-powerful chatbot.

It is designed as a careful navigation and support assistant. It can help users understand where to go, prepare a journal template, explain a flow, or suggest a small set of allowlisted actions.

But it does not run tools silently.

Every tool action requires confirmation. Unknown actions are rejected. External routes are blocked. During urgent situations, productivity tools are paused so the interface prioritizes support pages, safe exit, and human help.

This made the assistant feel less like a chatbot that tries to answer everything and more like a limited support layer inside a safer product system.

Consent and safety

AmanAkses is careful about what it is not.

It is not an emergency service. It is not a therapist. It is not a legal advisor. It is not a diagnostic tool. It is not an automatic reporting system. It does not secretly collect evidence, record people, or submit data to outside institutions.

That limitation is not only a disclaimer. It is a product principle.

Sensitive software should not pretend to have more authority than it has.

In the prototype, safety appears through small constraints:

• AI output is always draft-first.
• Notes must be selected before timeline generation.
• Source references are required.
• Events without valid sources are rejected by validation.
• External routes are filtered.
• Unknown tools are rejected.
• Tool calls require confirmation.
• Urgent states block non-helpful productivity tools.
• Safe exit stays available as a first-class route.
• All scenarios use synthetic data.

This made AmanAkses less like an “AI chatbot for reporting” and more like a careful workspace with AI inside it.

Accessibility as product structure

Accessibility was not treated as a decoration or a final settings page.

It shaped the product structure from the beginning.

AmanAkses supports simple language, clear labels, readable spacing, large touch targets, reduced motion preferences, keyboard-friendly thinking for the web prototype, and mobile-first layouts that avoid overwhelming the user with too many choices at once.

The accessibility settings let users adjust the experience directly: easier language, larger text, larger controls, and calmer motion. These preferences help the product adapt to the user instead of forcing every user into the same interface.

The product considers different user states:

• a user with low vision may need stronger readability and clearer layout;
• a user with cognitive needs may need simpler language and smaller steps;
• a user with physical disability may need larger controls and fewer complex gestures;
• a user in distress may need a pause, a safe exit, or a route to human help;
• a user who is not ready to report may only need to write one small note.

The product is built around the idea that not every user is ready for the same next step.

Web and mobile together

The web version helped explore the wider workspace: dashboard, timeline review, chatbot, accessibility settings, and report preview.

The Expo version helped test the emotional and practical shape of the product on a phone: shorter sessions, tab navigation, local state, quick actions, safe-exit behavior, and mobile accessibility decisions.

Together, they made AmanAkses feel more complete.

Web prototype
    |
    |-- wider review space
    |-- dashboard-like overview
    |-- presentation-friendly flow
    |-- timeline and report review
    |
Expo mobile prototype
    |
    |-- closer to real user context
    |-- phone-first navigation
    |-- safer quick-exit interaction
    |-- mobile accessibility decisions

The web app shows the system.

The Expo app shows the moment of use.

That difference became one of the most important product lessons in the project.

Technical system

AmanAkses uses a lightweight prototype stack for both web and mobile exploration.

The web prototype uses React, TypeScript, Vite, Tailwind CSS, and serverless API routes. The mobile prototype uses Expo, React Native, Expo Router, and TypeScript.

AI endpoints stay outside the client bundle so the Gemini key is not exposed directly in the browser or mobile UI. The system also includes deterministic fallback behavior so the prototype can still demonstrate the core experience even when the live model is not available.

Client interface
    |
    |-- Web: React + Vite
    |-- Mobile: Expo + React Native
    |
    | POST /api/chat
    | POST /api/timeline
    v
Server-side AI routes
    |
    |-- Gemini available
    |       v
    |   structured AI response
    |
    |-- Gemini unavailable
            v
        deterministic fallback
    |
    v
Validation layer
    |
    v
Editable human-review UI

This architecture keeps the prototype focused. AmanAkses does not try to pretend it is a full production safety platform. It focuses on the key research question: how can AI help with preparation and documentation while keeping the user in control?

Validation

Because AmanAkses uses AI in a sexual violence support context, validation became part of the product story.

The prototype uses structured output, fallback behavior, allowlisted routes, source references, and review states. The goal is to prevent the AI from becoming an unchecked authority inside the product.

A responsible AI prototype cannot rely only on kind interface copy. It needs code paths that reject unsupported outputs.

AmanAkses uses:

• structured JSON response contracts;
• deterministic fallback;
• allowlisted internal routes;
• tool-call confirmation;
• source-grounded timeline events;
• human review states;
• synthetic scenarios for testing.

The core idea is simple: AI output should be useful, but never automatically trusted.

Visual direction

The visual direction needed to feel gentle without becoming decorative.

AmanAkses deals with sexual violence, disability access, and early support. The interface should not dramatize the experience or make the product feel like a crisis dashboard. It should also avoid feeling cold, bureaucratic, or overly medical.

I leaned toward soft surfaces, calm colors, rounded cards, practical iconography, and clear hierarchy.

The design goal was not a beautiful app screenshot.

The goal was a screen that lets someone pause.

AmanAkses should feel like a place where the user can take one small step, not a system that demands completion.

What I learned

AmanAkses taught me that building AI for sensitive domains is less about making the model sound smart and more about making the system around it careful.

The hard part was not only asking Gemini to return JSON. The hard part was deciding what the AI is not allowed to do.

It should not decide truth. It should not classify legal status. It should not infer intent. It should not pressure the user to report. It should not run tools silently. It should not continue productivity flows during urgent moments. It should not make a prototype feel like a production safety guarantee.

The best version of AmanAkses is not an AI that speaks with confidence.

It is a tool that knows when to help, when to slow down, when to ask for confirmation, and when to point back to human support.

The Expo prototype made that lesson even clearer. On mobile, safety is not abstract. It is the size of a button, the wording of a prompt, the speed of a safe exit, the calmness of a screen, and whether the user still feels in control after tapping one thing.

AmanAkses is a reminder that responsible AI design is often quiet. It lives in validators, fallback paths, consent steps, source labels, review states, and the small pauses that stop software from pretending it has more authority than it should.