システムの開発 (主に Web アプリケーション) を外注すると、とにかくユーザビリティの低い、非常識としか言いようのないものが納品されがちで、それを後から修正させるのはかなり困難です。

「ユーザビリティ」というとやはり曖昧ですよね。

大変面倒かもしれませんが、求める内容を以下のように数値化して

仕様に含めてから契約するのが良いと思います。

・処理Ａから処理Ｂまで３クリック以内で到達出来ること。

・処理Ｃの実行完了までユーザに入力を求める画面は２面以内に収めること。

・どの状態でも、画面Ｄに不整合なく１クリックで戻れること。

などなど。

http://e-words.jp/w/XP.html

>顧客を常に開発チームに参加させる「オンサイト顧客」などである。

上記をお勧めします。

納品時にユーザビリティが問題になること自体、開発中のコミュニケーション不足と思います。

質問された方は開発中に一度でも開発会社に足を運ばれたのでしょうか？

上記が質問者の現状を良く表していると思います。

必要なのは開発会社との密なコミュニケーションに尽きると思いますね。

画面遷移などの設計を終えた上で発注すればいいのではないでしょうか。それがどうしても無理ならば、画面遷移図を発注先に書かせた段階でレビューすればそこで指摘はできます。

１．担当SEに自分たちの仕事を経験してもらう。

２．アプリケーションの仕様の打ち合わせには、かならず、それを実際に使うであろう人をメンバーにいれる。

３．使ってみないとわからない部分が必ずあるのを前提に、納品後、数ヶ月は、バグの修正はもちろん、ある程度の仕様変更が可能な契約にしておく。（ソフトウエアを作る側はこれを一番嫌うでしょう。）

４．完全に出来上がってから、大幅な仕様変更がなくてすむように、開発段階から少しずつ実験的に使用し、その結果を開発にフィードバックする。これを繰り返して開発する。

５．十分なテスト期間とバグ修正期間を考慮に入れて、余裕を持った開発スケジュールを組んでもらう。

６．私に依頼する。まずは、ご相談下さい。（笑）

まずいかに「要求仕様」をきっちりとまとめ出せるか？にかかっています。

「自分たちの求めるもの」

　・機能

　・性能

　・他システムとの連携

　・その他

こういった事を、まず漏らさず開発陣に伝えることから始まります。

またもちろん伝えるだけではダメです。

特に機能的なこと、操作性に関してはプロトタイピングも行いながら、早期にお互いの意見すりあわせを行いましょう。

そのために大事なのは、あなた方発注者と、開発者の間に立つSE/SIです。

この SE なり SIer がヘボではどうしようもありません。

正しく発注者の言うことを理解し、開発者たちを適切にコントロールできているかを見極め、力不足と感じるならば交替させましょう。

設計のフェーズまでは現場に入ってもらって、一緒に要求仕様をまとめ上げ、基本設計、機能設計を行うというのもアリでしょう。

前につとめていた会社ではまず、画面設計に関しては自社で全て指示を出しました。

インターフェイスに関しては以下のようなフローで進めていました。

１．画面の移管図を作成

２．画面の詳細なデザインを行う。

（場合によってはデザインを外注する）

３．HTMLベースに起こす。

ここで、3のHTMLをシステム開発会社に渡し、php,もしくはjspで開発させていました。

つまりはインターフェイスは自分たちが納得いくものを、相手に渡し、かつ、HTMLの部分に関しては自分たちでデザイン的なメンテナンスも出来るようにさせます。

当然、システム会社には処理が発生する部分だけ、プログラムを

組み込ませるので、無意味にHTMLコードが汚れるということも防ぎます。

この方法のメリットはインターフェイスは自分たちのイメージ通りのものが仕上がる反面、自分たちで結構用意するものが増えるので、時間的なコストがかかるという点です。

デザインまで外注すると、金銭的なコストも当然かかります。

が、契約次第で、システム会社に画面設計と移管図の作成がなくなるので、安く発注出来る場合もあります。

他の回答者同様、ユーザービリティの定義は非常に曖昧です。

まずはpmakino様の考えるユーザービリティをドキュメントにまとめられてはいかがでしょうか？その際気を付けなければいけないのは、曖昧な表現は使わない。具体的な数字で明確に意思表現することです。

理解してもらえないのであれば、注文（契約）自体取り消すべきです。Web製作費はとても高額なので納得いく発注先を見つけてください。

何も言わなくてもわかるだろう、常識でしょ？はことソフトウェア業界ではとても危険な発想です。エニジニアはソースを書くとき理論的にコードします。その際に曖昧な要素が入ると色々良かれと考え、要望と異なる仕様もでてきます。ＳＥはその際に方向修正を行わなければいけませんが、曖昧な要素を含む場合、ここでも間違った方向へ軌道修正される可能性があります。

・外注先の質を高める。相手は一流企業ですか？

・ＳＥも一流ですか？本当にお客様のニーズを考えられるか？

・ちゃんと相手に仕様を伝えられていますか？議事録や仕様書のドキュメは管理できていますか？

・小さな企業であれば、プロジェクトに関わる技術者を打ち合わせに参加させてもらう。

ユーザービリティーの認識齟齬の回避を行なうには

モックの作成を推奨します。

モック（mock-up：原寸模型）とは固定表示のHTMLだけで

紙芝居の要領で動作を擬似的に再現したものです。

たとえば、検索画面ならば実際の検索処理は実装しないで

検索ボタンを押下すれば固定表示の検索結果画面のサンプルに

画面が遷移するようなものです。

１．要求仕様に基づいて受注側がHTMLだけで画面モックを作成

２．発注側がモックの動作をレビューする

３．レビュー結果を受注側に伝える（要求仕様に反映）

１～３を繰り返して、発注側・受注側の意識を統一します。

------

以下、ご参考まで。

問題の根本原因は、他の方も指摘しているように

要求仕様自体があいまいなのだと思います。

画面内の動作・使用感に関しては、画面遷移図だけですと

人によって意図したものと異なる場合があるので

基本設計の行程で動作パターン毎に画面部品として規定して

この画面部品を組み合わせて画面を構成するようにします。

「オンサイト顧客」は非常に有効な手段で

一見、コストがかかるように思えますが

手戻りや仕様齟齬のリスクや開発スピードを総合的に

判断すれば、かえってコスト的にもメリットがあると思います。

また契約については、要件定義、基本設計、詳細設計、実装

などの行程毎に分けて契約を行ない、各段階でレビューして

方向性が間違ってないか確認する事が大切です。

画面遷移図、状態遷移図を描かせることですね。

また、ユーザービリティを求めるなら、プロジェクト参加予定者が今までに関わってきたプロジェクトのWEB画面を確認したほうが良いと思います。

発注前に実績を確認しないと大変なことになることが良くあることに最近気づきました。