We’re very plan driven at Brainjocks. We like to create them, execute them, measure them, adjust them…and we employ a number of governance plans when executing a new Sitecore project.
Very often, large site development projects will include a number of people from various organizations all working together for a common goal – but those teams typically have very different success metrics and objectives. Let’s take a simple web project and look at some of the teams that will be involved, and what matters to them most.
Designers – you know I love ’em. In all seriousness, they have a tough job – creating a design that is aesthetically pleasing, aligned to a brand, which provides a user experience that will engage a visitor. Ultimately they are responsible to drive visitors into areas of interest that will create a meaningful connection between the visitor and the organization.
Content Management Team
The content management team has a significant operational role in management and delivery of content. Their job is to take content in its raw form, and apply to it the design and user experience of the website – and in doing so, satisfy and enforce all of the performance and quality measures such as speed and accessibility.
Important to note – design and content don’t always get along, so in content management we have to factor in variants of design. An example of a variant might be slight alterations of the header to accommodate a longer title, or a different layout of a hero to include a featured image to the left or right of the content – but understanding these types of “flex” in the design will ultimately be needed to make the content team more successful.
Optimization teams can be divided into 3 functions – data collection, analysis and strategy. In general, this team (or teams) will be responsible for the collection of analytics and data from visitor activity on the site, understanding it and determining a strategy to increase conversions.
This team will typically employ the use of AB or multivariate tests that will be used to prove or disprove a hypothesis and personalization in order to segment the audience and engage them on a more meaningful level. An important note here is that Sitecore and most other CMS products with personalization built-in allow the personalization and MV testing to be conducted on a component level – so what is a component will impact what is testable or personalize-able.
Another team to note is the SEO team. Again, this team might be part of the larger optimization group, or separate from them – but the requirements for a component to deliver viable content for search indexing is a real need.
The engineering team is responsible for fulfilling the design and user experience crafted by the designers, providing an authoring experience that can be managed by the content team, properly implementing the system so that data collection can be done, and satisfying both functional (does it work) and non-functional (is it fast, it is compliant, is it accessible, is it secure, is it seo capable) performance criteria of the project.
So, there’s a lot going on
Yes, it’s a lot to take in … and when the site is being constructed, each of these functions have to be taken into account for the system to be operationally sound and performant.
You might think that developers just take a design and make a template out of it, but that’s far from the truth. Design is remarkable more complex in the modern era than that, and so is the collection of user interaction data. Typically design these days is componentized – or decomposed into a series of interconnected connected components that can be assembled into pages. If you are familiar with SXA and other Sitecore frameworks like Brainjocks SCORE, you already understand this.
What is component governance?
Component governance is the plan and processes by which we decompose design into components. With all of these groups as interested parties, we need to ensure the proper information is collected to rationalize the design and satisfy the needs of these teams.
A sample component governance plan
No single governance plan will work for every project, mainly because each organization is different, and in the construction of the site, what teams are built as a combination of vendors and internal personnel and will reflect the organization’s maturity in its digital practices.
Thing the governance plan must determine and enforce include
- Asset specifications
- Analytics / tracking requirements
- Variance of design
- Rationalization of the component library
- Data validation
- Functional and non-functional quality metrics and impacts
- Design and user experience consistency
So there you can see what we’re trying to accomplish – mainly, we are making sure that the teams have a common definition of ready to deliver your design – and to ensure that the outcome of the development meets or exceeds the expectations of these various teams.