ちょうど手が空いた外注のプログラマがいたので、その画像を渡して、プログラムを変更してもらった。といっても、画面をデザインするツールを使って、「ラベル」を張り、文字列を書くだけの簡単な作業だ。
しかしである。後で出来上がった画面を確認すると、顧客から送られてきた画像と、かなり印象が違っていた。追加した文章の「行間」が開きすぎているのだ。
作業をお願いしたプログラマに指摘して直してもらってもよかったのだが、そのまま自分で修正した。そのほうが早かったし、彼もそうした細かいことを言われたくないかもしれないと思ったからだ。
しかし、その判断が彼にとって良かったのかどうかはわからない。それがもし自社の若手プログラマだったら、指摘して直させただろう。実際、少し前には、同じ理由で、新人プログラマに別の画面レイアウトを直させたばかりだった。
★
実は、そういう私も、新人の頃に同じようなことをして、リーダーに指摘されたことがある。
ある画面に、黒い三角形が表示されたボタンを付けたときのことだ。ちょうどカーソルキーのように、上下左右の方向を表す4つのボタンだった。私は、それらに、あえて顧客が作った資料の画像とは違った三角形を載せた。資料の三角形は大きすぎるし、並べたときのバランスも悪いと思ったからだ。つまり、自分では親切のつもりだったのだ。
しかし、リーダーに見せると、顧客の指定している通りに直してくれと言われた。今にして思えば当然である。受託開発では、開発しているプログラムは顧客のものであり、私のものではないのだから。
プログラマの中には、このようなシステムの動作に関係ないようなことはどうでもよいと思う人もいる。しかし、どうでもよいのなら、依頼者の意向に合わせてやればいいではないか。
顧客が提示するデザインには、こちらには分からない「こだわり」があるかもしれない。特に、デザイナーが携わっているような場合には、1ドットでも変えてしまえば、彼らの仕事を台無しにしてしまうかもしれない。
★
もちろん、現実には、顧客側に何のこだわりもない場合も多いだろう。ワープロの文書上に「罫線」で描かれているような画面を、そのままプログラムで再現することはできない。また、技術的な制限によって、顧客の希望通りにできないこともあるだろう。
しかし、どんな場合でも、なるべく顧客の意図を汲み取って、それに近づけようと努力はすべきだ。意図がはっきりしない場合、あるいは実現できない場合には、顧客とよく相談しながら進めていく必要がある(実際に画面を作って見てもらうということが最も有効だ)。それは、「データ処理」だろうと、「画面レイアウト」だろうと同じことなのである。
■関連記事
・デザイナーの屈辱
・アイコンの色を塗る時
ユーザビリティエンジニアリング
―ユーザ調査とユーザビリティ評価実践テクニック
―ユーザ調査とユーザビリティ評価実践テクニック
posted with amazlet
on 06.11.26
樽本 徹也
オーム社
売り上げランキング: 14044
オーム社
売り上げランキング: 14044
おすすめ度の平均:
ユーザビリティ評価を効率的に行うために実践的で入門書として過不足がありません
プロジェクトの最初から!
GUIデザイン・ガイドブック―画面設計の実践的アプローチ
posted with amazlet
on 06.11.26
菊池 安行 山岡 俊樹
海文堂出版
売り上げランキング: 69038
海文堂出版
売り上げランキング: 69038