Rebuilding Information Architecture
Restructuring a resource library to a mental model that made sense
Client: Oil and gas sector
Role: Product Designer
Context
A key client in the oil and gas sector approached us to create a proof of concept for a new version of their resources library, which had been taken offline due to user frustration and complaints about finding information. We were asked to povide two low-code designs for them to choose from, one based in Microsoft Sharepoint and one in Power Apps.
Historically, product designers were rarely involved in no-code projects, but when I pointed out we could save development time by having me iterate with the client on mockups instead of building two separate PoC's, that got me on board.
Challenge: The library's poor architecture, outdated info, and unclear microcopy made it difficult for users to find what they needed.
Constraints: We were limited by no access to end users to validate assumptions, no analytics since the system was offline, and a tight budget and timeline.
Research & discovery
I started with stakeholder interviews to understand their perspectives, define the problem, and align on definition of success. I had them walk me through the existing solution, identifying pain points and areas of frustration. The primary decision-maker kept suggesting an experience like “apps on an iPhone,” which helped me uncover the real ask: make resources clearly visible and avoid a multi-level folder structure.
During the content audit, I found resource links buried behind a huge grid of tiles (an attempt at that "iphone" experience) with confusing labels, broken links, and no clear action for the user. I dug in and audited hundreds of tiles to identify what worked, what didn’t, and how the resources aligned with user tasks.
Original Sharepoint Library
Design
I used the natural groupings that emerged during the content audit to create an updated information architecture and iterated on this framework with the client.
Original sitemap
Revised sitemap
Once the information architecture and sitemap were established, I designed parallel experiences in Figma for both SharePoint and Power Apps, with a focus on using out-of-the-box components to set the client up for easy future maintenance. We presented the client with two solution options:
Power Apps: Offered greater customizability and a few additional features, but required users to leave SharePoint and navigate to a separate system. It would also exceed the timeline and budget for the PoC.
SharePoint: Less flexibility, but leveraged a platform users were already familiar with. This option would allow us to deliver a complete, functional solution within the project window, that they could easily edit and maintain without our help. This is the option I recommended.
Outcome
Intuitive, on time, and under budget
The client selected the Sharepoint option and the developer and I tag-teamed the migration process. Between the two of us we delivered the client a fully functional solution on time, with budget to spare.
When we demonstrated the final SharePoint site, the stakeholders were impressed by how intuitive and navigable the site was. They implemented the new design immediately, and this project led to continued engagements with this same business unit.
"When you see the new solution and it seems obvious, that's how you know you have a good solution."
IT stakeholder
What I learned
Don't get stuck on user interviews — there are lots of research options!
I pushed hard to highlight the risk of not doing user research in this project, but the client was opposed to us shadowing or interviewing their users and wouldn't budge. In hindsight, I didn't adequately explore my research options —when they said no to interviews I took that as a "no" to any user research. If I could go back, I’d suggest unmoderated remote usability tests like tree-testing and see if they are more open.
Mockups for Sharepoint are overkill
Once I dug deeper into Sharepoint and realized how easy it was to to configure the options I wanted myself, I dispensed with further mockups. The mockups did give us a head start since we didn't have access to the client Sharepoint environment right away, and Figma component sets made it fast, but in future I would just build a sample page in our own environment.