An interface is not required to provide any sort of online designing tools, or even to provide a way to enable the special design privileges. Nevertheless, minimal tools can be very helpful, and you will often find that they are helpful in debugging the rest of the interface, since you can use them to construct test cases at any time.
A basic set of design tools should include a way to enable and disable designing for at least one side, a command to create units of a given type, and some sort of tool to set the terrain type at a given location. A full set would include "painting" tools for all area layers, including geographical features, materials, weather, side views, and so forth - about a dozen in all.
A least one level of undo for designer actions is very desirable, although it may be hard to implement. A useful rule for layers is to save a layer's previous state at the beginning of each painting or other modification action, when the mouse button first goes down.
The designer will often want to save only the part of the game being worked on, for instance only the units or only the terrain. The "save game" action should give designers a choice about what to save. For units particularly, the designer should be able to save only some properties of units. The most basic properties are type, location, side, and name/number. The unit id should not be saved by default, but should have its own option (not clear why).
Note that because game modules are textual and can be moved easily from one system to another, it is entirely possible to use one Xconq (perhaps on a Mac) to design games to be played on a Unix box under X11, or vice versa. This means that the interface should always save the designer's work as an ordinary text file if possible, so as not to require any further manipulation.
Likewise, any image design tools should have some sort of option to save as text, so that the imagery for a game design can be used on every platform that the design can.