This is perhaps very simple; we have a process which allows people to both import data into and export data from an application. Previously we were going to have two separate links for importing and exporting but that is cluttering up the top level menu as we have many links up there already.

Therefore, we want to combine the import and export processes into one page and then, when the user clicks on the link to take them into this page we would ask the user whether they would like to import data or export data.

Question is if there is a better way to say "Importing and Exporting" in one word. "Transfer" seems a little out of tough and ambiguous.

Is there something better?

Thank you.

  • 1
    "Vandelay Industries" Commented Jun 2, 2017 at 17:42

5 Answers 5


I think Port or Portation could be better alternatives. Later you can be a little creative while displaying the import & export options:


enter image description here

enter image description here

  • But are users really going to associate the word "port" with importing and exporting? Although by definition it works, I've certainly never seen it used in that context. If users are expecting Import/Export, calling it exactly that is the best option from a UX perspective.
    – user101673
    Commented Jun 2, 2017 at 12:05

Though knowing more about the user base and the application's nature/purpose would be helpful - here are some thoughts that you might consider -

1) Are these Export and Import functionalities equally important? Is there one of them which would perhaps be used more often? If so, give that a priority treatment.

2) Think in terms of - when in the app flow would the user do the export, and when would he/she import? Instead of putting it in a global manner, see if you localize these actions at the point when they are most likely to happen. That may help the users and at the same time, add more meaning to these functions. For example, if its about, health tracking, users might export the health data, from the page where they are viewing their health stats (Export health data).

3) Depending upon your application and the nature of the process, see if Import/Export could be called something more specific. Say, Import Contacts, Import CSV etc. Upload is also another term that can be used. Idea is to make the call to action more specific and explanatory. As in, Export what? Import what?

4) If you it comes down to putting them together, think of using Export/Import Icons as options to signify the same. Alternatively, have an icon for Transfer Data/Transfer Contacts etc - to take the users to a dedicated page.


Drop the "ing" and use both verb forms with a slash.


This uses 13 characters, which is not excessive. It's easy to recognize and understand, and it saves you the headache of finding the unicorn word you're looking for ; )


Another option is to conceptually go up a level and use terminology centred around what the user will ultimately achieve from this functionality. Data changes, batch changes, etc.

Since you're in a navigation scenario, it's not as tough as a button on the page of form label in terms of word length, so I'd ere on the side of clarity over brevity.


Maybe a bit late to the party, but instead of focusing on the functions of the page (Import/Export) you should define it by what it is not what it can do.

Essentially you are importing or exporting data to a database. So, why not call the page Database or Datahub or Data transfer?

This can help reduce the screen space of long labels whilst not being totally ambiguous.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.