ライトニングは優れた戦闘機であったが、ハードポイントの増設やレーダーの換装により多用途性が付加された輸出型の海外セールスは同時期の他国の戦闘機と比較するとあまり芳しくなく、わずかにサウジアラビアとクウェートが導入したのみであった。西ドイツ空軍に採用を働きかけたこともあったが、イギリス政府の支援を得られなかったことによりF-104 スターファイターに敗れてしまった。日本の航空自衛隊による「第2次 次期主力戦闘機導入計画（第2次F-X）」の候補機に名前が挙げられたこともあるが、あくまで「第1次調査」における予備候補の域を出ることはなかった。サウジアラビアに導入されたライトニングはイエメンとの紛争に投入され主に対地攻撃に使用された。
ライトニングの一部は、イギリスが開催するエアショーであるロイヤル・インターナショナル・エアタトゥーで稼働する姿が確認されている。なお、このショーに参加する他の機体にも言えることが、機体はタキシングとエンジン点火のみしか見せていない。その他、南アフリカのケープタウンにあるサンダーシティ社で、複座型が遊覧飛行用として使用されている。
2基のジェットエンジンを前後にずらした上で縦に並べて配置するという、量産された戦闘機では後にも先にも例がないエンジン配置を採用している。先端の空気取り入れ口はコックピット後ろで上下に分かれ、主翼下にあるエンジンと胴体後方上のエンジンに空気を送る構造になっている。これは通常の並列配置よりも胴体を細くでき空気抵抗を減らすことが目的で、片方のエンジンが停止してもトリムが変化しないというメリットもあった。しかし、エンジンの点検整備や交換作業が煩雑になり、胴体内に燃料タンクを設けるスペースがなくなるというデメリットがあった。また、高温になりやすく、オイル漏れが発生するとすぐ火災に直結するという問題点もあり、イギリス空軍が損失した80機の内、約22機が空中火災によるものだった。エンジンの取り出しは機体の上下から行い、燃料タンクは機体下部を膨らましたような形で設置されている。主翼はデルタ翼の空力的に必要性が無いとされる内縁部をカットしたような形状で、構造上は通常の後退翼と同じであり、図らずも後の標準たるクリップトデルタ翼の始祖になったと評価されている。これは離着陸時にデルタ翼機のような大仰角を強いないものの、翼内燃料タンクスペースは減少する。また、主翼下面には主脚が格納されるため大型のハードポイントが設置できず、増槽のような大型の装備は搭載できなかった。前述したように胴体内に燃料タンクが設置できなかった点もあり、増槽を主翼上面に装備するという苦肉の策が取られるなど幾度かの改良を経ても航続力が短く、兵器搭載量にも乏しいという欠点が付きまとった。しかし以上のデメリットを考慮しても余りある多くの利点もある。マッハ2.0の速度を持ち特に運動性が良好であったライトニングは、同世代のF-104 スターファイターやミラージュ III等にも引けを取らない優れた戦闘機であり、局地防衛を重視した強力なエンジン推力は、後に登場するF-15 イーグルやSu-27 フランカーに劣らない上昇力をもっていた。本機は後にトーネード ADVによって更新されるが、上昇力に関しては本機のほうが優れていたため、ある操縦者は不満を述べたともいう。また、それまでのイギリス製戦闘機にない次世代的な照準器を装備し、レーダー性能など大きく飛躍を遂げた戦闘機でもあった。
ハードウェア記述言語による設計の本質は、ハードウェア記述言語プログラムをシミュレーション可能な点にある。シミュレーションすることで、設計のハードウェア記述言語プログラム（モデル）が設計検証に合格するようにできる。設計検証は、コード実装（ハードウェア記述言語プログラム）がその設計が意図した機能（仕様）に対して妥当かを検証する重要なマイルストーンである。シミュレーションによって構造（アーキテクチャ）的な吟味もする。技術者は基本設計に対して複数の設計を実験的に書き、シミュレーションでそれらの動きを比較することができる。以上のようなことから、ハードウェア記述言語による設計ではシミュレーションが重要である。ハードウェア記述言語で書かれたモデルをシミュレーションするには、テストベンチと呼ぶシミュレーション環境をまず記述する。テストベンチには少なくとも、モデルを実体（インスタンス）化したもの（Device Under Test、DUT）、そのモデルの入出力のためのピンと信号の宣言、クロック波形が必要である。テストベンチのコードはイベント駆動型である。テストベンチが生成するリセット信号の実装、インタフェース・トランザクション（ホストバスの読み書きなど）のモデリング、そしてDUTの出力モニタのための記述が必要となる。テストベンチを実行するソフトウェアをシミュレータと呼ぶ。シミュレータはテストベンチ内の全イベントの参照元となるシミュレータ・クロックを発生させる。イベントはテストベンチのプログラムが指示したときだけ発生するもの（テストベンチ内のコードでリセット信号を発生させるなど）と、およびそのようなイベントへの反応としてモデルが発生するものがある。最近のシミュレータはGUI化されており、デバッグツール一式も備えている。利用者は任意の時点でシミュレーションを中断/再開でき、ブレークポイントを設定でき、モデルの階層を監視／変更できる。さらにプログラム実行環境に利用者がコンパイルしたライブラリをPLI／VHPIインタフェースを通してリンクできるシミュレータもある。リンクは環境依存であり、シミュレータと利用者ライブラリのコンパイルとリンクは、HDL環境の外部で行う。設計検証は、ソフトウェア開発工程で言えばソフトウェア試験（ソフトウェアテスト）とデバッグの工程である。設計工程の中でも最も時間がかかる可能性がある。試験結果によっては大きな設計変更もありうるため、シミュレータ環境で最初に行う。ただし、厳密に定義したコーディング規約に基づいているかどうかの検査を先に行うことにより、試験作業を大幅に短縮することもできる。プログラムをハードウェアで検証する目的でPLD（プログラマブルロジックデバイス）、FPGAを使うこともある。ハードウェアを使ったプロトタイピングはシミュレーションよりも費用がかかるが、シミュレーションではわからない設計上の問題点が明らかになることもある。他のハードウェアとのインタフェースの確認はハードウェアによるプロトタイピングが最善の方法である。FPGAは、シミュレータより高速に動作するだけでなく、実際に並行実行するための時間的な問題について検出可能である。