I recently suggested to someone that separating one's data from the GUI that displays it is an important technique. They responded with... "Well how do I do that?" Which made me realize it was a good topic for a tutorial.

Why do we want to separate the data from the GUI?
One reason would be so we can keep a LOT of information, but only display a subset of it. For example we might have a lot of personal information about an employee like their pay rate and social security number. But we don't want to display that to everyone on the network. We only show that to people with Human Resources management level access.
Another reason might be so we can use one form for gathering data, and other for displaying it.
But my personal favorite need is so I can serialize/deserialize the information. Remember that GUI controls can't be serialized. So if you have a contact form like this one

how do you plan to save the data?

Of course you know you should NOT just directly access the GUI controls in every line of your code. GUI controls should always be kept private. Other classes should only change public properties. This way you can rearrange the form, change names, do whatever you need to do under-the-hood and not break all of your references to the properties.

Now it is just a matter of adding a couple methods to update the gui and update the object

Spoiler

/// <summary>
/// Send the information from the object to the form
/// </summary>
[Description("Send the information from the object to the form")]
private void UpdateGUI()
{
// There are more eligant ways of updating the GUI to match the data
// including iNotifyPropertyChange and DataBinding.
// But for the purpose of this simple tutorial this is the easiest to
// read and follow what it is doing.
tbFirst.Text = First;
tbLast.Text = Last;
tbMobile.Text = Mobile;
tbDicHandle.Text = DicHandle;
tbEmail.Text = Email;
}
/// <summary>
/// Get the information from the from and update the object with it.
/// </summary>
[Description("Get the information from the from and update the object with it.")]
void UpdateContactObj()
{
// There are more eligant ways of updating the GUI to match the data
// including iNotifyPropertyChange and DataBinding.
// But for the purpose of this simple tutorial this is the easiest to
// read and follow what it is doing.
First = tbFirst.Text;
Last = tbLast.Text;
Mobile = tbMobile.Text;
DicHandle = tbDicHandle.Text;
Email = tbEmail.Text;
}

We create a little Tester form to call our Contact form, then save the new data as an XML file after the Contact form closes.

And voila, we have a contact form with the data separated from the GUI. Our main form (tester in this case) can give the user a new contact form to obtain new data, and then save it.

But remember it could just as easily get a List<ContactObj> from a database. This would allow you to get a lot of contacts without creating a lot of forms for no reason. You could get a ContactObj and feed it into a different form that shows all the hidden properties and so on.

If you're running VS10 I've attached the finished solution.
If not, here's the final code after all the edits.

Prism provides guidance designed to help you more easily design and build rich, flexible, and easy to maintain Windows Presentation Foundation (WPF) desktop applications and Silverlight Rich Internet Applications (RIAs) and Windows Phone 7 applications. Using design patterns that embody important architectural design principles, such as separation of concerns and loose coupling, Prism helps you to design and build applications using loosely coupled components that can evolve independently but which can be easily and seamlessly integrated into the overall application. Such applications are known as often referred to as composite applications

By a "strings" file, do you mean a file with all the strings used in your application?

I usually do this with the resources of the component. That makes it easy to globalize/localize an application. You just open the form/file, change the Language property and replace all the text.

Now the correct 'version' gets installed when the user installs the "english" or "Russian" or "Polish" version from the installer. This way InstallShield & Visual Studio do all the work and I don't have to do anything in code for the change, except to be sure to add all my strings to the correct resource file and use them instead of hard coding the strings.

By a "strings" file, do you mean a file with all the strings used in your application?

Yes, sometimes I use the resources but I have found it is easier and more convenient to create an "en.lang" file with all strings so I can localize it and others can change the strings if they want to. Especially for other languages since I just use Google translate to translate the "en.lang" file to other languages. Other people have emailed me better translated language files that they have updated to include in updates.(After checking Google translate to make sure they didn't write something bad of course)

You know, I forgot all about that. WPF databinding is surprisingly complex, and I'm still learning a lot about it as I use it. I can probably put together a simple binding guide pretty soon, it just won't be comprehensive (because to be comprehensive, it'd have to be a small book).