Aon Meridian.
One workspace.
Connected products.
Product introduction by Aon. Read the official Meridian overview
A shared workspace for Aon clients.
Aon Meridian brings insurance-program information and specialist tools into one place. Clients can find documents, invoices, certificates and high-level claims information, with access shaped by their role.
I led the administrative UX for client setup, defining the information structure, selection and summary states, and connected prototype paths across group and application assignment.
Select Client.
Start with the organization being configured. Client identifier, parent and tenant choice appear together before any assignments.
A name alone does not establish tenant context. Grouping these details gives the administrator a place to check the setup before moving on.
Context comes first, at the cost of another step. The later screens do not retain this context—a gap I would revisit.
Add Client
- 1Select Client
- 2Assign Groups
- 3Assign Applications
Select Client
Please select a client to add to the system.
- Client Name 2
- Example Company
- Client ID
- DEMO-001
- Parent
- Example Group
- Regions
- Example Region
- Status
- Active
- Select Tenant ID 3
- Select
Assign Groups.
Group assignment has its own workspace. Search and candidate rows sit beside a summary of the groups added to the setup.
Selecting a row and adding it are distinct states. The explicit Add action moves the workflow from a tentative selection to a populated summary.
A dedicated group step clarifies the task but requires more navigation.
Swipe the table sideways to view all columns.
Add Client
- Select Client
- Assign Groups
- Assign Applications
Assign Groups
Please search and assign groups to the client.
| Group Name | Description | Group Type | Status | |
|---|---|---|---|---|
| Example Client Team | Users supporting Example Company | Client Entity | Active | |
| Example Service Office | Example office group | Servicing Office | Active | |
| Example Functional Group | Example working group | Functional | Active |
Assign Applications.
The same search, selection and summary pattern supports application assignment. Scopes, tenants, owner and environment help distinguish each application.
Reusing the interaction keeps the task familiar while preserving the context each product needs.
These extra columns make the table denser. Scope and tenant values are placeholders in the source; the design establishes the information structure.
Swipe the table sideways to view all columns.
Add Client
- Select Client
- Assign Groups
- Assign Applications
Assign Applications
Please search and assign applications to the client.
| Application Name | Allowed Scopes | Allowed Tenants | Owner | Environment | |
|---|---|---|---|---|---|
| Example Application A | [Example scope] | [Example tenant] | Example owner A | DEMO | |
| Example Application B | [Example scope] | [Example tenant] | Example owner B | DEMO | |
| Example Application C | [Example scope] | [Example tenant] | Example owner C | DEMO |
Before and after Add.
Two linked prototype frames show the transition: the summary becomes populated and the table selection count returns to zero.
The extra action makes the transition explicit. Both areas use “selected” language, which is a clarity issue I would revisit.
Before & after Add / Interaction detail
Selecting rows and adding groups are separate actions.
The original Add action connects a state with two selected rows to a state with a populated summary. The table selection count then returns to zero.
Before Add
No group has been selected yet.
After Add
- Example Group A
- Example Group B
Design tradeoff: the explicit Add action separates tentative table selection from the summary, but adds an action to the task. Both areas use “selected” language, which is a clarity issue I would revisit.
Shared structure.
Product authority.
The interface provides a consistent way to configure assignments. Each product retains the meaning of its permissions and the actions a role allows.
Group and application tables share an interaction pattern while exposing different information. Configuring those assignments and enforcing authorization are separate responsibilities.
A consistent way to administer access.
How administrators work
- Identify the client and application context
- Configure and assign access
- Understand the scope of the task
What access permits
- The actions a role allows
- Each product’s permission definitions
- The product’s authorization rules
Shared administrative structure Explicit product authority
Explore the responsibility model and requirements context
Access & responsibility / Conceptual model · Editorial illustration
Share the administrative structure.
Preserve product authority.
The interface provides a consistent way to configure assignments. What a person may actually do is a separate authorization question.
Shown in the original Admin design
Configuration taskAdministrator
Configures assignments for the selected client.
Client + tenant context
Established before assignment. Tenant is not equated with a client account.
Groups
Organizational group choices, type and status.
Applications
Application choices with scope, tenant, owner and environment.
These are separate assignment steps. The shown flow does not establish a Group → Role → Permission inheritance rule or name the administrator’s business role.
Requirements context — not demonstrated in this prototype
The requirements ask: which named user, within which client/account scope, may access an enabled feature—and which actions does their approved role permit? These are access conditions, not additional prototype steps.
- Who receives access
Person / named user
A specific client or colleague user.
- Where it applies
Client / account scope
The relationship in which access is granted.
- What is available
Enabled feature
Availability to a client does not grant it to every user.
- What is permitted
Approved role & permissions
A role defines a set of responsibilities; permissions specify the actions allowed for that role.
Contact record ≠ granted accessRecording a person is separate from authorizing them.
Authentication ≠ authorizationSuccessful sign-in alone does not grant product permissions.
Visible in my UI: group and application tables reuse the same search, selection and summary pattern while showing different columns. The interface makes those distinctions visible; product-specific permission interpretation remains outside the demonstrated flow.
A connected workflow.
I delivered client setup interfaces, assignment interactions and connected prototype paths across the three setup stages.
What I would revisit
Keep the selected client and tenant visible throughout the later stages. A persistent context summary would let administrators recheck who they are configuring.
This is a retrospective recommendation, not a feature shown in the original work.
Delivery scope and evidence limits
The delivered scope is design and prototype work. Production integration, successful saving, authorization enforcement and rollout remain unverified. The sources do not establish research findings, usability improvements or business impact.
A dated iteration history, removal outcomes and selection persistence when navigating back remain unverified. Later requirements for named-user access and delegated administration are separate from the demonstrated Admin prototype.
