TL,DR

• Web Content Accessibility Guidelinesやニールセンのユーザビリティ10原則
• 暗中模索よりも仮説と実証、フィードバックを繰り返して手を動かす
• 量は質を超える

本文

動機

興味本位

どのように学んだか

courseraというMOOCsのサービスを利用して
UCSDのScott Klemmer氏のHuman-Centered Designの授業を受けた。

この授業は日本語字幕もあり、3 weeks となってはいるが
1回の講義が10~20分程度のものなので、比較的無理なく続けられる。
(と言っても私は3回目のチャンレジでやっと完走したが…)

以下学びのメモ

デザインのアプローチ

• ユーザが本当に必要なもの
• チームの認識を合わせるためのもの
• 画面に見えるものだけがデザインではない

チームの認識の齟齬に対してのアプローチ

私の環境では、
企画、営業、開発の3つの役割を持った組織が同じ製品をあつかっていても
認識が上手く合わせられず、要件や実装の手戻りが多発してしまっていた。
この解決方法としては、とにかく目に見えて動くものをつくり、
そのものを見ながらはなすべきである。

必要なのは、その場面では精度が必要なのか、
ざっくりとでも動くものが必要なのかを判断し、
できうる速度でものをつくり、そのものを見ながら関係者で認識を合わせる。
こうすることで、思い違いや勘違いなどを極力減らせる(はず)。

プロトタイプについて

本講義で印象に残った3つのプロトタイプについて記述しておく

Walter Dorwin Teague氏のBoeing社でのPrototyping

倉庫で飛行機のプロトタイプをつくり、実際に

• 旅行用の荷物を持った人を連れて体験のテストをした
• 大陸横断と同じ時間席に座るテスト
• 客室乗務員が食べ物などを運ぶ際テスト

このテストを行うことで、シートの快適さや、通路の幅、荷物の棚の大きさなど
あらゆる項目を確認することができた。

メモ

想像とやってみることは全然違うので、 想定されるペルソナや
利用する環境が決まっているなら、実際にそのユーザに、
その環境(もしくは限りなく近い状況)でサービスを利用してもらうべき。
呼び出して使い勝手を確認する方法も利点はあるが、可能であれば
実際に利用される環境で試す方がより正確なフィードバックが得られる。

Video Prototyping

例：https://www.youtube.com/watch?v=kWsBvUnvCmg

プロモーションビデオのようなもの

利点

ペーパープロトタイピングよりも素早く試行できる。
動かなくても良いところが良い。エンジニアは動画を見て、どのような機能があれば良いか 判断しやすくなる。工数的に大勢のサポートが必要な場合や、経営者や投資家などに
対するプレゼンとしても有効である。

Video Prototypingで必要なこと

・動機を説明する
・ゴールを説明する
・必要な作業を説明する

進め方

・概要、背景を演説する
・即興でやってもいい、ビデオで回しても良い

メモ

想像でシチュエーションを話し出すと
ある人は通学中であったり、ある人は授業中であったり、ある人は放課後であったり
認識がズレていることにさえ気づけない場合があるので大変効果的である。
関係者の想像に頼る部分を極力なくしていく方法としては
ベストに近い印象があるが実際はどうなのだろうか。

Paper Prototyping

私が在籍したチームや会社はやったことがないのだが、知り合いに聞く限り
よく利用されているテスト方式であり、ビデオプロトタイピングの次に認識を合わせやすい。

Paper Prototypingで気をつけること

• 素早くやり、再利用できるものをつくろう
• つくったものはまとめておく、壊れたりなくしたりしないようにする
• プログレスバーやinteractiveな状態をシュミレートも一旦書いてみよう
• 重要なところは太く、重要でないところは細く書こう
• スライディングウィンドウ・画面の深さを持たせよう

メモ

その他に、オズの魔法使いという方法もあった。
ペーパープロトタイピング実践するならやったことある人に教えを請いたい。

Parallel Prototyping

並行プロトタイピングはひとつのプロトタイピングを行うより合理的で経済的でおすすめとのこと

利点

• 平行で作っているもの同士を比較しフィードバックを得ることができる
• ビジネスの学習を2つ平行で学ぶと、双方を比較したり類似点を発見したりすることができ結果的に3倍の知識量になる
• 複数のものを共有すると敵対心がなくなる、意見が複数出てくる
• 複数つくることはボキャブラリーを生む

メモ 並行プロトタイプやりたいわ〜、無理矢理にでもやってみたいわこれ。

デザインの落とし込み

試行したものから得られるフィードバックについての注意点

エクストリームユーザに気をつけろ

質問と観察、観察、そして観察

エクストリームユーザ、リードユーザ

• 利用する大多数は中流なのだからトップのユーザではなく中流から始める
• トップは自意識過剰、保護する立場と権限を持っている
• リードユーザーは巧妙な解決策を思いつく、デザイナーはそのイマジネーションを参考にできるがマジョリティではない
• 電子メールの例でいうと、平均よりもメールを多く受け取っているユーザがエクストリームユーザである。
  
• 山奥で月に一度メールを受け取るユーザもそうだし、シリコンバレーのスタートアップのCEOのように
  毎日数千のメールを受け取っているユーザもそう、エクストリームユーザは実際のユーザではないことに気をつける。

質問

• ログから質問してもいい。この機能を使っていないようですがなぜですかなど？
• どれぐらい運動しますか？と聞いても被質問者は絶対多めに言ってくる
• より具体的に、より最新の新鮮な記憶に頼る質問をする
• 絶対尺度で聞くのをやめる。10のうちの7はどういうことですか？など

観察

• ある機能について知りたければ質問するな、観察しろ
• 質問をした後回答を待つ。その沈黙こそがお金、silence is golden
• 素早い回答よりも、2度目の沈黙後の回答の方が興味深い

メモ

絶対尺度で聞くのをやめるとか、それ満足度調査のことか。
そちらを学びたい。沈黙は金なりってのは本当にそうだよな。
インタビューについてはインタビューのノウハウがあるので必要になったら
都度学んでいきたい。

受講してみて

学びしかないが時間がかかる。
今回は日本語字幕もあったので英語の補完が可能であったが、
ネイティブ英語をひたすら聞く感じだと厳しいので
引き続き色々やっていきたい。

これから関わる話は今回学んだプロトタイプを適用できないか試していきたい。
並行プロトタイピングとビデオプロトタイピングはやっていきたいなー