Project plan example

Open to enlarge image

1. Your Solution Engineer will arrange an Onboarding Kickoff to align your entire project team with the goals, scope, and context of the project.
2. They may then follow up with the Hello Structured Content Workshop to introduce the team to the principles and practices of structured content.
3. Internally you next would facilitate a Content Model Brainstorming session to generate and discuss potential content models and decide on the most suitable one for the project.
4. Developers then implement the Studio schema based on the selected content model, ensuring it aligns with the project's design requirements.
5. Your Designers can skip the queue here and begin creating preliminary designs based on this content model so long as they stay in touch with revisions to that model.
6. The entire team should perform a Studio Review Session to assess the schema's implementation, ensuring it meets the necessary standards and project specifications. Any feedback gathered from designers and content creators can then reshape the model. With a smooth deployment pipeline for your Studio these iterations should take no more than a week – depending on the size and complexity of these alterations.
7. The Experience Designs – for example a website front end – should be reviewed to critique the designs, gather feedback, and identify areas for improvement.
8. Content creators can begin entering content into the finalized Studio, populating the designs with the actual content used in the final product.
9. Developers can then proceed with experience implementation, integrating the content and designs into the final product's environment.
10. Before launch, conduct a comprehensive Experience Review to ensure the implementation matches the project's goals and the end-user's needs.
11. Finally, prepare and execute the launch of the completed product, making it available to the target audience.

Each loop of this process should take approximately one week, with schema changes being informed by design. Early designs can be created based on early content models to facilitate rapid and iterative development.

Clear lines of responsibility should now be established so that stakeholders understand their role in the launch and continued success of your project.

Ensure that lines of communication remain open as some work can overlap – such as designers working from an incomplete content model or content creators authoring in an incomplete Sanity Studio.

Deployment pipelines are crucially important during the beginning – and ongoing success post-launch – of your project. Maintaining content velocity requires developers to be able to rapidly iterate a content model based on feedback from designers, content creators or application users.

Having multiple “environments” or datasets is useful as well. A space where content creators can preview Studio builds before they are published to production, as well as the ability to author and preview draft content without accidentally overwriting production data.

As your project endures, new designers, developers, and content creators will inevitably join it mid-stream. The Sanity documentation and training resources such as these can give a good grounding in all things Sanity. Your Studio should also be as self-documenting as possible. Field names, descriptions, validation messages, and live previews play a crucial role in helping any new users understand the impact of making content changes.

Once your project is more established, you may look to create onboarding materials of your own to document the process of how your unique Studio is best used.

Assemble your team and prepare for the Hello, Structured Content workshop!

Your developers may also benefit from the Day One with Sanity workshop for a quick overview of the most commonly configured features of Sanity.