By Siobhan King |
May 30, 2025
Information Architecture: Standardisation vs Customisation
It was great see so many of you at the recent IRMS Conference 2025 in Birmingham.
You may have seen Siobhan King, Senior Consultant here at Metataxis, live on stage together with Melody Allsebrook, sharing the work they have delivered for Historic England, to help this national heritage organisation develop an information architecture to accelerate SharePoint adoption.
One of the aspects this paper explored was the need for standardisation while still respecting the organisation’s requirements for customisation. Standardisation and customisation both have their benefits and drawbacks, so the question becomes: how do you find an acceptable middle ground between the two?
Siobhan shares her thoughts and her top five tips to balance standardisation with customisation:
Site Standardisation
It is no secret that the best way to adopt Microsoft Teams or SharePoint quickly is to use a standardised Information Architecture (IA) model. Providing everyone with a standard site or Team is advantageous for swift rollout. However, this approach carries the risk of issues with uptake, as colleagues may reject SharePoint sites that do not reflect the way they work or the way they perceive their environment. The standardised site structure may feel reminiscent of an option available in a 1980s Eastern Bloc state, but for many organisations, the alternative is even less appealing.
In reality, “standardisation” means no IA model at all. Everyone receives a blank slate “to completely ruin” (sorry, Freudian slip), should I say “to structure and update” as they see fit. This leads to divergence, which increases complexity over time. Initially, this approach may appear low-cost and low-effort, but it sows the seeds for high-cost, high-maintenance challenges and remediation in the future.
Site Customisation
Conversely, organisations that opt for the customisation of SharePoint sites and Teams often find themselves bogged down in the minutiae of local requirements. Consultations and development of structures may take several months, leading to adoption dragging on for years with no end in sight.
The challenge with the customisation model is that, without an overarching framework, there is no clear endpoint for adoption. It becomes an ongoing task akin to painting the Forth Bridge—never-ending and stretching organisational resources beyond their limits. Any adoption model that includes customisation requires an organisation-wide map of the information landscape to quantify and define the rollout timeframe.
Striking a Balance
Rather than viewing standardisation and customisation as adversaries, it is essential to integrate elements of both into the IA model. The smartest approach to IA development is identifying commonalities within the organisation and incorporating them into a standardised structure. This core structure allows for customisation and local refinements.
So, how do we achieve this balance? Below are my top five key considerations for building a standardised IA.
Top Five Tips to Balance Standardisation with Customisation
- Look at your requirements and IA objectively to decide where the line should be drawn between standardisation and customisation. Where you draw that line will depend on the compliance and security needs of your organisation.
For example, if your organisation groups all its information by project, each of which is kept on an Microsoft Teams site, and all site content has the same retention value, you are likely to be very comfortable allowing owners and members to create channels, columns, and choices. If you have a more complex structure on which your Purview records labels and policies are dependent, you may want more controls in place.
- Look for commonalities to develop your standardised structures. Look for things that are authoritative and that people can agree are true. Get people to reflect on the common purpose for all employees within the organisation. In theory, they are all coming to work to achieve the same overall goal, and this brings some sense of unity to the conversation.
For example, if everyone is working for a charity whose goal is to improve the lives of a particular cohort, consider how this guiding goal determines organisational activities, structure, and stakeholder obligations. These factors, in turn, will influence how information is structured.
- Understand the context of your information, specifically what elements your users need to be grouped together because they refer to them regularly. Then identify what is referred to less frequently, which can be surfaced via search.
For example, if your organisation has a series of records that relate to a customer, which need to be considered together to offer services, then it makes sense to have “customer records” as an organising principle and group all that information together.
- Don’t sweat the small stuff. The purpose of the standardised structure is to find a core IA solution that will benefit the collective. That means it’s important to have some measures in place—such as scale of impact or risk management—to help determine what is critical to your IA and what might be an edge case.
For example, you may have one team in your organisation that has an enthusiasm for taxonomies that no one else uses or understands. Where taxonomies are isolated and have no impact on the day-to-day work of others, you are looking at something that probably needs to be locally deployed rather than included in an enterprise-wide standard.
- Be very open with colleagues about what you are trying to achieve when building the IA. When confronted with the question, “Tell me about your work and the information you use/create,” most will think you are asking what distinguishes their activities from others. So, remind people that you are looking at what connects them to the common purpose of the organisation as well as understanding their particular role. Having honest conversations with people about the possibilities and constraints of information architecture builds trust and buy-in.
The biggest factor in this conversation, as usual, is people. Essentially, developing an IA is about getting people to agree on how they see the world, which is a big conversation to have. Having this in mind, with clear parameters from the outset, will make this conversation much easier to have. In my experience, it will win you friends along the way.
