# Project planning _AKA the service blueprint_  --- ## Why plan?  ---- ### Centering the user By being clear from the start about what we are building and how we are building it _for our user_, we ensure that their needs are being met. ---- ### Starting on the same page Planning makes sure everyone agrees on lots of different decisions about system design from the beginning. You can always point at the project plan later, to say "here is what we agreed to do". ---- ### Scope It helps to give everyone a sense of how much there is to do. ---- ### Continuity We should aim for someone else to able to pick up our plans and build what we had in mind without us. --- ## Start big, drill down - What tasks should your frontend and backend be able to perform? - What components do you need to build to acheive each task? - How does a given task depend on other parts of the project? --- ## How the project fits together - It can help to visualise tasks and components - A 'service blueprint' - an interconnected block diagram of the system as a whole - How does the someone use the frontend? How does the frontend work with the back end? How are you making everything resilient to errors? --- ## Use available tools - Use colour, space, arrows / lines and shapes to add clarity to your plan. - Post it notes for ideas, flow charts for user / information flow - Miro has helpful templates and iconsets --- ## Sense when enough is enough - It's a judgment call when your plan is detailed enough to start building. - This is the project equivalent to writing pseudo-code. You do not need to build anything during the planning phase. --- ## That's all  --- ## Resources - [User journey to service blueprint](https://blog.practicalservicedesign.com/the-difference-between-a-journey-map-and-a-service-blueprint-31a6e24c4a6c) - [Miro](https://miro.com/)