Role
UX Researcher and Designer
Timeline
6 months
Tools
Miro, Visio, and Power Apps
Overview
A 6,000-person organization relied on two IT administrators to create every SharePoint and Microsoft Teams workspace.
Requests were inconsistent, unstructured, and often didn’t enter a formal system at all. Even when they did, administrators had to manually gather missing information before taking action.
Early identified issues
-
1-2 week turnaround time
-
No visibility for requesters
-
Constant bottlenecks
Discovery Research
Methods
Semi-structured interviews
-
7 Responses
Online surveys
-
18 Responses
Participant Job Roles included:
-
3 Project managers
-
4 Team leads
-
7 General employees
-
4 IT support staff
I intentionally recruited across roles to capture the entire lifecycle of a request, not just a single perspective.
Defining the Problem
"Beyond just a bad form this large organizations entire digital collaboration needs were dependent on a system that did not scale"
Key breakdowns
-
Information gap → admins had to follow up on every request
-
Centralized bottleneck → 2 people serving 6,000 employees
-
No visibility → users had no status or confirmation
-
Fragmented intake → requests came via email, phone, or unknown channels
Development
3 solutions were identified and implemented in tandem with each other to resolve the key breakdowns identified
-
A Federated Administration model
-
A Request App for users
-
a Creation App for administrators
The Federated Design Model
The organizational design decision that made this project possible, and the one that shaped every product decision after it, was the creation of a federated Collaboration Admin network.
Business units with 10 or more active workspaces demonstrated both high adoption of SharePoint and Teams and enough operational volume to justify dedicated local oversight. Each of the 15 qualifying business units was directed by their own leadership to appoint two Collaboration Admins from within their existing staff— individuals with strong working knowledge of SharePoint and Teams. 30 admins total, embedded across the organization, each accountable to their own business unit.
Old Centralized Model
New Federated Model
Request App
Designed for the 6,000-person employee base. Its job was to make submitting a workspace request as clear and low-friction as possible — collecting everything an admin would need to act, without requiring the requester to understand the technical architecture behind what they were asking for.
Welcome Screen
Form Screen
Submission Confirmation
Creation App
Designed for the 30 Collaboration Admins. Its job was to take a received request and execute it — accurately, consistently, and in compliance with organizational standards — with as little room for error as possible.
.png)
Welcome Screen
Form Screen
Rollout and lessons
Launch surfaced what testing couldn't: the human variability in a federated system.
A portion of Collaboration Admins came into the role with less working knowledge than their appointments had suggested. Early fulfillment produced errors in workspace naming and security configuration — caught through manual review by the original administrators and corrected through direct communication with the relevant admin. The two administrators who had previously owned all fulfillment shifted into an oversight role, reviewing created workspaces for compliance and flagging issues. It worked. But it reintroduced exactly the kind of back-and-forth the system was designed to eliminate, and isn't sustainable at scale.
The rollout also confirmed what the research had predicted about the Request App. A 10-question form, on a single page, asked more of users than the fulfillment process required. The data collected through the six additional questions has yet to be used or referenced since launch.
Both problems have a clear paths forward that I hope to tackle in future iterations.
What's next?
Error handling in the Creation App. The next phase focuses on building validation logic directly into the form — so that a workspace that doesn't meet naming or configuration requirements can't be submitted in the form it's in. Making the right way the only way removes the dependency on individual admin knowledge and eliminates the need for post-creation manual review.
A leaner Request App. Four questions served the fulfillment process. The path back to that is making the case with data — and the data now exists. The six additional questions have been collected against, their usage record is empty, and the cost to users is documented in the research. That's a strong brief for a redesign.
A desktop-formatted Creation App. A straightforward fix with a clear user rationale and a process lesson attached: device context is a requirement, not an assumption.
The multi-page form. The case for it was right when I made it. As platform constraints evolve, returning to that structure is the right long-term investment for the intake experience — and the research to support it is already done.
Post-submission status tracking and a discovery layer. Requesters still submit into relative silence. And with more than 700 workspaces in the environment, a pre-submission discovery experience that surfaces existing workspaces before a new request is initiated would reduce duplicate creation at the source. Both are the next frontier of a system that solved intake but hasn't yet solved visibility the problem the research identified from the beginning.
