It makes a difference if you do something the right way from the beginning.  Everything seems to work out so much better and takes less time over all.

Here are some basic steps that I have learned will help you do it right the first time. These steps are from my experience, mostly because I did it wrong the first few times.  These are not exact steps. They are subject to change and improve.  In fact, you might have improvements to suggest immediately when you read this. But if you are new to WPF, then reading these steps before you start and following them, will have you closer it doing it the right way the first time.  It is much more pleasant to tweak a pretty good process than it is to go in with no idea for a process and do it wrong.

Step 1 – Prepare the idea

1. Some one has an idea
2. Determine the minimal features for release 1.
3. Determine the minimal features for release 2.
   1. Alter minimal features for release 1 if it makes sense to do so.
4. Determine the minimal features for release 3.
   1. Alter minimal features for release 1 and 2 if it makes sense to do so.

Step 2 – Design the Application’s back end business logic (simultaneous to Step 3)

1. Design the backend
2. Apply the “Keep it simple” idea to the business logic and makes changes as necessary.
3. Apply the “Keep it secure” idea to the business logic and makes changes as necessary.
4. Repeats steps 2 and 3 if necessary.
5. Backend development can start now as the UI and the back end should not need to know about each other, though this coding is listed as the Step 5 item.

Step 3 – Design the UI using WPF (simultaneous to Step 2)

1. Determine what development model should be used to separate the UI from the business logic.
   1. Model-View-ViewModel (MVVM) is the model I recommend for WPF.
   2. Gather libraries used for the model (such as common MVVM libraries that include the common ViewModelBase and RelayCommand objects)
2. Consider using a 3rd party WPF control set will be used.  Many 3rd party companies provide WPF controls that are better and easier to use than those included by default.
   1. If you decided to use 3rd party controls, purchase or otherwise obtain the libraries for these 3rd party controls.
3. Consider designing two WPF interfaces or skins (I will call these Views from here on out) for each screen. This will help drive the separation of the back end code from the WPF code. Also if developing two Views is not simple, it indicates a poor design.
4. Design the interface(s) (you may be doing two Views) using SketchFlow (take time to include the libraries for the 3rd party WPF Controls in your SketchFlow project and design with them)
   1. SketchFlow allows you to design the UI, which is commonly done in paint, but instead does this in XAML, and is actually the WPF code your application will use.
5. SketchFlow allows you to deliver the design (or both Views if you did two) as a package to the customer.
   1. Deliver it immediately and get feedback.
   2. Make changes suggested by the customer if in scope.
6. Take time to make the XAML in SketchFlow production ready.
7. Deliver the XAML to the customer again, to buy of that the design changes are proper.
   1. Make changes suggested by the customer if in scope.

Step 4 – Determine the delivery or install method

1. Determine the delivery method.
2. Determine when to develop the delivery method.
   1. The easier the application is, the longer you can wait to determine the installer or delivery method.
   2. The more complex the install or delivery method, the sooner this should be started.

Step 5 – Develop the business logic

1. Develop the application designed in step 2.
2. Get the application working without UI or silently. Note: Start the next step, Develop the UI, as soon as enough code is available here.

Step 6 – Add Bindings to the UI

1. Start the UI project by copying the XAML from the SketchFlow document to your Visual Studio or Expression Blend project.
2. Determine a method for setting the DataContext without linking the View to any ViewModel or Model dlls.
3. Create a project for the ViewModel code and develop it to interact with the business logic using Binding.
4. Remember to develop two Views for every UI screen as this will help, though not guarantee, that the the MVVM model was correctly used.

Step 7 – Develop the View Model

1. You should now have a backend code and a View, and now you start creating the View Model.
2. This should be in a separate dll than the View or ViewModel.
3. The ViewModel should never link to the View but can link to Model and Business libraries, though you may consider interface-based design and only link to an interface library.
4. Make sure to use the properties that the View is binding to.

Step 8 – Consider a other platforms

Macintosh

Macintosh owns a significant market share.  Determine if this application needs to run on Macintosh as well. Sure, since we are running C# your options are limited to either rewriting in objective C and Coca, or using Mono with a MonoMac UI.  I recommend the latter.

Note: It is critical that the UI and business logic are separated to really make this successful.

1. Completely ignore the WPF design and have Macintosh users users assist the design team in designing the new UI.  Macintosh’s have a different feel, and trying to convert the same UI is a mistake.
2. Create the MonoMac UI project.
3. Create a project similar to the ViewModel project in Windows, to link the UI to the business logic.

BSD/Linux/Unix

BLU (BSD/Linux/Unix) doesn’t exactly own a significant market share. However, it is still important to determine if this application needs to run on on BLU as well. Sure, since we are running C# your options are limited to either rewriting in C++, or using Mono with a GTK# or Forms UI.

1. Completely ignore the WPF and Macintosh designs and have Linux users assist the design team in designing the new UI. Linux have a different feel, and trying to convert the same UI is a mistake.
2. Create the GTK# project.
3. Create a project similar to the ViewModel project in Windows, to link the UI to the business logic.
4. GTK# doesn’t support binding, but still keep the UI separate from the business logic as much as possible.
5. Also, don’t develop for a single open source flavor, but use standard code that compiles and any BSD/Linux/Unix platform.

Mobile Platforms

1. Do you need to have this app on IOS or Android or Windows Phone?
2. Completely ignore the WPF and Macintosh and Linux designs and have Android or IOS users assist the design team in designing the new UI. Mobile platforms have a different feel, and trying to convert the same UI is impossible as the screens are much smaller.

Step 9 – Develop the delivery method

Again, you may need to do this way sooner if the application is complex.

1. Develop the install or delivery method.
2. If you decided to deploy to Macintosh or BLU you may have to develop separate install or delivery methods for those platforms as well.
3. Remember to have a plan and a test for your first patch even if you have to mock a sample patch before you release.
4. Remember to have a plan and a test for upgrading your application even if you have to mock a sample upgrade version before you release.

Step 10 – Deliver the finished Products

1. Once finished, deliver this product.
2. If you decided to create a Macintosh or BLU version, deliver them when ready as well.  It is OK and maybe preferred to deliver these at different times.