Product
Information architecture
Consumer app 4-tab IA — Home, My Bills, Analysis, Offers
Information architecture
Canonical consumer IA lives in the iOS client (AppTab / RootTabView in efacts-iosapp).
Docs chrome ≠ product chrome
dev.efacts.ca uses a spacious, retractable sidebar. Do not put the consumer tab bar into docs navigation. See also Product IA (Design language).
Four tabs
| Tab | Purpose | Typical contents |
|---|---|---|
| Home | Hub | Alerts, shortcuts, orientation into the rest of the product |
| My Bills | Vault | Digital receipts / bills — returns, warranties, line detail |
| Analysis | Insight | Spend and category breakdowns over time |
| Offers | Growth | Retailer offers and redemption |
Auth gate
Unauthenticated users land on auth (email / password and/or Google) before the root tab experience (AuthPortalView → RootTabView).
Adjacent, not a fifth tab
| Area | Placement |
|---|---|
| Profile / account | Drawer / adjacent chrome |
| Settings | Adjacent to profile |
| Wallet bind | Explicit flow — not a permanent tab |
IA principles
- One primary job per tab — do not turn Home into a dumping ground.
- Bills is the source of receipt truth in the UI — Analysis and Offers reference it; they do not replace it.
- Deep links resolve into a tab + screen, not a parallel navigation tree.
- Empty states teach the job — especially first receipt and first bind.
Mapping docs ↔ product
| Consumer tab | Closest docs home |
|---|---|
| Home | Getting started |
| My Bills | Product |
| Analysis | Metrics · Design language |
| Offers | Feature lifecycle |
| Profile (drawer) | Engineering / auth |