Enterprise product consulting · Information architecture · SharePoint
Enterprise Collaboration Portals
The request looked like three website redesigns. The work was really three information problems — and one delivery system.
Every product visual is labelled by provenance, so original work is never confused with a portfolio-created explanation.
A genuine working document, wireframe, screenshot or output that can be shown publicly.
A recreated product view grounded in the original work, using synthetic or anonymised information.
A simplified model created for this portfolio to explain system behaviour, workflow or product logic.
The problem underneath three redesign requests
The issue was not missing content. People had to understand the organisation before they could find what they needed.
Enterprise platforms · Product consulting · Information architecture · SharePoint
Knowledge, operational resources, expert contacts and programme information already existed, but they were distributed across internal sites and organised around repositories or departments. The product challenge was to redesign access around user intent while keeping three fundamentally different enterprise jobs legible.
How do I find an answer, reusable knowledge or the right expert?
A repository model was insufficient because documents, discussion and people all participate in discovery.
Where is the metric, tool, report or resource needed to complete this task?
Users should not need to decode internal reporting lines before reaching operational resources.
Which rotation opportunity is relevant across geography, function and programme stage?
A single hierarchy could not represent a programme that crosses regions, functions and pathways.
One engagement · three product problems
One platform technology did not mean one information architecture.
All three products were delivered in SharePoint, but each served a different user intent. The product work was to identify the correct organising model before the interface was refined or built.
Turn a repository into a discovery system.
Employees needed to find reusable knowledge, discussions and internal expertise without first knowing where each item was stored.
Design three discovery paths — knowledge, discussion and people — as one connected experience rather than another department-led document library.
- Knowledge-base search
- Discussions and accepted answers
- Technical documents and articles
- Topic and business-unit filters
- Expert and support-contact discovery
Organise around tasks and resources, not the org chart.
Metrics, engineering resources, reports, tools and team information were distributed across organisational structures that did not match the user’s immediate task.
Create a shared entry point organised around what users needed to do or access, reducing the need to understand departmental ownership first.
- Digital and operational metrics
- Engineering and customer-experience resources
- Reports, tools and quick links
- Team profiles, tasks and calendars
- Ready-to-deploy operational resources
Use a matrix model for a programme that crosses boundaries.
The rotation programme spanned global, regional and functional dimensions, while opportunities, participants and programme stages all needed to remain understandable.
Use a matrix-style information architecture that exposes geography, function and programme context without forcing every user through one static hierarchy.
- Global, regional and functional programme views
- Rotation opportunities and deployments
- Associates, programme leadership and alumni
- Onboarding and training schedules
- Initiatives, outcomes, news and events
Information architecture as product strategy
The common product principle was user intent. The structures underneath it were deliberately different.
A knowledge system optimises for discovery. An operations portal optimises for task access. A rotation programme needs a matrix that can represent geography, function and stage. Reusing one navigation model across all three would have preserved the original fragmentation in a cleaner visual shell.
Design three discovery paths — knowledge, discussion and people — as one connected experience rather than another department-led document library.
Create a shared entry point organised around what users needed to do or access, reducing the need to understand departmental ownership first.
Use a matrix-style information architecture that exposes geography, function and programme context without forcing every user through one static hierarchy.
Do not make employees learn the organisation before they can use the product.
One delivery system across three products
I owned the product framing and the delivery system across all three portals.
My scope covered stakeholder discovery, requirements, information architecture, initial mock-ups and functional specifications, prioritisation, team formation, implementation coordination, testing, pilot, deployment and production monitoring. The UX designer and SharePoint developers handled specialist design and implementation work inside that operating model.
Stakeholder discovery and problem framing
Requirements and information architecture
Initial mock-ups and functional specifications
Prioritisation and product decisions
Testing, pilot, releases and production monitoring
UX and SharePoint implementation direction
One repeatable operating model created delivery consistency without forcing the three products into the same information architecture.
Delivered outcomes and evidence boundary
Observed outcomes
What changed after the redesign work moved into production.
Three existing internal sites were replaced with redesigned production portals.
Distributed information and resources were consolidated into clearer product structures.
Stakeholders reported easier navigation and improved access to documents and support contacts.
A shared delivery model created consistency while allowing each portal to solve a distinct user problem.
Successful delivery generated follow-on work and additional project discussions.
Three products reached production and were monitored after deployment. Stakeholder improvements are presented as observed signals; no unsupported adoption or percentage claims are used.
Public visuals in this case are portfolio reconstructions of the information and interaction models. Internal organisational data, employee information, URLs, system identifiers and proprietary TE Connectivity screens are not published.
What the work changed in how I think
Enterprise portals are product systems, not document containers.
Information architecture is a product decision.
A portal can contain the right content and still fail if users have to understand internal structures before they can act.
Different user jobs need different organising models.
Knowledge discovery, operational access and programme navigation could share a delivery process without sharing the same information model.
Small teams move faster when ownership is explicit.
Product framing, design refinement and SharePoint implementation stayed aligned because one delivery model made decision ownership clear.
Deployment is not the finish line.
Pilot, release coordination and production monitoring were part of the product scope rather than hand-off activities after design approval.