We are building a web interface to a tiered membership system, which will interface with a third-party CRM web service for the creation and management of accounts. The web service, unfortunately, is not yet built; however, we need to begin work.

I have created an interface, `IMembershipService`, in which I am beginning to define "best-guess" prototypes, so we can begin building our User Controls. Most of these methods will return some data bundled in a Model object, e.g.:

    ContactModel GetContact (string userId);

When the web service methods become available, I will create a concrete implementation of `IMembershipService` that will wire up the controls to the web service.

The problem I have is that I don't yet know whether the web service will consist of:

- calls returning complex objects; e.g. a `User` object with a nested `Membership` object, which, in turn, has a nested `PaymentMethod` object
- simple calls for specific pieces of information; e.g. `String GetUserMembershipType (string userId);`

This is causing me to have trouble specifying the structure of the models and interface, which is causing problems for the developers beginning work on the User Controls:

- If the service returns complex objects, I don't want my `IMembershipService` methods to be too simple, forcing me to use multiple web service calls where it is not necessary.
- If the service consists of simple calls, I don't want to have a load of complex models defined that I then can't implement, thereby having to do a load of refactoring.

In theory, creating `IMembershipService` should allow me to abstract away from the actual nature of the web service, but the fact that each call to a method in `IMembershipService` will, ultimately, result in a web service call, thereby adding overhead, is making this difficult to spec.

How can I design my models and `IMembershipService` in order to minimize the amount of refactoring I have to do when the nature of the web service becomes less elusive?