# Course: Implementing Sanity successfully https://www.sanity.io/learn/course/implementing-sanity-successfully Lay the perfect foundation for your team's first dip in the Content Lake. Assemble your team of subject matter experts and draw up plans to uncover your project's content model. --- ## Navigation ## Contents 1. [Gathering your team](https://www.sanity.io/learn/course/implementing-sanity-successfully/gathering-your-team) · [markdown](https://www.sanity.io/learn/course/implementing-sanity-successfully/gathering-your-team.md) 2. [What is involved](https://www.sanity.io/learn/course/implementing-sanity-successfully/what-is-involved) · [markdown](https://www.sanity.io/learn/course/implementing-sanity-successfully/what-is-involved.md) 3. [Project plan example](https://www.sanity.io/learn/course/implementing-sanity-successfully/project-plan-example) · [markdown](https://www.sanity.io/learn/course/implementing-sanity-successfully/project-plan-example.md) --- ## Lesson 1: Gathering your team https://www.sanity.io/learn/course/implementing-sanity-successfully/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. > [!TIP] > Watch: See how Sanity customer Tecovas [brought content and engineering teams together](https://youtu.be/1-EDCowZfqA?si=Pk2YvoB2fwnbf-z2&t=750) (start at 12:30) to create a powerful ecommerce stack built on empathy for each others jobs to be done. 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: ## Content creators 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. ## Designers 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. ## Developers 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. ## Project managers 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?* ## Data managers 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. --- ## Lesson 2: What is involved https://www.sanity.io/learn/course/implementing-sanity-successfully/what-is-involved ## Defining a content model Once assembled, your team should work through the “[Hello, Structured Content](https://www.sanity.io/learn/course/hello-structured-content)” module, which includes identifying the content needs of an imagined event venue business. This exercise should prepare you for what it takes to create an initial content model for your project. > [!TIP] > See “[Hello, Structured Content](https://www.sanity.io/learn/course/hello-structured-content)” There’s also an example spreadsheet to draft your early content model. Tempting as it is to start a new project by picking colors and fonts and writing code, nothing beats collaborative planning with simple tools that everyone can relate to. ## Choosing architecture components Composable architecture involves orchestrating individual best-of-breed providers into a cohesive workflow – connected by APIs. This can be dizzying to understand without proper planning and may benefit from drawing a basic technical diagram. Similar to mapping out schema types and their connected relationships in the content model exercise. ### Content Management System Congratulations! You made the right choice. Once complete, your Sanity Studio will be the central location for content creation, as well as the previewing of how that content is rendered in potentially multiple outlets. It can also be uniquely configured depending on a content creator’s responsibilities in their role, team, or market. ### Hosting Sanity Studio can be hosted anywhere any React application can be hosted. So your Studio may live inside your Remix or Next.js application. Or be deployed to the hosting that Sanity provides. Either way, your Studio will behave the same as it relies on publicly available APIs. It’s also inconsequential where the applications you’re developing consume or update content from Sanity. The JavaScript Sanity Client package is designed to run in all modern hosting environments. Sanity also provides [clients for other languages](https://www.sanity.io/docs/client-libraries), such as .NET or PHP. Like the Studio, all these clients are built upon the same [HTTP API](https://www.sanity.io/docs/http-api), which can also be used directly. ### Front end Your primary front end is likely a website or mobile application. However, your content may be rendered into multiple other outlets like emails, open graph images, or more. While the Sanity Studio is built with React, your front end does not need to be. Starter templates are available for various frameworks if your team wants to experiment first. However, it’s likely your development team already has a preference. > [!TIP] > [See all our starter templates](https://www.sanity.io/templates) The most popular framework for building websites with Sanity is currently Next.js, for which the [next-sanity package](https://github.com/sanity-io/next-sanity) offers a library of functions to make this integration simpler. As mentioned above, with Sanity client libraries, no one framework gets a privileged experience accessing Sanity content as they all rely upon the same HTTP API. ### Analytics Your Sanity project’s vision should extend beyond your website, but as your website is likely the primary outlet for it, it’s important to consider how you analyze the success of that content. Creating a relationship between your website’s analytics and your content is commonly done by matching a document’s `slug` field value. You may choose to build an integration that shows analytics reports in a [view pane](https://www.sanity.io/docs/create-custom-document-views-with-structure-builder) so that your content creators can take actions based on the performance of that content. ### Personalization It is possible to create basic personalized experiences with structured content and Sanity. Making audience profiles part of your content model allows you to take user information and have it influence queries for Sanity content. In a large-scale, production-grade project, you’re likely to integrate a specialized service to gather and report user data, so you may wish to integrate a third party into this part of the project as part of your composable stack. ## Integrations While Sanity plays a central role in storing your content, that content is likely influenced by more than one external service. Your e-commerce provider should be able to keep product data in sync with your Content Lake. Sanity offers an integration for Shopify. Other providers may also offer integrations. > [!TIP] > [Sanity Connect for Shopify](https://www.sanity.io/learn/apis-and-sdks/sanity-connect-for-shopify) Translation services may be required to scale content for multiple locales rapidly. AI services can help create or augment the content creation experience. Sanity offers AI Assist to get started quickly and natively in the Studio. > [!TIP] > [Install and configure Sanity AI Assist](https://www.sanity.io/learn/studio/install-and-configure-sanity-ai-assist) Some assets are better stored in dedicated services as their size or usefulness may be larger than reasonably expected for a Sanity project. For this, you may integrate your PIM or DAM. > [!TIP] > [Example asset source plugin for Bynder](https://www.sanity.io/plugins/bynder) Other assets – such as video – are better delivered from sources other than the Sanity CDN and would be better from a dedicated external provider such as Mux > [!TIP] > [Example asset source plugin for Mux](https://www.sanity.io/plugins/sanity-plugin-mux-input) If an integration for a service you already use does not yet exist, you may find inspiration from existing integrations to quickly build your own. --- ## Lesson 3: Project plan example https://www.sanity.io/learn/course/implementing-sanity-successfully/project-plan-example The diagram below shows what a Sanity project might look like when created by four distinct teams. Adapt as is more useful to your organization. ![Diagram of how a team might run a Sanity project](https://cdn.sanity.io/images/3do82whm/next/df2f1e72d5faa5103132ca7ea99212237b231811-4899x2343.png) 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. ## What is required organizationally to make this happen? 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. ## How do you roll this out to your users? 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. ## What are your next steps? Assemble your team and prepare for the Hello, Structured Content workshop! > [!TIP] > See [Hello, Structured Content](https://www.sanity.io/learn/course/hello-structured-content) Your developers may also benefit from the Day One with Sanity workshop for a quick overview of the most commonly configured features of Sanity. > [!TIP] > See [Day one content operations](https://www.sanity.io/learn/course/day-one-with-sanity-studio) --- ## Related Resources - [All courses and lessons](https://www.sanity.io/learn/sitemap.md) - [Complete content for LLMs](https://www.sanity.io/learn/llms-full.txt)