« 2008年10月 | メイン | 2008年12月 »

2008年11月 アーカイブ

2008年11月05日

機能的デザイン

「機能的なデザイン」を作り、かつ無駄に時間を使うことなく設計するにはどうしたら良いのか?

それには、最初にとことん画面デザインで考えることに尽きます。

歳のせいなのか、それとも生まれつきなのか、一つの物事を繰り返し考えている杉山です・・・。

しかし、SEにはそんな性質が合っているのかもしれません。
また、それくらい画面周りは重要だと思っているのです。

今回は「画面が機能的であること」について追及してみます。

通常、画面デザインを行う場合は、画面の共通事項、設計の前提条件について決めるところから始めます。


1)画面解像度を決める

正直、今だに「800×600」は、ないでしょう。
「1024×768」でも小さいくらいです。

端末PCがノートブックばかりだとしても「1280×768」で良いのではないかと思います。

最近はワイドモニターの方が値段が安いってご存知でしょうか?とにかく、時代に合わせて考え方を変えていくことが重要です。

ユーザーがどの解像度で使用するかを想定することで、画面にどれだけの情報を表示できるかが決まるので、一番先に決めたいことですよね。


2)マウス操作だけでない操作手段を決める

F1からF12までのキーを意味付けて使うのかなどを決定します。

・忙しいときに慣れた人であれば両手を駆使してすばやく操作できること
・初心者がゆっくりと判断しながら操作できること

これはどちらも要求される機能です。


3)画面として共通に表示する項目の位置を決める

ログイン者情報、日付、時刻を表示するといったことですね。
こういった共通項目を後から追加するのは開発者に無駄な工数を負担させる元です。


4)どんな種類のボタンを作るのかを共通して決める

例えば、Webシステムでよく使われるボタンとして以下のようなものがあります。

「戻る」「クリア」「ログアウト」「閉じる」「次へ」「確定」「登録」「更新」


この中でも、「次へ」や「確定」といった表記はその後にどんな画面が表示されるのかが分かりにくく、かつ、システムで何が行われるのかも分かりません。

ユーザーはボタンを押す場合に迷うだろうと思います。
このような押すのに躊躇するようなボタンはいただけないです。

・誰が見ても何の処理をするのかが推測できるアナウンスを付けること


5)横スクロールは出さない

できれば縦スクロールも使用したくないところですが、Webデザインの場合、縦スクロールは許容されているようです。


これらのことは、システム開発の仕事をしている人であれば常に考え、一定のルールの基で仕事をしていることでしょう。

しかし、わたしが一番大事にしていること、それは「無心で画面に向かって操作してみる」ということです。

「これはこういうルールなんだから、というような思いこみを捨てて操作できるか試してみる」

これです。

客観的に、時には主観的に、画面を見て操作しやすいかどうかを判断するのです。

Webサイトの制作では、こういうことが研究されていますが業務系のシステム開発でも同じです。

・人は間違えやすい
・人は細かく文字を読んで操作はしない

この気持ちを忘れずにデザインするのです。

続きを読む "機能的デザイン" »

2008年11月11日

ダメな画面設計で思うこと

さてこのところずっと、画面設計周りの話をしてまいりました。

さすがにネタが尽きてまいりましたので、これまでに出会った「ダメな画面設計」について話してみたいと思います。

実際、ダメな画面設計というのにも理由はいろいろあるのです。

一番悲しいなと思ったのは、「明らかに経験が少ないプログラマが考えもなく作ってしまったもの」でした。

それは、伝票入力の画面でした。

前回、画面の解像度のことをお話ししたと思うのですが、当時(10年くらい前でしょうか)解像度は1024×768で設計されていたとしましょう。

商品コードを入力するとシステムが商品名と単価を自動表示し、数量を入力すると、計算結果を自動表示するといったようなものでした。

数量を入力して、金額欄にカーソルが移る際に画面が左にスクロールするのです。

つまり、画面に横スクロールがあるということです。
画面の横のサイズがモニターの解像度を超えているために起こる動きです。

毎行の商品を入力するたびに、画面が右から左、左から右へとスクロールして動くのです。

気持ち悪い限りです。

その画面設計が、一番ダメだという理由は実はもっと深いのです。

今、これを読んだ印象では、項目が長かったり、項目数が多くて横に入りきらなかったのだろうと誰しもが思うはずなのです。

ところが、画面を見るとやたらに項目と項目の間が空いているのです。

つまり、項目の間隔を詰めればスクロールは必要ない。

何を言いたいかというと「ひどい」「笑える」ということではないのです。

「横スクロールしてはいけない」というルールがあった、無かっただけでなく、その画面を開発会社の先輩や上司が実際に見ていないのではないか、ということがひとつです。

よほど慣れた人でも画面設計は何度でも見直し、他人に指摘を受けてより良いものにするといったことが必要です。

次に、本人が作ったものを動かしたときに、なぜそれを不思議に思わなかったのか?
なぜ「まあこんなものだろう」といったことになってしまったのか?
その浅はかな考えが一番気になるところだったのです。

「ちょっと変」を放っておくと、他人にとっては「あり得ない」「とっても変」という事態に繋がるということなんです。

これって、何にでも応用できる考えですよね。

続きを読む "ダメな画面設計で思うこと" »

2008年11月18日

画面設計・・ポータルの設計と検索画面

今回も、画面設計についてです。

