はじめまして、株式会社トラストバンクのスクラムチームでフロントエンドエンジニアをしている飯島です。
スクラムチームではスプリントという一定の期間を設けてその中で社内から上がってくる課題に対して要件定義・デザイン・実装を行なっていきます。
エンジニアも実装だけではなく要件定義・デザインから参加しますので、アドベントカレンダー6日目はエンジニアも知っておいた方が今後役立ちそうだなと感じたデザインについての話をしたいと思います！
グラフィカルなものだけがデザインではない
デザインというとどうしても綺麗な絵やイラスト、アートなどを思い描いてしまいがちですが、ここでいうデザインとは設計のことです。
UXデザインやUIデザインといった言葉がありますが、これらは絵を作ることがメインではなく、ユーザーの体験やユーザーが操作する画面を設計することがメインです。
なのでデザインは決してデザイナーだけでなく、ディレクターやエンジニアなど幅広い職種で役立つ知識だと思います！
これから自分が勉強した中で「今後役に立ちそうだな」と感じたものを少しだけ紹介します！
発見可能性
ユーザーがプロダクトを扱う際、それが何をするもので、どう動き、どんな操作が可能かを発見することが必要です。
それが発見可能性です。
発見可能性には5つの要素があり「アフォーダンス」「シグニファイア」「制約」「対応づけ」「フィードバック」からなります。
アフォーダンス
アフォーダンスは「ユーザーがどのようにプロダクトを扱うことができるかという関係」のことです。
webサイトでいえばユーザーはクリックやスライド、タイプや音声入力など様々な行動ができます。
そしてそれらの操作はユーザーの意思により行われるため、サービスを提供する側では制限することができませんし、基本的にはするべきではないです。
サービスをどう使うかはユーザーの自由だからです。
しかし、かといってサービスを提供する側としても意図した操作や行なって欲しくない行動などがあります。
それらをユーザーに促すためにシグニファイアを設置します。
シグニファイア
シグニファイアは「ユーザーに適切な行動を伝える知覚可能な全ての標識」のことです。
webサイトではボタンやリンク、マウスカーソルやテキストボックスなどありとあらゆる場面でユーザーに対して行動を促すものを設置しています。
開発を行う場合はユーザーにとってわかりやすいシグニファイアを設置しなければなりません。
シグニファイアがない場合ユーザーにとってどのようなことをすれば良いかの選択肢が多すぎて混乱してしてまい、強いストレスを与えることになります。
制約
制約は「ユーザーがとりうる行動を制限する」ものです。
ここでは「物理的制約」「文化的制約」「意味的制約」「論理的制約」について軽く触れていこうと思います。
物理的制約
言葉の通り物理的な制約です。
家の鍵などは違う鍵穴には刺さりませんし、刺さっても回して扉を開くことはできません。
これが物理的な制約になります。
webサイトでは「操作を行うボタンが存在しない」や「ページにたどり着くまでの同線がない」、「アラートで２択を選択させる」などが該当すると思います。
文化的制約
国や地域、宗教など個々人の文化的な制約です。
webサイトで例えると一番わかりやすいのは文字かもしれません。
日本人や日本からのアクセスには日本語を表示します。日本からのアクセスでも検索ワードが英語の場合は英語の記事も検索結果にヒットしてきます。
日本人が日本語で検索してアラビア語の記事がヒットしてもきっと読まないでしょう。
言葉だけでなく、同じ国でも収入や年齢、性別などによって文化的な常識が違います。
開発する際もユーザーの文化的な背景まで想像して行えると良いと思います。
意味的制約
意味的制約はその状況に対して何ができるかを制御するものです。
webサイトでも一般的に赤はエラー、黄色は注意、緑は成功などといったように色でどういった状況なのかを伝えることができます。
青文字で下線が引いてあるのはリンク、灰色のボタンは押すことができないなど意味的な制約はさまざまな箇所で使われます。
しかし、文化によって意味することが違う場合もあるため意味的な制約として何かを配置する際は注意が必要です。
スマートフォンなどではボタンが上下に設置されており、上が「戻る」下が「進む」を意味する場合があります。
しかし上が「進む」下が「戻る」というのが自然だという考え方もあり、配置以外で色を変えるなどの意味を与える必要もあります。
論理的制約
論理的な考えから導き出される制約です。
例えばジグソーパズルなどは決められたピース同士でしかはめることができません。無理矢理嵌め込むことができてもどこかで不整合が起き破綻してしまいます。
ゲームなどは論理的な制約を用いてユーザーを楽しませるものの代表かもしれません。
対応づけ
対応づけは「二つの要素同士の関係を繋ぎ合わせること」です。
webサイトの例ではスライドが分かりやすいかもしれません。
スライダーには「右へスライドさせるボタン」と「左にスライドさせるボタン」があり、下にはナビゲーションドットが存在しています。
これらを操作することでユーザーは右にスライドさせたいときは右のボタン。左にスライドさせたいときは左のボタンを押し、特定の場所までスライドさせたい場合はナビゲーションのドットをクリックします。
正しい対応づけとはユーザーに「この要素を操作したらどうなるか」という予想を与えられるものです。
もし右のボタンを押して左にスライドしたら？
ナビゲーションドットの２番目をクリックしたのに３番目のスライドまで移動してしまったら？
正しく対応づけできていない場合はユーザーに混乱と強いストレスを与えてしまいます。
フィードバック
フィードバックは「行為の結果を伝えること」です。
リンクを押してページ遷移することや、商品を購入して完了画面が表示されるなどユーザーが行った行為に対して結果を返すことを言います。
フィードバックはとても重要で、ユーザーに「なぜそうなった」のかや、「今どういう状態なのか」、「どうすれば解決するのか」を提供する際に役立ちます。
フィードバックは正しく優先順位付された情報を適切な量で伝えなければなりません。
よくある例ではエラー時に「〇〇ができませんでした。」というようなフィードバックを返すことがあります。
しかしユーザーにとっては「なぜできなかったのか」「どうすればできるようになるのか」といった情報が知りたいはずです。
なので「〇〇のため〇〇ができませんでした。〇〇をお試しください。」といったような「なぜ」と「どうなったか」と「どうすれば良いか」をユーザに伝える必要があります。
不十分なフィードバックはユーザーにとって混乱と苛立ちを与えてしまうので、正しく設計することが重要です。
概念モデル
概念モデルとは「きわめて簡素化された、あるものがどう動くかについての説明」です。
ユーザーにサービスや機能の概念モデルの構築を促すことによってより深く理解してもらえるようになります。
ふるさと納税で考えてみましょう。
「ふるさと納税ってよくわからないけどお得らしい」という人と「ふるさと納税は寄付した額が来年の税金から控除されてさらにお礼の品ももらえるからお得」という人では概念モデルでの理解度が大きく違い行動にも移しやすいと思います。
さらに言えば「寄付したお金は各自治体の公共事業に役立てられたり、生産者の助けにもなっている」という概念モデルの人がいるならば、上記の２つの例とは別の動機でふるさと納税を行なっているかもしれません。
エラーが起きた際に自分を責めてしまう
みなさんは普段色々なサービスを使っていると思いますが、エラーが起こった時や自分が思っていたのとは違う動きをした時に「自分の操作が悪かったんだ」といったように自分を責めてしまっていませんか？
多くの場合それは自分が悪いのではなく、システムとユーザーを繋ぐデザインに問題がある場合が多いです。
webサイトなどで電話番号入力時に「ハイフンを入れてください」あるいは「ハイフンを入れないでください」といったようなエラーに出会ったことはありませんか？
本来であれば入力箇所をハイフン区切りで分ける、ハイフンが入っていたらとるなどの処理を入れることで対応可能ですがそれをユーザー側で行うように強制しています。
しかし、「エラーが起きる」→「間違えてしまったんだ」→「間違えるのは恥ずかしいことだ」というような感じで自分を責めてしまう人が多いです。
自分が間違えてしまったということは他の人も同じように間違ってしまう可能性があるということなのでぜひ意見を言いましょう！
「ここが分かりずらい」「ここが想定していた動きと違う動きになった」などたくさんの指摘がサービスをより良くしていくと思います。
エラーの種類
サービスを利用する際いろいろな場面でエラーに遭遇することがあります。
入力間違いや必須項目の選択忘れ、他にもエラーとして何かしらのフィードバックはないが結果が自分の意図したものと違う場合など様々な場面でエラーは発生します。
エラーが起こる理由として「スリップ」と「ミステーク」の2つに大別することができます。
スリップ
スリップは「ゴールは正しいが必要な行為が適切に行われていない」状況で起こります。
基本的にはゴールに辿り着けないため、行為中に気がつくことができます。
スリップの中でも2つの原因が考えられ、それは「行為ベース」と「記憶ラプス」に分けられます。
行為ベース
行為ベースは言葉の通り間違った行為を行なってしまうことです。
これは使い慣れたサービスなどを操作する際に無意識に行なってしまう場合などです。
身近な例を挙げるとスマホなどでいつも使用しているアプリを起動させようとして、他のアプリをタップしてしまうなどです。
記憶ラプス
記憶ラプスは物忘れです。
物忘れによって必要な手順を飛ばすことでゴールに辿り着けないような状況です。
webサイトでは「必須入力の項目を入れ忘れて先に進もうとしても進めない」みたいな状況です。
上記のような例では大抵バリデーションによって自分が何を忘れているのかを思い出すことができます。
ミステーク
ミステークは「ゴールかプランが間違っている」状況で起こります。
ミステークも「ルールベース」「知識ベース」「記憶ラプス」の3つに原因分類することができます。
ルールベース
その名の通りルールが間違っている状況です。
ルール通りに正しく操作してもルールが間違っているので結局エラーになってしまいます。
この場合はルールを見直す必要があります。
知識ベース
記憶している知識が間違っている状況です。
こちらは正しい知識をアップデートする必要があります。
記憶ラプス
スリップと同じように物忘れが原因となるパターンです。
最後に
上手くまとめることが出来たかは相当怪しいですが１つでも「なるほど！」と思ってもらえるものがあれば幸いです。
今後スクラム開発のようにエンジニアが要件定義やデザインから入ることが増えるかもしれません。
そうなった時に今回書いたような内容は役に立つと思いますので興味があったら是非調べてみてください！
自分もまだまだ勉強頑張りたいと思います！
参考：誰のためのデザイン？