0

最近のソフトウェア プロジェクトの UI デザインに関連するチームと大きな議論をしました。

特別なバージョン管理システムを既存の製品に統合する必要があります。これは、テスト スクリプトを記述および再生することによってテストするためのソフトウェア テスト ツールです。

デザイン チームは、私が同意できないデザインを出しており、基本的なデザイン ルールに反していると考えています。

私の観点からすると、設計の最大の問題は、バージョン管理の特別なもの (ビューの作成、チェックイン/チェックアウト スクリプトなど) を既存の UI に追加することです (実際には、既存の UI をコピーして別の UI に変更し、何かを追加します)。 ）。たとえば、[プロジェクトを開く] ダイアログで、UI をコピーしてから 2 つのボタンを追加して、特別なバージョン管理をトリガーします (スクリプトを開く前に、プロジェクトのソース コードを含むバージョン管理ビューが必要です)。

私は設計チームと何度も議論しましたが、この例では、ソフトウェア テスト ツール機能とバージョン管理スクリプト機能のように、異なるものを一緒にするのは悪い考えです。そして、これらを行うことでUIが重複し、同じ問題を解決するための状況が増え、メンテナンスの大きな問題になることを説明しました. また、UI から 2 つを分離することを好みます。一方の UI (ダイアログまたはウィザード) は、2 つの異なるもののうちの 1 つだけに焦点を当てる必要があります。

「1つのUIに2つのまったく異なるものを含めてはならない」というUI設計原則をまとめました。彼らはそのような努力とすべての側面の努力 (より多くの UI、UI が解決するより多くの状況、2 つの異なるものを分離する UI 設計と比較してより多くの開発/テスト/メンテナンスの努力など) をユーザーのために払いたいと主張しましたが、使いやすく、使い勝手の良いソフトウェアを手に入れるために。もちろん、私はそのような宣言に完全に同意しません.他のすべての面で優れていないソフトウェアが、ユーザーにとってどのように優れているのでしょうか? また、設計チームはまだ完全な設計を行っていないため、測定するものは何もありません。

そして、それはチームを納得させることができないという結果に終わります。すべてがまだ客観的に見えます。

これにより、私たちの状況をカバーする優れたUI設計ガイダンス/ベストプラクティス/原則はありますか? 1 つの特別な UI、ダイアログ、またはウィザードなど..)

上記の質問に特別なものではなく、問題全体に関連するコメントや提案をいただければ幸いです。また、ここでうまく表現できなかったことについてもお答えします。

これを閉じないでください :) これは、開発マネージャーとしての私にとって本当に大きな問題です。

4

2 に答える 2

1

@JanNeilson に同意します。デザインの原則は、開発者に UI デザインを変更するよう説得するのに役立たないということです。

機能するのはユーザビリティテストです。数人のユーザーがソフトウェアを使おうとして行き詰まるのを見ると、開発者は身もだえし、UI を修正したくなるでしょう。一方、実際のユーザーが新しいソフトウェアを問題なく使用できることがわかっている場合は、問題はなく、設計原則は重要ではありません。

ユーザビリティ テストは、顧客をラボに連れて行き、ソフトウェアで特定のタスクを実行してもらい、ユーザーと画面のビデオを記録する正式なプロセスになる場合があります。

重要:テスト ユーザーには、テストしていないことを必ず伝えてください。ソフトウェアのテストを手伝ってくれるよう依頼していること。ソフトウェアが気に入らなくても気分を害することはないことを説明します。あなたは正直な反応を望んでいます。定期的に、何を考えているかを言うように頼んでください。完全に行き詰まらない限り、ハウツーの質問には答えないでください。

ユーザビリティ テストは、何人かのランダムな同僚に試してもらう非公式のプロセスでもあります。私はカフェテリアでこれを行いました。何人かの同僚に新しい UI を見せて、新しいアイコンの意味 (表現) を尋ねました。

各テスト中またはテスト直後にメモを取ります。後で開発者に録画したビデオを見てもらうか (待機部分を編集して、開発者がすべて見ることができるようにする)、またはテスト中に別の部屋からビデオを見ることができます。または、ビデオがない場合は、一度に 1 人の開発者を部屋に連れてきて、視聴することができます。開発者は、ユーザーの質問に最初に「お粗末なユーザー インターフェイスを作成して申し訳ありません」と言わずに答えてはなりません。

ソフトウェアがこのテストの準備ができていない場合は、紙のモックアップを使用してユーザビリティ テストを行うことができます。

ユーザビリティテスト専用のフィールド全体があります。よく訓練された専門家がいます。経験豊富なコンサルタントに依頼するか、それについて学び、自分で試すことができます。

ウェブで検索すると、多くの記事や本が見つかります。これは非常に良い記事です: http://alistapart.com/article/usability-testing-demystified

ユーザビリティ テストに関するウィキペディアの最初の段落には、次のように書かれています。

ユーザビリティ テストは、ユーザー中心のインタラクション デザインで使用される手法であり、ユーザーに対してテストすることによって製品を評価します。これは、実際のユーザーがシステムをどのように使用しているかを直接入力できるため、かけがえのないユーザビリティの実践と見なすことができます。これは、専門家がさまざまな方法を使用してユーザーを関与させずにユーザー インターフェイスを評価するユーザビリティ検査方法とは対照的です。

イタリック体を追加しました。つまり、ユーザビリティテストなしでは、良いユーザビリティは得られません。対照的に、原則と経験に基づいて専門家に UI を評価してもらうことは役に立ちますが、必須ではありません。

于 2014-03-09T17:21:09.587 に答える
0

この質問では、いくつかの異なる側面に触れています。UXの管理に焦点を当てます。

「関心の分離」のような一般論を論じる代わりに、UX の観点と、より抽象的または一般的な概念の両方から、特定の UI デザインに関する具体的な問題を検討します。これを行うには、UI モックアップが必要です。また、UI モックアップの前に、UI モックアップを駆動する UI の意図の基本セットの説明が必要になります。UI のモックアップを作成したら、UI のユースケースについて説明し、関心の分離やその他の特定の原則のために UX の問題が懸念される理由を強調できます。

私の経験では、それを理解している人はそれを聞く必要がなく、理解していない人は理解するのに十分なコンテキストを得るためにモックアップが必要なので、一般論を議論することは効果的ではありません.

UI のモックアップを作成するために必要なリソースについて懸念がある場合は、「UI のモックアップを紙にまとめるのに 3 時間かかり、レビューしましょう」など、時間制限を設けることを検討してください。

于 2014-03-09T05:18:00.357 に答える