Introduction
What’s Abulé?
Currently a seed-stage startup, Abulé is a community based care-platform helping families by enabling mutually beneficial care exchanges.
Project Overview
I architected Abulé's dual-portal admin ecosystem and designed the Community Admin Portal, a role-based system that enables community creators to manage billing, permissions, and operations independently.
Timeline
2 months | Delivered launch-ready designs and dev documentation
Tools
Figjam, Figma, Linear, Microsoft Teams
My Role & Focus:
I led product design and IA strategy for this 0 to 1 product, working closely with the Founder and Lead Engineer. I defined the roadmap, simplified platform architecture, extended the design system and delivered MVP modules including navigation, billing, roles and access management, and event insights, establishing the design foundation for continued development.
TL;DR
Challenge: Design admin portals for 3 distinct user groups with overlapping permissions, within startup constraints (pre-launch product, 2-month timeline, limited engineering capacity).
Impact: Architectural decision saved ~25-30% engineering effort by avoiding duplicate systems; delivered 6-level role system with 65+ screens.
Approach: Led platform architecture mapping, defined role hierarchy and IA, extended design system, phased rollout strategy.
Abulé's web app was ready for launch but operational control and oversight was missing across three distinct user groups:
Problem
Without admin portals, communities would be unmanageable, billing would remain manual, internal teams had no visibility into member data or events. Fragmented workflows and support bottlenecks would block revenue & scale.
1. Map multiple user types with different permissions, and how internal teams and web-app community admins intersect operationally.
2. Every IA, permission, or navigation choice had backend, scalability, and roadmap implications, requiring close alignment with Eng. + Founder.
3. We had ~2 months to deliver a functional foundation while balancing the existing engineering lag on the member-facing web-app.
Key Challenges
My first step was aligning with the founder: clarifying expectations and agreeing on a realistic 2-month roadmap for a 0→1 delivery.
Let’s Dive In
To move from ambiguity to clarity, I followed a modified design-thinking process adapted for a fast-paced environment with limited research resources. I focussed on:
Who are the users?
What are their goals? What tasks would they perform?
Where does the Team managing Abulé’s core community belong?
What must ship first to unblock launch?
Research
The PRD made one thing clear- we needed two admin environments:
1. Community Portal for → Web-app members who manage their communities
2. Company Portal for → Abulé’s internal operations teams (leadership, sales, product, support etc.)
Insights from PRD
User Input
Working with a pre-launch product, I gathered indirect user input through the Founder's sales conversations with potential community organizers. Those conversations helped shape how roles, access, and core admin features were designed.
Based on the insights and through sessions with the Founder and Platform Team, I developed clear permission boundaries and role-based access built into Community Portal and defined six hierarchical roles of community admins.
To avoid engineering redundancy, we needed to identify:
Shared data points between Community and Company portal.
Where does the Core Community Team managing Abulé’s default community fit, in Community or Company portal?
Define Platform Architecture
#1 Identifying Shared Data Points
I mapped intersection areas between community and company portal to identify shared data and workflows, revealing four areas with different scopes and the backend touch-points engineering needed.
Design Implications for intersection areas:
#2 Where does the Core Community Team Fit?
The Founder and Lead Engineer initially leaned toward the Company Portal because the team is technically part of Abulé’s internal operations. But analyzing their day-to-day tasks proved they functioned as community managers.
I found out that organizationally they belonged to the company…
To unblock this decision, I mapped their tasks and weighed pros and cons of two options with the Founder and the Lead Engineer:
Seeing the side-by-side comparison helped the engineering lead realize that by changing where the Core Community Team logged in, we could avoid duplicate auth, role management, and data access work, saving ~25–30% of engineering effort (about 3–4 weeks).
Option 2 Was Saving Us Dev Time. It Was Huge.
i still had to address engg. concern
It Was Getting Real
Prioritizing community portal’s IA
With architectural decisions made, I prioritized Community Portal's IA since communities couldn’t launch without, billing setup, admin delegation, and basic configuration.
Early research showed that admins spent most of their time on strategic community management with task delegation and settings accessed occasionally. This led me to define two primary areas in the IA- management tasks and backend tasks.
I aligned the Founder with this IA…
…and gathered content requirements around what around what admins needed to see and do: key metrics, member details, and event data that support day-to-day decisions.
This helped me structure the Community Portal into 10 sections, designed with role-based access from the start. Key decisions:
Most roles can access core areas like Dashboard, Members, and Events, while moderators and group admins see these in read-only or scoped views.
Higher-risk areas like Manage Admins and Settings are limited to higher roles.
Core community management lives in the main sections while less frequent, backend tasks are grouped under Workspace.
Manage Admins and Settings (solid outline) were Phase-1 priorities.
All dashed items were next-launch features, planned but deferred for MVP.
With the IA defined, I needed to validate it would actually work for all six roles but with limited time and engineering resources already stretched, I couldn't design from scratch.
Testing The IA
My approach: Adapt the existing web-app design system to prototype navigation quickly then test it against each role's permissions.
This reduced design & engineering lift while giving admins a familiar interaction model. What I reused:
Core layout: left nav, top bar with a shared hamburger menu, workspace structure
Navigation patterns: tab headers for sub-sections
Interaction model: drawers, dropdowns, familiar UI components
Using existing components and navigation patterns not only sped-up development, it ensured a seamless experience for members switching from web-app to admin portal
Testing for Role-based Access
It was critical to validate that the IA worked for all six admin roles. Each role should only see what they have permission to access without confusion or overwhelming options.
Design principles we landed on:
Inheritance: Higher roles automatically get lower role permissions
Scope-based: Community-wide vs. group-specific access
At or below level: Admins manage only roles beneath them
Navigation for community-wide roles: Owner/ Super Admin, Admin, and Moderator
Navigation for group-wide roles: Group Admin, Group Moderator
“We can't build all of this in 2 months!”
When I presented this structure to the Founder and Lead Engineer, their reaction was immediate “We can't build all of this in 2 months.”
Designing all 10 sections with 6 role levels was the ideal solution but building it end-to-end would have taken far longer than our timeline allowed. So, we agreed to design the full structure upfront but ship it in phases.
Phased Roll-Out strategy
Because moderation, requests, and events were already in the web-app, we didn’t have to include them in first Admin Portal release. That saved engineering time. Phase 1 only served roles who needed Settings and Admin Management.
Navigation per launch phases
Designing Launch Blockers
Settings
Different admins needed different levels of control in Settings; Owners needed full access, while Admins should not see or touch billing or sensitive setup. To support scalability and role-based access from day one, I structured Settings into three tabs:
General: enter and update general info
Plans & Billing: manage plans, payments and upgrades
Privacy & Security: edit community visibility and membership approval
Prototype shows how an Owner would use the Phase-1 admin portal. I reused the same drawer pattern from the web-app, so the experience felt familiar and was quicker for engineering to build.
Navigation with just Manage Admins and Settings
Settings → General: update community info using drawers
Settings → Plans & Billing: edit payment methods and upgrade plans, also through drawers
Admin Management
Admins needed to understand roles without accidentally changing permissions while learning. Key design decisions:
To reduce mental load and prevent mistakes, I split Manage Admins into two tabs:
Admins: view all admins in the community, their roles and activity, take quick or bulk actions and add new admins.
Roles & Access: understand what each role can do and create custom roles (in paid tiers)
Allowed admins to have multiple roles so one person can manage the community broadly while owning specific groups, without duplicating accounts.
Admin role management with built-in guardrails:
Roles are color-coded for quick recognition
Action menus adapt by hierarchy. Admins can only edit or remove roles below their level.
In this flow, an admin promotes a group moderator to admin, reviews the added permissions step-by-step, then
Adds a new admin through a guided drawer that only shows eligible roles and members
As part of the platform architecture strategy, I designed the Company Portal's Events dashboard to establish UI patterns for the most data-intensive intersection area. I designed these components to work for both aggregated (Company) and localized (Community) data, ensuring consistency while reducing future design and engineering effort.
Company Portal Events
Key patterns we agreed upon:
- Overview tab for analytics and Events List tab for management
- Click charts to drill into event details
- Multi-layer filtering (community, date range, event type, status)
- Scalable table design (columns, sorting, actions)
I delivered the Community Admin Portal design within the 2-month timeline, including launch-ready designs and the underlying platform architecture with documentation for engineering handoff.
Outcome
Community Admin Portal deliverables
Strategic Foundation
Impact
Working closely with the Founder and the Lead Engineer, taught me how much clarity, speed, and collaboration matter and I’m proud of what I delivered. The admin portals are now in development, and the architecture decisions we made continue to guide Phase 2.
In 0→1 work, getting stakeholder alignment on the problem is harder than designing the solution. I spent 2 weeks mapping user groups and architecture before touching UI, which felt slow, but helped me turn ambiguity into clarity and prevented months of rework
Designing for launch while keeping things scalable was the hardest part. I built only what Phase 1 needed, but defined the full structure upfront so future features could be added by turning things on, not reworking the system.
Bringing engineering into conversations early saved time and rework. Asking questions about feasibility upfront helped shape better, more realistic solutions, faster.