This is a very pertinent question as while pre-processing steps are widely considered to be part of the overall model and should be included in its validation procedure, explainability tasks (through LIME, SHAP, PDPs, etc.) rely on the pre-processed model inputs and are thus unable to account for changes done during pre-processing.
Some further discussion: we know we should zero-centre our data using only the training set derived means - e.g. see Question about subtracting mean on train/valid/test set for a further discussion). When the learning algorithm is then fitted on the pre-processed training set, that learner's "world" is already preprocessed without the learner knowing that. When we use some post-hoc explainability routine, the routine can only account for the behaviour of the learner, a behaviour that it is fixed on the preprocessed training set.
As such, we need to make a clear and accurate description of the preprocessing steps done. Some steps might be very straight-forward (e.g. zero-centring) some steps might be more complicated (e.g. imputation of missing values). In all cases, the impact of the preprocessing will/should be captured by the model validation but when explaining the learner's output we focus on the final learner. I have personally tried to created PDPs across each of the folds done by a resampling procedure, as a way to visualise the variability of the PDP and thus of the underlying model, but that was really model specific and definitely ad-hoc. I am sure this can be done with other explainability routines too (e.g. SHAP).
Having said the above, unfortunately there is no formal way of presenting the effect of preprocessing steps; there are some data science project methodologies you might want to consider when structuring and/or presenting a DS project (e.g. CRISP-DM, TDSP, etc. - see CRISP-DM Twenty Years Later: From Data Mining Processes to Data Science Trajectories (2019) by Martinez-Plumed et al. as a first start) but those are not exactly what you want. (I did found them helpful when structuring the project delivery though.)