Q:

How to bring others to understand your interface

I'm working in a corporation that has two products.  One is a desktop application the other is a web-application.  I'm in on the part as backend-engineer on the web-application.  I design the web-interfaces.  We use SOAP as the interface technology. 
Now as the product develops there are lots of changes in the current not released version of the interface.  
The web-application develops way faster than the desktop-app and we make a new interface-version only if we get live with it (means there is a customer-desktop-app that uses this interface-version).  But now and then there are new use-cases that the desktop app should be able to handle.  And we have to exchange new data so we extend the current version. 
When we present the new interface to the desktop-developers (after lots of business-reviews) they always complain about the structure, naming and content of the scheme.  They kind of refuse to work with it and there are a lot of meetings and unnecessary talk.  Technologically its all fine, but it's like they are not on the same boat. 
What would a best-case look like when I want a to define a soap interface that is accepted from developers and businessman alike? 
I'm looking for a best-case-scenario how to handle this.  I hope that when the idea of a working workflow does not come from me (the developer) it is easier for the businessman to accept it. 
EDIT(@k3b follow up question):
they always complain about the structure, naming and content of the scheme
As the interface provider we define the structure.  The desktop-developers complain about how we did structure the content.  There are several ways it is possible and we choose the structure that is closest to the real-world.  This does please the business mostly but 'offends' the developers.  One of the most used arguments are that we "generate unnecessary work for them when there would be an easier way (from a developers view)".  
In the technical-view I agree.  We could make it easier.  But due to the fact that the business can't read the XSDs and the provided api well enough we have to simplify it for them.  So they can go an sell the data-interfaces to other business people. 
When we make an interface that favors the dev's - the business won't be able to read it (I tried). 

A:

A recognizable scenario. 
As you already have client side prototypes (at the minimum), make a (nice) client side API, and test code on a test database.  That should remove the distraction created by the SOAP plumbing.  Have a defined glossary of bussiness entities.  Document business rules. 
An interface change should be backwards compatible - is it not?  A client side API may hide attributes, collect in one single parameter class several attributes, so the API remains solid. 
Extensions for specific functionality could use the adapter / decorator pattern. 
The problem is that they probably are nearer to the real-world business concepts than the IT.  They might want new features, but certainly not the effort to upgrade on their own.  And certainly not errors.  So unit tests, documented test data and such are important. 
However much will not be new. 

A client API with test tools and the rest will give extra quality, help the
client and cost you nothing if you are already into unit and integration testing.  It will save you, when established.