ネイティブとWebの両方のアプリケーションは、一般的に2つのカテゴリに分類される。ほとんどが利巧主義的で、大部分の投資が機能性に対して行われており、グラフィックアーティストには、初期のモックアップ以上には積極的な投資がされていない。そしてそれらは、すべての過程で、成熟したユーザインターフェイスデザイナと平行してプログラマが作業しており、見た目にフォーカスされている。それらの人々は時々、直接HTML、MXML、XAMLを編集することが期待されている。
XAMLの話は複雑である。プログラマによるコードの変更は、Blendのデザイン環境できちんと動作する。彼らがそれをしたら、ユーザーインターフェイスデザイナは、まるで彼らがHTML/CSSツールを使っているかのように、完全に動作を確認することができる。
ASP.NET MVCの状況は、想定よりもよくない。それは、開発を容易にしたが、Michael Taylor氏は、他の方法からの後退であると主張する。
MVCにおける問題があります。UIを構築する際、なぜデザイナでどのように見えるかを確認することができないのでしょうか？これでは、UIを書いてはIEを実行してどう見えるかを確認していたASP/HTMLの時代に戻されてしまったようです。UIデザイナの視点から見ると、これは正常な状態ではありません。ASP.NET（と、おそらくVisual Interdev）の本当に大きな特徴の一つは、UIを書いたら、VSから離れることなく、すぐにそれを確認出来ることです。フォーム上にコントロールをドラッグ＆ドロップすると、それが正しくなるまで変更することができます。MVCでは、それができません。
Michael氏の主張は容易に理解できる。デザイン時にMVCブロックのレンダリング機能がないということは、CSSをどのように変更したら、ビューがどのように変わるのかをデザイナで確認する方法がないということである。これには回避方法がある。ひとつのオプションとして、サイトと生成されたHTMLを静的なファイルとしてコピーする方法がある。それを、デザイナは彼らの好きなツールでスタイリングすることができる。
他の悩ましい問題として、業界がブラウザ特有のレンダリング問題に対応することができないということがある。多くのツールと同様にVisual Studioは、ブラウザ間で互換性がないであろうテクニックを使った時に開発者に対して警告してくれない。そのためデザイナは、CSSを変更したときにそれが正しく動作するかをそれぞれのブラウザで評価するという面倒な作業を避ける。