1. Problems with the Original IA
The original OKRoger IA showed typical symptoms of an organically grown product:
-
Features added incrementally over time
-
Sections mixing configuration, operations, and reporting
-
Related elements (policies, approvers, exceptions) scattered across different areas
-
A flat hierarchy where:
-
critical items were buried
-
secondary items lived at the top level
-
In short:
The IA reflected internal system evolution, not the user’s mental model.
OK Roger UI
Visual map of the current UI
2. The Shift to a Task-Based IA
The redesign starts from a core decision:
Organize the IA around admin responsibilities and tasks, not technical modules.
This required stepping back and asking:
Who is the main user?
I defined it as The admin user. Is the only user Swovo has information about.
​
-
What responsibilities does an admin actually have?
-
What decisions do they make regularly?
-
What do they configure once vs. monitor over time?
-
What requires immediate attention vs. periodic review?
3. The Admin Mental Model
(Foundation of the New IA)
An admin typically reasons about their work in this order:
-
Who can travel?
→ people, roles, permissions -
Under which rules do they travel?
→ policies, limits, exceptions, approvers -
What needs my attention right now?
→ approvals, alerts, incidents -
Is the system healthy?
→ compliance, policy status, risk indicators -
How is the travel program performing overall?
→ spend, trends, reports
The new IA mirrors this logic—even if it isn’t presented as a strict linear flow.
🧩 Team & Access
All people-related configuration lives in one place:
team members roles & permissions directory sync integrations
​
Why:
Admins need a single, predictable location to answer “Who has access and under what permissions?”
🧩 Travel Policies
Policies are treated as a living system, not static rules:
-
all policies
-
exceptions
-
tiers
-
notifications
-
approvers
-
rules
​
Why:
These elements are conceptually inseparable in the admin’s mind and should not be scattered across the product.
🧩 Approvals
Approvals are separated from policy configuration.
​​
Why:
Configuring workflows is a different cognitive mode than handling daily approvals.
This separation supports focus, speed, and clarity.
🧩 Analytics
Analytics is isolated as a read-only, insight-driven space.
​​
Why:
When admins enter analytics, they are not trying to configure or act—they are trying to understand performance and trends.
🧩 Dashboard (home)
This is a “set-it-and-forget-it” system.
The dashboard answers two questions instantly:
“Is everything under control?”
“Do I need to act on anything right now?”
​​
Why:
This is a “set-it-and-forget-it” system.
The dashboard answers two questions instantly:
“Is everything under control?”
“Do I need to act on anything right now?”
That’s why it surfaces only:
-
pending approvals
-
alerts & incidents
-
policy health
-
budget snapshot
No configuration.
No long tables.
Only signal.
4. Rebuilding the Information Architecture
5. Wireframing
6. Mockup
Open side bar
Closed side bar
7. Prototype
Prototype for explaining purposes