Those who have worked with Sitecore Experience Accelerator (SXA) are aware that the way of working with Sitecore has changed. Different development teams that previously worked in isolation must now work in parallel and coordinate more closely.
SXA gives users the ability to drag and drop blocks, items, and structure (such as rows, columns, containers), but if the person behind it is not aware of how the Grid system works and how the front-end developers think, what may look good on a back-end developer or content editor’s screen could be very challenging for front-end programmers to work with. SXA won’t stop anyone from creating unrealistic structure because it relies on the joint effort of all the teams. After all, we are all in this together.
The ideal scenario would be a meeting (or a series of meetings) with front-end, Sitecore back-end, UX and the design team sitting together to build a strategy. Often, this is not the case. The team could be made up of members from another agency, existing resources can be allocated or busy on some other project, etc.
Based on our experience there are several things you can do.
Take a mobile first approach
When designing and building a site, it is important to have in mind which devices will be served. Nowadays, mobile layout is a must. Out of the box, SXA will offer you options to design your Grid per device. You can even choose what you want to show or hide per column.
Do not overnest
It is very easy to create a complex structure with deeply nested rows and column splitters. Try to avoid row nesting as much as possible and focus on using Containers and simple page structures instead.
Style for re-usability
Consider how, with a CSS class, you can accomplish a desired change. Try to treat the functionality of CSS classes as simply as possible; this makes them reusable later on.
Focus on HTML structure and grouping of the elements to minimize changes. Although nice, a flat structure would most likely cause rework in the future from the Sitecore developer’s side, or more work for the front-end developer.
We use variants to change the presentation of the data while keeping the same underlying data structure. This gives the content editor lots of flexibility when building a site. Be careful not to use data structures that are too generic. The rendering and data should be built around a single purpose, making it easy for the content editor to understand where and how to use the component.
Think of simple, describable names that you want to give to your blocks, renderings and styles. When the end user gets the solution, your implementation should be as self-explanatory as possible. If you need a document (mapping or a dictionary) to understand how to use the solution, then rework is required.