ITの隊長のブログ

ITの隊長のブログです。Rubyを使って仕事しています。最近も色々やっているお(^ω^ = ^ω^)

「UI/UXデザインの原則」を読んだ

スポンサードリンク

読書中のメモ

  • 使い勝手のよさ
  • ターゲットのニーズに沿った優れた体験価値を提供すること
  • 具体的な数字よりなぜ便利なのかを謳うべき
  • 詳しくなりすぎるのと考え方が偏ることで
  • ユーザーとのすれ違いが発生する
  • データだけみてても頭打ちしがち、仮説をたてて定性分析も併せて行う
  • 利用前と利用後も含めて体験をデザインする
  • ユーザーテストのシナリオ作成は機能を使ってみてくださいではだめ
  • ユーザーの善意や忖度に惑わされない
  • 素の心理や行動を汲み取る
  • 説明は常に不足していると考える
  • 認識されない要因は定型化してまとめてチェックする
  • 入力フォーム
    • エラーの場合は即時にフィードバックする
  • ネイティブの機能の承認可否?は説明の後に表示させる。事前許可ダイアログというらしい
  • アプリのチュートリアルや選択肢を制限したステップごとの案内が効果的
  • ユーザーが困っているリアルな姿を見てもらう

読書後の雑感

  • 入力フォーム周りのtipsはその通りだなーって思った
    • 即時にやっていないケースってこれまでいっぱいあったなって気持ち
    • ただ、JSのフレームワークやSPAを使ってからは即時に返すようになった気もする
  • GAだけでの分析や、ユーザーの善意や忖度に惑わされないのは本当そうだよなーって思う
    • 去年マーケティングの本とか読んでてもそんな話ばっか書いてあった
    • データだけで判断せずにデータをみてちゃんと仮説立てて、現場にみにいくとかユーザーテストしてもらうとか、実際に使っているところを確認する検証とかが必要
  • ユーザーテストのシナリオ作成は機能を使ってみてくださいではだめの話はなるほどなぁという気持ち
    • 機能を使ってくださいや細かく指示するのは自然じゃない。そうだよね確かに
    • ちょっと前にアンケートの設問は何について聞かれているのかを推測させないほうが良いアンケートみたいな話を聞いたことあったので近いかなって思った。いや?近いか?多分違うか
  • 説明は常に不足していると考えるの話も面白かった
    • 説明しているけど築いてもらっていないパターンが多いので、その点注意せよーみたいな気持ちになりました
  • 最後あたりは、部署でわけてやるんじゃなくて横串させてみんな一緒になってやるぞ!じゃないとちゃんとできない改善しない話はそうだなって思うんだけど、新規事業はまだしも既存の事業とかどうやって理解させたり導入していくんだろうっていうのはわからなかった
  • UXがまだふわーっとした理解。これは別書籍で補うことにする
  • ぼく、基本的なWebのUIとか理解してたつもりだったんだけど、調査するだけならともかく、サービスを体感してもらうところにもっと注力を置くべきだったと反省
  • もともとこの本を読もうとしたモチベーションってサービスをデザイン、具体的にするために使いやすいUI・画面を作りたいからだったので、振り返ってみて役に立った感はある。他社の事例とかをもっと知るともっと面白くなるのかなーって思いました