フロントエンドエンジニアから、デザイナーへ。。
概要
デザイナーの方々へ、常日頃から思っている思いを書きました。
これ以上争いを生まないように読んでください。。
個人の感想なので、コメントいただいたら追記します。。
また、開発リソースが極端に少ない人向けです。。。
みちゃダメな人
- 予算と時間が有り余っている人
- こだわりの強すぎる人
みるべき人
- エンジニアの気持ちをわかってあげたいが、プログラミングはしたくない人
なぜ両者で溝が生まれるのか。。
エンジニアの主張
我々は、効率的にコードを書きたいのです。。
シンプルにシステムを作りたいです。
デザインに一貫性を持たせて欲しいです。。
複雑度を上げたくありません。
デザインに一貫性を持たせて欲しい理由
- コード量を減らしたい
コード量を減らすには
愚痴
このようなデザインにされると少しイラッとします。
しかし、このフォームは3つ項目がある生年月日欄が一番下に来ているのでマシだと思います。
もちろん作ろうと思えば作れますが。。。
なぜ腹が立つのか?
- 行と列に一貫性がない
我々(少なくとも私には)こう見えています。。
簡略化して描きます
| お名前(必須) | ||
| 姓 lastname | 名 firstname | |
| フォーム | フォーム | 残り必須18 |
| ※注意書き | ||
| フォーム | フォーム | |
| ※注意書き | ||
| 性別(必須) | ||
| フォーム | フォーム | |
| 生年月日(必須) | ||
| フォーム フォーム フォー | ム |
空白欄が多すぎます。この欄はうまく変更することが可能です。
| お名前 | フォーム | フォーム |
| お名前(全角カナ) | フォーム | フォーム |
| 性別(必須) | フォーム(セレクトボックス) | |
| 生年月日(必須) | フォーム |
コード量が減りました。。
1/2になったのではないでしょうか。。
減らせた理由を書きます。。
変更点
- 注意書きをなくした
- 入力項目ラベルを1列目に持っていった
- 性別をセレクトボックスにした
- 生年月日を一つのフォームにした
- 残り必須入力項目欄をなくした
- 必須項目ラベルをなくした
共通して言えること
htmlとjavascriptにはこんな素晴らしい機能があります。。
クライアント側のフォームデータ検証
この機能を適切に使えば、、デザインも楽じゃない??って言いたいです。。
また、必須ラベルとか貼らなくても入力しなかったらフォームが真っ赤になってくれるし。。。
注意書きをなくした理由
プレースホルダーに書くだけで伝わるかと思います。
読まない人がいる前提で書かないと意味がないです。
また、デザイン的にも一貫性がなくて気持ち悪いのではないでしょうか。。。。
入力項目ラベルを1列目に持っていった理由
必ず存在する項目なので、一列目に持って行きました。
また、横の余白、、気持ち悪くない??
性別をセレクトボックスにした
ボタンを押したら、このデータを入れるとか、、めんどくさいんですよ、、
最初から、html側に選択肢が入っていた方が保守しやすいですよ。。
生年月日を一つのフォームにした
システムに入れるときは最終的に結合するので、最初からCCYYMMDDの形式で入れて欲しいですね。。
変換も楽ですし。。
残り必須入力項目欄をなくした
これは、フォーム送信ボタンの横にでも置いてあげたほうが親切ですよ。。
必須項目ラベルをなくした
これは上に書いた通りクライアント側のフォームデータ検証を利用すれば目的は達成できます。。。
複雑度を上げたくない理由
小難しいことが書いてあるので、元気な時に読んでください。
要約すると、
- テストしやすくしたい
- 凝縮度をあげたい(コンポーネント化しやすくしたい)
主張
- 一画面でできることをなるべく少なくしてください。。
- 機能を重複させないでください。。
- 遷移のパターンを無駄に増やさないでください。。
なぜテストしやすくしたいか
バグが生まれたとき、どこで発生したか特定する作業が必要です。
その際、バグが起きる条件を再現する必要があります。
複雑に入り組んだ画面だと、構造的な問題でバグが起きる状況を再現するのが困難であることが多いです。
具体例
ユーザー登録するのに、情報の入力が必要で、登録フォームをダイアログをで表示している画面があると仮定します。
3ステップで情報入力が完了したら、ユーザー登録が完了になります。
3ステップ目でバグが起きたとします。
そこで、原因を特定する必要がありますが、デバッグするのに2ステップ目まで何度も同じ動作をしなければなりません。
いかにして解決するか
- 仕様を変更する
- デザインで解決する
上の例の場合、デザインで解決できる場合があります。
入力する情報が少ない場合、システムが目的を達成するのにダイアログにする意味はありません。
複雑度とは何か
循環的複雑度(wikipedia)のことです。
複雑度が上がるとテストが難しくなっていきます。。
一番ありがちでわかりやすいパターンでいくと、遷移のパターンが多すぎるという問題です。。
図示してみた。。
飼い主と動物を表示するシステムです。。
矢印に機能名がついているのが、その画面とは関係ないことをやっていると考えてください。
ただの矢印は、遷移です。
複雑度が知らず知らず上がりがちなパターンを大袈裟に図示しました。
複雑化している箇所を言語化すると、
- 一覧画面に全機能を持たせている
- 編集画面に削除ボタンがある(削除のリクエストが投げれる)
- 詳細画面に削除ボタンがある(削除のリクエストが投げれる)
- 詳細画面で編集ができる
要するに、画面名と機能が一致していません。
さらに、機能が重複しすぎていてむかつきます。。
極端にシンプル化するとこうなります。
これが、一番デバッグしやすいです。。しかしユーザビリティは下がるような気がします。。
単機能なので、バグを生みづらいです。。
僕は楽なので、このパターンにしてくれると超助かります。。
もしくは、一覧画面に全機能を持たせるパターンもありな気がします。。
現実的にこれが一番多いのではないでしょうか。。
このパターンの場合、ダイアログを多用すると思いますが、、
ダイアログのフォーマットは統一してください。。
全ての動作にそれぞれフォーマットの違うダイアログがあると、恨まれます。。
凝縮度をあげたい
凝縮度 (wikipedia)
要約すると、任された機能のみにどれだけ集中できているかということです。。
凝縮度の観点からいくと、
この遷移はとても素晴らしいですね。。
さらに踏み込めば、動物の編集以外のことにも使えそうですね。。(飼い主の編集にも使える)
小結論
いずれにせよ、どちらかに絞ってもらえると非常に楽です。。
感情的な話
エンジニアが😡になるパターン
実装が無駄に複雑になった時、デザイナーの方に質問をしますが下記のような返答はしないでください。
エンジニア側が業務委託でデザイナー側が社員の場合、エンジニア側が折れることが多いですが。。
なんとなく、お洒落だから、モダンだから、、など
共通項は、主観しか入っていないことです。
何でもいいので、納得する理由を作っといて予防線を貼ってください。。
ユーザーの誤動作を防止するため、、通信環境が悪くてもイライラさせないため、、など
まとめ
シンプルな方がいいことの方が多いです。。
無駄を省けるかよく考えてください。。
あと対話してくれるとこちら側も非常に助かります。。。
シンプルと言えば。。
電車で例えると、、
切符買うのめんどくさいでしょ。。Suicaに満額チャージしておけば電車乗るの楽ちんじゃん。。
改札で残高足りないエラーが出たら、また満額チャージすれば問題起きないもん。。
テスラの自動車もタッチパネルデカくするより、シンプルな物理ぼたんの方が反応速度上がってたでしょ。。
と、、愚痴でした。。
Discussion