Enterprise System
Redesigning how employees navigate and access information across a complex, permission-based enterprise environment.
Role: Product Designer (Design Lead) & IA
Timeline: 6 Months
Organization: The Daniels Corporation
Platform: M365 & SharePoint Intranet
Team: Information Technology
My Contribution: Translated the existing information architecture and business requirements into a new enterprise-wide system, from structure through implementation.
The Challenge
The organization needed a centralized internal platform where employees could easily access information while ensuring each department only saw the content relevant to their role.
-
fragmented information
-
different employee needs
-
permission requirements
-
navigation/wayfinding problems
-
organizational constraints
-
content ownership/governance
Objectives
01
Organize Information
Consolidate scattered content into a logical, findable structure.
02
Integrate & Simplify Permissions
Replace ad-hoc access with a governed, role-based model.
03
Improve Navigation
04
Create a Scalable System
Build consistent wayfinding across all department hubs.
Design for growth so the platform ages well without rebuilding.
Before designing the interface, I needed to understand the system.
Two perspectives on the same broken system
Business Goals
User Pain Points
-
Centralize company resources into one governed platform
-
Improve content governance and ownership clarity
-
Reduce manual permission administration overhead
-
Support future departmental growth without rearchitecting
-
Enable self-service publishing with appropriate controls
-
Employees couldn't find documents- search was the only path
-
Too many clicks to reach frequently accessed content
-
Inconsistent page layouts confused users between departments
-
Access requests slowed work; no self-service option
-
Unclear who owned content or how to update it
From ambiguity to insight
I combined stakeholder research with a content and permissions audit to understand both how employees expected to navigate the platform and how the existing system was structured.
01. Stakeholder Interviews: 12 participants across 4 departments
02. Content Audit: 1200+ folders catalogued and categorized
03. Department Mapping: Ownership and audience defined per site page
04. Permission Analysis: Existing groups reviewed and rationalized
05. Site Architecture: New IA proposed and validated
Key Insights
Employees searched instead of navigating.
Different teams required entirely different visibility rules, different access levels on the same content.
Too many unique, ad-hoc permission groups created a maintenance burden that no single owner understood.
Departments wanted autonomy over their content, but needed guardrails to stay consistent with the whole.
Information Architecture
A structure built for how departments think & navigate.
The previous environment had grown organically, with departments storing files independently. Taxonomy decisions were made locally, leading to overlapping content, and duplicated libraries.
Reduced cognitive load - Grouping by audience role, not by content type meant users landed in familiar territory immediately. Each department hub mirrors the same structural template, so learning one means learning all.
Predictable hierarchy - No site sits deeper than three levels from the homepage. This decision eliminated the navigation dead ends that users previously complained about in exit interviews.
Scalable by design - New departments can be onboarded by cloning the department template. Governance rules, permission groups, and content types are inherited automatically, with little one-off configuration needed.
Search as a second path - By making navigation reliable, we shifted search from a necessity to an accelerant. Users who know where they're going navigate; users who want to explore using search.
Designing for security without sacrificing usability
The permission model was the most technically complex and politically sensitive part of the project. The goal was a system anyone could understand, no one could accidentally break or override, and IT could maintain without a spreadsheet.
User Flows - 3 Journeys
Wireframes & Shared Components
A component library ensured every department page felt part of the same platform, while allowing each team enough flexibility to reflect their content.
Final Platform
Final deliverables included five core page templates, a component library, and a governance guide handed to IT for ongoing administration.
Measurable Outcomes
30 %
Fewer Support Requests
Related to navigation and access within 60 days of launch.
40 %
Faster content publishing
Department owners reported publishing and storage indication in minutes, not hours of communication.
220 +
Employees Onboarded
Transitioned to SharePoint sites in a phased rollout.
Final Reflections
What this project taught me
What worked
Challenges
Future Iterations
Designing permissions as a system rather than a page-by-page decision was the right call. Treating it like an architectural problem with inheritance, ownership, and principle-based rules gave IT a model we could actually maintain. It also gave stakeholders a framework they could reason.
Balancing departmental flexibility with platform-wide governance was the defining tension of this project. Every department wanted exceptions. Negotiating those exceptions required close collaboration, explicit trade-off conversations, and iterative refinement.
I'd introduce analytics tracking from day one: search queries, most visited pages, zero result searches to continuously improve the IA post-launch. I'd also conduct a structured usability study with novice users before handoff, and optimize the search relevance model with real usage data.