The Partials are in my opinion the most interesting part of the MPS – this are the main building blocks of a page (or another Partial). Think of Partials like groups of Blocks that can be modular (re)used in the many ways – this is off course only possible when they are created like that.
A particular Partial could be a news item (in all it’s possible ways it’s being rendered in), a product box in a web shop, or a complete block of USP’s. But a possible Partial can also be a group (or loop) of other Partials, e.g. a block with “news items”, a “featured products block” that can be used site or store-wide.
The more efficient a Partial is being developed the more time in later steps will be saved. It’s good to think of Partials as they are ‘components’ or ‘configurable includes’ – that behave differently on what parameters are being pushed to them.
In this way you only need to create calls to data once – and based on parameters, only relevant data (for a particular view mode) will be rendered to the front-end. And as it’s a Partial based on Blocks and Elements, code can be modified and optimised along the way at any given moment!
A good practice is to think what parameters are relevant e.g. how advanced do you want make the Partials (and how easy you want to able to re-use them)?
Designers have to make sure they create Pieces as much as possible with previously designed elements in the Principles phase – make use of defined fonts, buttons and colours. If possible create symbols or instances to keep the ability to update them through all the instances.
As mentioned before – for developers it’s good to think of Partials like components (and not just another piece of copy / paste code). Think of the different ‘view modes’ a Partial could have and keep them together within a single file (or maybe includes).