King Abdulaziz
University -
two portals,
one system.

KAU needed an internal system to run student service requests through a layered academic approval chain, plus a student-facing portal to submit and track those requests. I designed both, solo, in Arabic and English, on top of Camunda-powered process flows, in one month.

The core design problem: neither portal is really one portal. On the admin side, each user type - Super Admin, College Dean, Department Head, College Graduate Studies Dean, College staff, and more - has its own navigation, permissions, and approvals. On the student side, the experience adapts to the student's type, college, year, and academic standing, so a student on a postponed term doesn't see the same services or states as an active one. On top of that, the approval chain a request follows changes from one service to the next. The job was to make all of that read as a single, coherent system in two languages.

King Abdulaziz University is the largest university in Saudi Arabia by enrollment and one of its longest-established, with student services flowing through a deep academic hierarchy of departments, colleges, and deanships. The client wanted that entire chain - from a student's submission to the final decision - to live in one internal system: admins managing services, news, committees, and reporting; students self-serving and tracking their own requests.

The catalogue spans 13 services, each with its own small differences but all following the same underlying flow. Because the portal existed to make a tangled, multi-step approval process legible, the design itself had to make that complexity feel simple at every individual step.

Mine. Everything design, solo. Information architecture for both portals; all role-specific approval views; the complete bilingual (RTL/LTR) design system and component library; the request timeline; the dashboards and statistics; news and announcements management; the rating and feedback patterns.

Shared. The flow logic. I designed against the Camunda BPMN process definitions that engineering and the client owned, translating each process step into a screen and a role. Delivered through BitBang, with BitBang engineering implementing the Camunda flows and integrations.

Set by others. The business requirement - an admin portal and a student portal - the contents of the 13-service catalogue, and the per-service approval chains themselves.

The university owned what the process is; I owned how people move through it: how it's structured, how each role sees it, and how it reads in two languages.

What people struggle with. A student request doesn't go to one approver. It passes through a chain of role-based approvals, and that chain differs by service. One graduate-studies request might run Department Head review, then College Graduate Studies Dean, then College Dean, then College staff; another routes through a different set of roles in a different order. Each approver has a distinct job to do on the same request. Without a system, status is opaque: students can't see where their request is or who's holding it, and each approver lacks context on what the people before them decided and why.

How I framed it. The brief looked like "build a portal for requests." The real problem had two axes. First, who you are drives the whole experience, on both sides - user type on the admin side; student type, college, year, and academic standing on the student side. Second, the approval chain itself changes shape from one service to the next, so which people are involved, and in what order, is never fixed. How do you let identity drive what each person sees and does, let the service drive the chain they sit in, and still have every request read as one coherent thing, in two mirrored languages across all 13 services?

The one-month timeline meant discovery was light and front-loaded into the things that actually constrained the design: the Camunda process definitions and the client's role hierarchy, rather than open-ended user research. I treated the process flows as the source of truth, mapping each BPMN step to a role and a screen, and designed outward from the request timeline as the spine that both portals share.

Success was judged qualitatively given the scope and timeline. The working bar was concrete: every user type can act on a request without having to ask "what happened before me," the two portals read as one product, and everything works the same way in Arabic and English across all 13 services. Shipping both portals, coherent and fully bilingual, in a month was the target - and the client put it straight into live use.

User type is the architecture of both portals. Each side becomes a different portal depending on who you are - user type drives navigation, permissions, approvals, and how a request renders. Modeling around identity, rather than one flag-gated portal, means everyone opens something built for their situation.

One flow, thirteen services, chains that vary. Each service carries its own approval chain - different roles, order, and length. The service sets who's in the chain; the user type sets what each sees. Both meet on one shared timeline, and designing the flow once while varying only the chain kept 13 services and two portals reading as one system.

Designing on top of a process engine. Camunda models the flow in BPMN, but users shouldn't see engine vocabulary. I mapped each state to plain-language status so "who has it, what's next" is always answerable from the request view - reflecting the engine without exposing it.

A complete design system in two directions. Arabic isn't a text swap - the whole layout mirrors, and mixed content (Arabic with Latin numerals, IDs, dates) must read both ways. One design system holds in LTR and RTL, so every screen renders correctly in either language from the same source.

• User-type-driven experience. Each admin is one of several user types. User type sets their navigation, permissions, the approvals in their queue, and how every shared screen renders for them.
• Home dashboard. Customizable, with pinned items and at-a-glance statistics: completion rates, the user's own active tasks, and the students' active tasks tied to that user.
• My Tasks. Requests assigned to me, plus a view of all service requests across the portal.
• Service catalogue. The 13 services that every request originates from.
• Request timeline and role views. A per-role decision view with full access to prior approvals and comments.
• Committees. Create and manage review committees.
• News and announcements. Author with cover images, publish, deactivate, and delete; surfaced into the student portal.
• Reports, statistics, and audit trails. Completion and activity reporting, performance and SLA views that surface bottlenecks, plus a full audit history.
• Notifications. System-wide alerts for new requests and tasks.

• Identity-aware experience. The portal adapts to the student's type, college, year or seniority, and academic standing. What they can request, and how a request behaves, changes with their situation - a student on a postponed term sees a different set of services and states than an active one.
• Student profile. Personal details and standing.
• Service catalogue requests. Submit a request from any of the 13 services.
• My Requests. Active, pending, and completed tracking on the shared timeline.
• Edit and cancel. Amend or withdraw a request while it's still in flight.
• Ratings and comments. Rate each service and leave feedback.
• News and announcements. The feed published from the admin side.

A shared component library, one bilingual design system, and a single request-timeline model underpin both portals and all 13 services, so the admin and student experiences read as one product in either language.

Shipped both portals - admin and student, fully bilingual - in one month, solo. The client was happy with the result, and the portal went into live use: internal university staff across roles and students both started using it.

At the platform level, the client reported faster approval turnaround and more consistent, transparent service across departments after launch. Coherence held across both portals, multiple admin user types and student segments, 13 services with differing approval chains, and two mirrored languages - all on a single design system and component foundation.