How to better engineer "generic argument list"?

I find myself hesitating between multiple solution but never finding something that I’m fully satisfied with when it comes to encapsulate some functionalities.

This came especially problematic in my recent desktop GUI projet where I want to generalize a functionality that encapsulate a set of well-defined views along with some logics, but one view must be “injected” and can take multiple forms that is largely up to the user. To do that, I defined an interface for the view that can be passed through a constructor.

A process is launched by the user and the result is return to the caller by callback once finished.

the interface:

interface ICustomMecPathViewModel : IScreen, IMecPathViewModel
    {
        public Dictionary<string, object> getStepResult(); //subview must return its result 
        public void Reload(Dictionary<string, object> preset); //subview will be reloaded for each new iteration
    }

the constructor:

public PreparePathViewModel(ILogger logger, IConfiguration config, ICustomMecPathViewModel customParameterViewModel, ITool tool, Action<MecPathModel> callback)
        { ...  }

The issue here is that this process includes multiple steps and the the view implementing ICustomMecPathViewModel might need different configuration for these steps. I see here two solution and struggle to find the best answer (maybe none of those two ? )

Either I can pass something very generic such as a list of Dictionnaries (the list to allow various configurations depending on the step) with no type restriction as it is for my preset values:

List<Dictionary<string, object>> settings

Or I can pass a List of intefaces where I define exact settings, adding new elements each time I add a new configuration:

List<IStepSettings>

the First solution is not pleasing to be because of the absense of type check and the latter might become an interface with a lot of random stuff that have no coherence between them, which just feels wrong. (and it would no be as extensive as a general API)

The first solution appears better to me for this reason. And my thought are : generalizing things come with a cost and this is it.

What do you think ? Something wrong with this kind of design ? Another better solution ?