Windows 8 のモットーは "クロム(Chrome)よりもコンテント" だ。これによって Windows 8 は，画面全体がアプリケーションのコンテント表示に供される初の Windows バージョンになる。デフォルトではウィンドウフレームも，メニューも，ツールバーも存在しない。アプリケーション間に共通の設定機能などは "アプリケーションバー" 内に隠され，ユーザが必要とするときにビューにスライド表示される。
注目すべきなのは，画面の すべての ピクセルが実行中のアプリケーションに与えられている点だ。Metro デザインには時計も，タスクバーも，さらに通知トレイも存在しない。実行されるアプリケーションはいずれもデフォルトでスクリーン全体を占有するか，あるいはユーザが同時に２つのアプリケーションを動作させたい場合には画面の半分を獲得する。
画面枠にあった標準的な操作は，エッジでのゼスチャに置き換えられている。画面の左端はバックボタンとして，通常はひとつ前のアプリケーションに戻るために使用される。右端では検索や共有など，アプリケーションとシステムのプラグインを格納した "チャーム (charms)" メニューがオープンする。そして上端と下端には，前述したアプリケーションバーが格納されている，といった具合だ。
Metro スタイルのアプリケーションの大部分は，"グリッドアプリケーション" レイアウトで起動する。グリッドアプリケーションの初期ビューは，ボックス内部にレイアウトされたコンテントだ。この形式のアプリケーションにはウィンドウ枠がなく，すべての操作はコンテント自体に対して行われる。
すばやく，滑らかに
タッチベースのアプリケーションにとってパフォーマンスは重要な問題だ。ユーザの気をまぎらわすような間接性を持つマウスとは違い，タッチベースのアプリケーションは，どのような操作にも即座に応答できなければならない。
Windows 8 にはシステムアニメーションのセットが用意されている。ほとんど，あるいはまったく開発作業を行わなくても，大部分のコントロールにおいて，アニメーションライブラリが最初から利用可能になっている。
Windows 8 では新たにタッチ言語が導入される。ジェスチャ数は限られているが，すべてのアプリケーションはそれらをサポートするように要求される。このモデルにはマルチタッチが不可欠だ。ユーザは１本の指で項目をピックアップして，２本でスクリーンをスクロールできるものと期待するが，一度に実施される操作がひとつだけという前提に基づいたマウスベースの操作から，これは大きくかけ離れたものだ。
モーダルと遅延入力は，Windows 8 ではそれほど重要なものではなくなる。例えば項目を選択したければ，それを横切るように指をスライドさせればよい。プレス・アンド・ホールドを行ったり，チェックボックスモードに切り替える必要はない。
アプリケーション内を移動する上での重要なコンセプトがセマンティックズームだ。UI をズームインあるいはズームアウトすると，サイズが変わるだけでなく，表示される内容も変化する。カレンダーアプリケーションをズームインすると，最初は１日のスケジュールが表示され，次には特定のスケジュールがオープンされる，という具合だ。ズームアウトを行えば，１週間のビューから月間ビューへと移動する。
Metro アプリケーションはすべて，タッチ操作とマウス操作を同一のユーザインターフェースで同じようにサポートする必要がある。ユーザはそのときの場所や使用しているデバイスによって，タッチかマウス，あるいはキーボードを使い分けることになるだろう。Microsoft はすべてのデスクトップ PC がタッチスクリーンを装備する一方で，最も小型のタブレットなどにもマウスやキーボードを備えたドッキングステーションが提供されると考えている。これを容易にするため，一般的なマウス機能に関するサポートがいくつか組み込みで用意されている。その一例が右クリックで，アプリケーションバーやその他のコンテキストコマンドをオープンする。
画面の解像度
すべてのアプリケーションがサポートしなければならない標準サイズは 1024x768 だ。これは Windows 8 がサポートする予定の最少画面サイズなので，アプリケーションはこれ以下の解像度で動作する必要はない。
その次にアプリケーションがサポートする必要のあるサイズは 1366x768 のワイドスクリーンだ。一般的に言ってこの解像度は，標準サイズとそれほど大きな違いはない。しかし次に説明するモードであるスナップビューをサポートするためには，最少でもこの幅の画面が必要になる。
すべてのアプリケーションには，スナップビューのサポートが要求される。わずか 320 ピクセル幅が広いだけだが，その中でユーザがアプリケーションに期待するものをすべて表示しなければならない。加えて標準モードからスナップモードへの移行が，ユーザの操作場所を損なうことなくスムーズに実行できる必要がある。
ポートレートモードはオプションである。Microsoft がこれを必須としなかったのは，ほとんどのデスクトップあるいはラップトップコンピュータが画面の回転をサポートしていないためだ。それでも多くのアプリケーションにとって，このモードはメリットがあるものだろう。
コントラクトとアプリケーション統合
Windows 8 のもうひとつの大きなテーマがアプリケーション統合である。Windows 8 オペレーティングシステムは "検索" や "共有" といった共通機能に関して，一連のコントラクト(Contract) を提供する。
すべてのアプリケーションは，共有コントラクトのソース側処理を実装しなければならない。これによって，他のアプリケーションに対して簡単かつ容易に情報を送信することができる。ここで言う共有とは Eメールや Twitter を意味するのではない。翻訳ソフトやノート記録アプリなどといった，情報の外部への貼り付けを行うものがターゲットだ。ソース側のコントラクトを実装することにより，アプリケーションは自動的にすべての共有ターゲットとの互換性を確保する。
アプリケーションに関連の深いもうひとつのコントラクトは，検索に関するものだ。"検索チャーム (search charm)" にクエリを入力してアプリケーションにタッチすると，結果を表示する領域がスクリーン上に確保される。アプリケーションのリストは表示されたままなので，検索結果のセットから別のものにすばやく切り替えることができる。
検索コントラクトは，PDF リーダの検索ダイアログのような内部検索のためのものではない。何らかの方法でトップレベルの検索ページが必要なアプリケーションのためのものだ。検索が必要な例としてはレシピアプリや，Wikipedia のラッパなどがある。ユーティリティアプリケーションなどでは通常，検索コントラクトの実装は行わない。
ピッカー(picker)コントラクトは，アプリケーションあるいはサービスのデータ共有を実現するものだ。ファイルをダウンロードしてハードドライブに保存する代わりに，アプリケーションから他のアプリケーションに対してデータを直接要求することができる。現状ではアプリケーションがそれぞれ，すべてのサービスを呼び出すための Web サービスを実装しなければならない。これに対してピッカーコントラクトは不可知論的なアプローチを採用する。ピッカーをサポートするアプリケーションは，インストールされている任意のピッカーソースからデータを受信可能である。
ライブタイル
タイルは単なるアイコンではなく，アプリケーションの拡張であると考えられる。タイルはアプリケーションが動作していない場合でも，常に動作しているような印象を与える必要がある。タイルの目的は，アプリケーションに関連する情報を表示することによって，ユーザから心理的応答を引き出すことにある。個人用アプリであればフォトギャラリのイメージを表示するだろう。財務アプリならポートフォリオを参照して株式ティッカを表示するかも知れない。
タイルはガジェットではなく，それぞれがひとつのタッチポイントを持っている。システムの一貫性を確保するため，タイルはテンプレート化されている。すべてのコントロールが可能なテンプレートも用意されているが，ほとんどのアプリケーションはテキストとイメージを単に指定して，Windows がレイアウトを行う方法を選択するだろう。
タイルはテキストとイメージの両方を表示するためにスクロールアップおよびダウンをする “ピーク (peek)” という考え方をサポートしている。ただしスクロール幅はそれほど大きくはない。
通知
通知 (Nortificstion)は任意のタイミングで，任意のアプリケーション上に表示される。ユーザはそれを無視するか，オープンするか，あるいはスクリーン外にスライドすることができる。通知を全体的に無効化することも可能なので，アプリケーションはこれに過度に依存しないことが大切だ。
注意が必要なのは，未確認の通知のための "がらくた箱" が存在しないことだ。通知を確認する機会は一度しかない。ユーザが通知を見落とすことがあるので，アプリケーションは状況に応じてライブタイルを更新することが重要だ。
プッシュ通知
アプリケーションはプッシュ通知 (Push Notification) を発行することができる。これによってアプリケーションが実行されていない状態でも，ライブタイルを更新することが可能になる。重要なのは，アプリケーションが実行しているのは画面に物理的に表示されている時に限られる，という点を理解することだ。したがってプッシュ通知はしばしば，アプリケーションが応答性を維持するための唯一の手段となる。
ローミング設定
Metro アプリケーションにはローミング設定の使用が求められる。アプリケーションがあるデバイスに設定されたなら，ユーザが次に使用するのがどのデバイスであるかに関わらず，設定された状態を保つべきだ。機器間で設定の同期を図るためには，Windows Live のアカウントがバックエンドインフラとして使用されることになるだろう。
明示的な保存が不要
アプリケーションの切り替え時，Metro アプリが中断するまで何らかの処理を行う時間はわずか５秒である。そのためアプリケーションは，常に状態を保存していなければならない。保存ボタンを提供するよりも，取り消し動作のための方法を提示することが望ましい。
理想を言えば，ユーザが単一のデバイスでデータを操作した場合，別のデバイスを選択してもその変更が簡単に参照できるべきだ。重要なビジネス情報からゲームのファイル保存に至るまで，すべての操作がこの方式で動作するように求められている。