4．デザインイメージの検討、調整

企画時のおおまかなデザインイメージを見直し、実際に操作することを想定して、詳細部分を含めてきちんと検討する。

各画面の詳細検討に入る前に、だいたい決めておく。

共通部分はほとんどの画面に関わることなので、先に決めておいたほうがいい。
バラバラに作ったものをあとで統一したり、各画面を作ってから変更をするのは、とても手間が大きくなる。

メニュー体系・画面遷移の検討と、並行で作業を進めてもよい。

検討・調整で決まったことを、ドキュメント化する。  
顧客が見て確認するためにも使われるし、製造にたずさわる技術者が見て作成するためにも使う。

この作業の前段階として以下の作業を行い、また、作業に必要な情報として以下のものや情報等を用意しておく。

この前の作業	事前情報、他
・企画案の検討・メニュー体系図作成	・企画案・ヒアリングで得た情報・一般的な／最新の業界・技術情報・対象システムの業務知識・（ドキュメント系）ツールの知識 ◾技術知識（マシン、ソフト、プログラム言語）

1．システムの各画面を（だいたいでいいので）想定し、デザインとして共通的な部分と、その定義内容を抽出する。

2．１と並行して、画面デザインや操作性について、顧客の持っているイメージをヒアリングする。

3．ユーザの見やすさや使いやすさを考え、画面全体や抽出した共通部分に対して、どんなデザインにするか検討する。

　メニューや画面遷移のあり方を考える。

　システム全体で、用語の使い方を統一する。

「戻る」「終了」などの言葉の使い方に気を付ける。
単に「戻る」としても、複数の画面からジャンプする可能性のある画面の場合はどこへ戻るのか不明確になりがち。直前の画面に戻る場合もあれば、トップ画面に戻る場合もある。
同様に「終了」も、ある機能／画面が終了するだけなのか、システムそのものが終了するのか分からないことがある。
明確な言葉を使ったり、言葉によって機能をきちんと使い分けたりする。
他にも同じような言葉があれば、ユーザが見てどう思うか、きちんと検討し、統一しておく。
統一されていないと、印象を落とすだけでなく、操作上ユーザを混乱させる。

4．技術的な実装方法、作りやすさを考える。「どうやって実現するか」の目途を立てておく。

「それでやりましょう」ということで顧客と合意してしまったら、やらざるを得ない。
技術的に難しいのであれば、あらかじめそれを相手に伝え、理解してもらったほうがいい。
単に「技術的に難しいので、できません」と言うのは、印象も良くない（こちらは「技術者」なのだから．．．）。ただ「できない」ではなく、代わりの方法の提案などをあわせて伝える。

5．必要に応じて何パターンか検討し、調整する。

6．決まったことをドキュメント化する。

この作業で以下の成果物を出す。または完成イメージの状態にする。それをこの後の作業につなげる。

成果物、完成イメージ、他	この後の作業
・共通デザイン定義	・サンプル画面作成・各画面設計

画面（や帳票）の見た目や操作性は、システムを使う人にとってのイメージ  
（＝その企業に対するイメージ、システムに対するイメージ）を決める部分となる。

システム全体の中で今いる位置や、前後の業務手順などが分かりやすいような構成・デザインを意識する。

検討した内容を、相手に口で説明するだけでは分からないので、実際にサンプルを見てもらうほうがいい。

ドキュメントに内容をひとつひとつすべて書こうとすると、冗長になることがある。

results matching ""