よくこんなに題材があるなぁと御思いでしょうが、まだまだあります。
画面設計は、システムの使いやすさ、分かりやすさの肝ですよね。


さて、画面設計には、どんなパターンがあるでしょうか。

1)ポータル画面
2)マスタメンテナンス画面
3)一品一葉の伝票入力画面
4)明細型の伝票入力画面
5)検索から一覧照会画面
6)照会の個別画面
7)印刷やバッチ処理の指示画面

これらに分類されるのではないでしょうか。

この中で設計に一番頭を使うのは、1)の「ポータル画面」や、5)の「検索から一覧照会画面」ではないでしょうか。

なぜなら、部署や人によって、使い方が変わる可能性が高いからなのです。

例として「ポータル画面」を考えてみたいと思います。
「ポータル画面」とは、例えば、ログインしたら最初に表示されるページのことです。

メニューだけが並んでいるのはメニュー画面と呼びますので、「ポータル画面」とは違います。

もちろん「ポータル画面」には、メニューも含まれています。
ただし、一番最初に目につくのは、今日チェックしなければいけない掲示板、承認しなければいけない申請、本日のスケジュール、ToDoの期限だったりするものです。

そして、この「ポータル画面」に表示されるべき画面の部品というのは、実は「検索画面」と大きな関係を持つものです。

例えばToDoリストで明後日以前が締め切りのものを一覧で表示するとします。

社員別ToDo照会といった別の画面を想定してみると、検索条件は、どんな画面になるでしょうか。

・ToDoを登録した社員
・ToDoの期限
・登録日付
・重要度
・ToDoの分類
・未処理か処理済みか

と、ざっくり簡単に考えてみましょう。

もし、「ポータル画面」が無い場合には、この検索画面を呼び出して自分の社員コードを入力し、期限を明後日に指定して検索実行をすることになるのです。

「ポータル画面」では、指示する手間が省けてログインするや否や重要度順や締切日順で、未処理の案件が表示されます。

これは、毎日同じ処理をしなくても良いという点、検索画面で一人一人が検索条件を考える手間やミスが省けるという点で非常に意味のある画面になります。

そして、実際には、「ポータル画面」も「検索画面」も両方ともほぼ同一機能で実現できるのです。
ですから、「ポータル画面」用のデザインとテスト工程を追加するだけで済むのです。

もちろん「ポータル画面」を作らない場合には、検索画面に上記のような、一番よく使う検索条件を初期表示させるのです。

しかし「一番よく使う検索条件」は、部署や社員の仕事の内容によって変わることもあるのです。

結局は、個別対応を切り捨てて汎用的に作ることも多いのですが、画面設計は奥が深く、面白いものなのです。


次回は、汎用性と個別の設定をどうするかについて考えてみます。

続きを読む "画面設計・・ポータルの設計と検索画面" »

2008年11月26日

登録フォームについて

今回はインターネットで一般消費者が情報を登録する
フォームについてのお話です。
ホームページ制作とセットになっていることが多いと思われるので、もはやこれは、システムと呼べるものではないのかもしれません。

フォームには個人情報を細かく登録するものや、中にはアンケートまで必須回答とするものも少なくありません。

こういったフォームを使っていると大体の形が決まっていることに気が付きます。

・郵便番号を入力したら住所の一部分が表示される。
・メールアドレスやパスワードは二重入力する。
・送信ボタンを押すとエラーチェックがされる。
・エラーメッセージは、画面の上部にまとめてわかりやすく表記される。
・確認画面から入力画面に戻ったときにも、
すでに入力した項目は、クリアされない。(パスワードは別)
といったお約束が、どのフォームにも共通で使われていると思います。

お約束が使われる理由として、1つ目は、入力する立場から見て「この方が便利」「この方がわかりやすい」といった総意なのかと思います。
2つ目は、誰もが良いと思うものをマネしていくためでしょう。
しかし、フォームの機能が落ち着いてきてしまったかと思う反面、進歩しているフォームもあるのです。

最近、「おっ」と思ったフォームは次のようなものでした。

入力する項目数が12~13項目と多かったのですが、入力した後で次に進もうとすると、エラーになってしまいました。

すると、OKとなった他の項目は表示されず、エラーになった1項目だけが画面に切り取られて表示されました。
この1項目を再入力してOKとなったわけですが、何かちょっといいなあ、という印象を持ちました。

再入力を促す場合に、文字で丁寧にメッセージを書いてもうっとうしい印象はどうしても拭い切れません。
理由は、入力する項目が表示されている画面に、エラー表示までもが追加されてあるからだと気付きました。

1つの画面を見たときに「人間が印象で理解できる大きさ」というものがあるのではないでしょうか。
1つの画面にありとあらゆる情報を詰め込んで表示しようと考えるのが常なのですが、人に入力を促すという視点から情報の見せ方を考えることも必要なのだと思いました。
画面の操作性といったものも「これで決まり」「これで十分」ということは無く、進化していくものなのです。

そして画面の操作性の進化とは「もっと良いものを作りたい」という気持ちがなければ出来ないことなのです。

続きを読む "登録フォームについて" »

About 2008年11月

2008年11月にブログ「アイロベックスメールマガジン 携帯版」に投稿されたすべてのエントリーです。過去のものから新しいものへ順番に並んでいます。

前のアーカイブは2008年10月です。

次のアーカイブは2008年12月です。

他にも多くのエントリーがあります。メインページアーカイブページも見てください。

Powered by
Movable Type 3.38