Building a LegalTech Super-App: Mapping 7 Personas in Figma Before Writing Code

Most LegalTech apps are course platforms with a chat bolted on, or chat platforms with a forum bolted on. We built Legal Owl at Xenotix Labs as a real legal-education super-app: structured courses, a community forum, legal journals, and an Advisor Hub where users talk to lawyers via in-app voice or scheduled appointment. Seven distinct user personas, one product.

The biggest decision we made on Legal Owl wasn't an architectural one. It was a Figma one: we spent three full weeks mapping all seven personas in Figma before any engineering started. Here's why, and the architecture that followed.

The seven personas

1. Law student — wants courses, study notes, exam prep, peer community
2. Practicing junior lawyer — wants advanced courses, case-law journals, mentorship
3. Senior lawyer offering paid time — wants a clean booking system, payouts, calendar control
4. Volunteer lawyer answering free questions — wants moderation tools, batched responses
5. End-user with a legal question — wants quick anonymous answers + paid escalation
6. Course author — wants authoring tools, royalty reports, student feedback
7. Platform admin — wants moderation queues, payout management, analytics

Notice: a single "user" can occupy multiple personas at once. A practicing lawyer can also be a course author and a senior lawyer offering paid time. The persona is a role, not an identity.

Why three weeks in Figma

If we'd started building immediately, we'd have shipped an MVP for personas 1 and 5 (the easiest two), then spent 6 months retrofitting the rest. By mapping all seven up front, we caught dozens of cross-persona conflicts before they became code:

• Course authors and senior lawyers both need a "my earnings" view — one source of truth, two entry points
• Volunteer lawyers shouldn't see "paid escalation" prompts; the same question UI must hide one button based on context
• Admins need to see everything but never become a bottleneck for routine moderation — community moderators handle it day-to-day

These conflicts are designed in Figma. They're impossibly painful to refactor in code.

The role system

After Figma, we modeled the data:

users
  id, name, email, phone, ...

user_roles
  user_id, role_type (student | junior_lawyer | senior_lawyer | volunteer | end_user | course_author | admin)
  granted_at, granted_by, status, ...

role_capabilities
  role_type, capability (e.g. 'create_course', 'moderate_forum', 'accept_paid_call')

A user can hold multiple roles. The UI checks role_capabilities, never role_type directly. "Can this user create a course?" is user has any role with capability 'create_course'. Adding a new role tomorrow is data, not code.

The Advisor Hub: real-time voice + scheduled calls

The in-app voice call between a user and a lawyer is two-way audio with on-screen call controls and post-call notes. We use WebRTC for the audio path and a signaling service over WebSockets for setup.

The complications nobody warns you about:

• Call quality on flaky networks. A lawyer on Wi-Fi, a user on 3G in a Tier-2 city. We layer adaptive bitrate + reconnect-on-drop into the client.
• Lawful recording (where required). Some calls must be recorded for compliance. Recording is server-side, not client-side, with explicit consent UI before the call starts.
• Billing precision. Charges are per-minute, but the user expects to pay for the actual duration on their screen, not what the server logs. We reconcile both client and server timestamps and bill on the lower of the two.

Scheduled appointments are simpler: a calendar UI, time-zone-aware booking, automatic reminder notifications, a join-call button that becomes active 5 minutes before start time.

Course delivery

Our course module is a custom build, not a Moodle wrapper. Why: we needed to deeply integrate course completion with role progression ("complete this course to unlock the volunteer-lawyer application") and with the Advisor Hub ("after this course, book a 15-min consultation with the author").

Video is hosted on AWS S3 + CloudFront with signed URLs (24h expiry) so course content can't be hot-linked. Video progress is tracked at 5-second granularity for resume-where-you-left-off.

The forum and journals

The forum is a standard threaded structure (post, comment, reply) with role-aware moderation. Journals are long-form articles authored by senior lawyers with peer review; we built a lightweight "editor + reviewer + publish" workflow.

Both surface as separate screens in the app but share a unified search index, so a query like "contract breach" returns courses, forum threads, and journal articles together.

The admin panel

The admin panel has the longest changelog of any screen we've built. Operations live here: payout reconciliation, dispute resolution, user verification, course approval, journal publication, community moderation escalation, analytics. We built it as a Next.js app with role-based section visibility — every admin sees only the modules their role allows.

Stack summary

• Mobile: Flutter (iOS + Android)
• Web: Next.js (course web client + admin)
• Backend: Node.js microservices + PostgreSQL
• Real-time: WebSockets (signaling, chat, presence) + WebRTC (audio)
• Background jobs: RabbitMQ (course reminders, payout batches, appointment notifications)
• Architecture: Microservices (auth, courses, forum, advisor, payouts, notifications)
• Design: Figma (7 persona maps, full design system) → Production
• Deployment: AWS
• Testing: Unit → Integration → Production

What we'd tell other LegalTech teams

• Start in Figma. Stay in Figma. Map every persona before a single line of code. The cost of refactoring an architecture is 50x the cost of redrawing a flow.
• Roles, not types. Don't hardcode if user.is_lawyer checks. Build a role + capability system from day one.
• Recording is a compliance feature, not an engineering feature. Loop legal counsel in early; some jurisdictions require explicit signed consent before each recording.
• Don't build your own video hosting. Use S3 + CloudFront + signed URLs. The bandwidth math will surprise you.
• Build the admin panel as a first-class product. Operations teams use it 8 hours a day. If it's slow or messy, your operating costs balloon.

Building a LegalTech, EdTech, or multi-persona platform?

Whether it's legal, medical, financial, or any domain with regulated personas — the work is in the role mapping and the cross-persona flows, not the individual screens. If you're building one, Xenotix Labs has shipped this archetype across legal education, healthcare delivery, and edtech. Reach out at https://xenotixlabs.com.