Gathering your team
The most successful implementations of Sanity projects share this in common – assembling all stakeholders as early as possible in the project.
Perhaps your new Sanity project could be summarised as a “new website,” but when used correctly, Sanity becomes a single source of truth for all the content your business needs to author, store, and query. Your Content Lake should be able to scale as your needs and business do without expensive and time-consuming rewrites. This is possible when every member of your team who interacts with your content in any way can share their domain expertise and contribute to the content model.
This might sound like a bump in the road right at the beginning of your journey, but it is less painful than performing content migrations mid-project after key stakeholders are introduced to the project after it has already commenced.
It will also help unite your team around content – and not technology choices – with every member feeling more involved by being able to contribute to the model. The opposite scenario – where designers and developers make uninformed content modeling decisions on behalf of creators – is unfortunately common and rarely leads to excellent results.
The aim at this early stage is not to get your content model 100% perfect, set it in stone, and start building. Just to uncover as much knowledge as possible from informed individuals so that your starting point is as well-defined as possible.
Consider the following roles and what they can contribute to creating the initial content model for your Sanity project:
Likely, the team members who will spend most of the time with your Sanity Studio long after the majority of development effort reduces after launch. They’re already using whatever content management system(s) you have implemented and can share insights into what they like and dislike about them.
The aim of a new project should never be to recreate exactly the same editing experience they’ve had before. This is your opportunity to break away from limited systems to reexamine those established habits.
Content creators will also know their ideal workflow of what it takes to author a new piece of content, put it through workflow processes, and publish it into production. This is a series of logical steps that will need to be implemented by your development team.
Among the content creation team, there may be different lines of responsibility, so documents might need to be off-limits from some creators under certain conditions. Or require specific validation rules to be met before publishing. These rules can be added to your early schema model work and coded into the project by your developer team.
Your designers will be familiar with the many surfaces on which your content will be rendered. At present, you may be copying and pasting content from one design to another, from one service to another. Your Sanity project can employ a Create Once Publish Everywhere (COPE) methodology so that designs are driven by content instead of individually bespoke.
They’ll also have domain knowledge of your design system. The intersection of this and your content is critically important to get right – and a great conversation point to have with content creators – so that your Sanity project does not become a do-it-all “design configurator” but instead a way to feed any content into a front end that has been coded with the rules of your design system only ever to create brand-consistent outputs.
Your developer team likely played a strong role in helping you select Sanity, and it’s an excellent choice for developers! It should be crystal clear, however, that Sanity’s developer-friendly nature is designed to empower developers to create creator-friendly editing experiences.
Sanity Studio has an exhaustive list of configuration APIs to build complete content schema types and, near-infinitely, customize the editing experience.
It can also power many different kinds of workflows. Think of Sanity Studio as a “no code experience builder,” which might be used for scheduling automation or product configuration settings.
Your developers should consider an automated deployment strategy early in a project. This way, any small changes to the content model can be rapidly deployed. This is especially useful in the early stages of iterating on your project and user-testing with content creators.
To avoid your Sanity project being steered overly in one direction, a project manager can play the role of referee for tiebreaker decisions.
Your Sanity project is not just a “set and forget” scenario. It’s a web application that will perform best when maintained.
They’ll also be able to estimate resources in the lead-up to launch, which will require more developer time, and what post-launch looks like when content creators are more hands-on. It will also be their responsibility to consider a maintenance and upgrade schedule for the Sanity Studio application.
Your team can go a long way with the wide variety of options Sanity provides. However, if something’s not quite exactly to your liking, almost anything is possible! But every bit of configuration or customization comes down to a question of your teams’ resources and appetite.
Do you have the resources to undertake a complex piece of customization and the appetite to maintain it long-term?
Fortunately, Sanity has abstracted away the “hard part” of data management in that it can host all the content and assets your project relies upon.
The security policies around what data goes into your Content Lake, who has access to it, and where that content is deployed are all questions your data managers should be able to answer.