00:00
♪
こんにちは出口です
こんにちは本山です
RE-SIZE.FMは
本山と出口が最近気になっているサービスやデザイントピックスを取り上げて
のんびり話すポッドキャストです
よろしくお願いします
お願いします
僕らはとんかつ好きじゃないですか
はい、とんかつ好きですよ
今日ちょっとたまたま銀座に昼間用事があって
あの前もてまさんに教えてもらった葛神に行ってきたんですよ
銀座葛神
そうなんかたまたまフラット入ったら一人でたまたま空いてて入れて
あ、あそこは予約なくても行けるんでしたっけ昼は
いやー結構なんか運良かった
バターかもしれないですたまたま一席だけ空いてて
で、あそこなんかコースのとんかつなんですよね。
そう、なんか僕はランチセットみたいなやつで、なんか4種類ぐらい、
4種類ぐらいコースで違うカツが出てくるんですよ。
だからなんか、なんていうの?
で、目の前でなんか、あの、いた前の人がこうあげてくれて、
で、なんか必ず2切れずつ、なんかこう目の前に出されるみたいな。
で、それ食べるみたいな。
カウンターの寿司屋みたいな感じ。
めちゃくちゃ美味しかったですよ。
ここ、僕、ずっと行きたいと思ってるところで、行けてないんですよ、僕は。
結構、一人でもしかして、ふらっと行くのを狙い目かもしれないです。
やっぱみんななんかカップルとか家族とかで予約してきてる雰囲気だったんで
まあそうだよね
でもここはねお昼も結構高めだしコースだし
まあまあまあ一番安いのに2,000円おやけになったかな
うん、まあでも結構それだったら安いね
まあなんか思ったよりはもっとするのかなと思ってたんだけど銀座だし
いやでも、なんかディナーにガッツリ予約してさ、行きたいなっていうのはあんじゃなくて
いやーめちゃくちゃ美味しかったんで、確かディナーは持っていいかもしれないですね
お店がなんかワインとマリオ味みたいな、なんかそういうコンセプトもなんか確かあって
だからなんかそういうお酒も一緒に楽しんでみたいなのを、ちょっとやりたいなってずっと思ってなかなか行けてないんだよね
なんか豚カツ以外のも美味しそうでした。なんかコロッケとか。
いやーでもなんか、全然ランチだけでもすごい楽しみましたよ。
いやーいいなー。行きたいなー。
油味ってこんな美味しいんだって思いました。
03:00
なんかね、油、なんか最後の方になんか二切れ出てくるんですけど、
同じ豚の、毎回その4種類、豚の種類が違ったりするんですよ。
部位とか、種類とかが。
で、最後だけ同じ部位、同じ種類で、
脂身がないものとあるものを食べ比べて出してくれるんですけど、
それを食べ比べてみると、脂ってこんなに美味しいんだって思いました。
うん、まあそうだね。
基本これは全部塩で食べる感じなの?
はい、塩とあとソースが2種類あって、
まあでも塩もおすすめですって感じなんですけど、
でも必ず最初に一口何もつけずに食べてみてくださいって言われて、
だからまず何もつけずに食べて、
これが本来の味かみたいなのを楽しんで、
うん、っていう感じですね。
何もつけずに食べろと。下味とかもついてないのかな?
多分ついてないと思いますね。
何もつけずにカツ、ちょっと浮き出てる肉汁を吸ってから食べてくださいって言われて。
いやなんか、ここのお店じゃなかったかもしれないけどね、
たまにこういうなんか肉汁がこう滲み出てくるようなトンカツっていうのを
なんかこう飲むトンカツっていう表現してやってるトンカツ屋があるんですけど
へー
なんかそういう感じだよね多分
あーでもそれは確かにわかるかもなんか
ほんとそういう感じでした
まずはすすってくださいって言ってラーメンみたいに
いやーいいなー行きたい行きたいなー
今日はラッキーでした
銀座いいですよね。いろんなとんかつ屋が、7種類もいいのがあって。
銀座とか、都内はね、本当にいっぱいあるし、
特に東京都でも、東側の方が美味しいとんかつ屋さんいっぱいあるから、いいなぁと思うね。
ここがダメでも、あそこ行こうみたいにできるんで。
そうそうそうそう。
ちょっとね、もう、もうなんか、1駅ぐらい離れれば、もうめちゃくちゃいっぱいあるからね。
そうそうそう いやーラッキーでした 今日
はい じゃあ今回はですね だいぶ前もだいぶちょっと時間空いちゃいましたね
なんかGoal Directed Designって アバートフェイスの話をだいぶ前
2週間3週間ぐらい前かなに2回続けてやってましたけど
うん
あれ割とまだ途中で 途中も途中というかまだ序盤というか本の中ではね
うん
で アバートフェイスの本自体は だいたい3パートあるんですよね
パート1 パート2 パート3って分かれてて
で パート3の部分が だいたい半分ぐらいを締めるんですよ
06:05
で そのパート3っていうのは結構デザイン なんかすごいUIデザインの
すごいパーツの細かいディテールの話を ずっと書いてるっていうようなもので
で パート2が1/4ぐらい パート1が1/4ぐらいで
で パート1が主に基本的な部分
ゴールディレクテッドデザインを学ぶっていう部分を解説してて
パート2が最終的に色々最初調査して ペルソナを作ったりとかってやってて
こうモヤモヤっとしたものを具体的な インタラクションデザインだとかUIデザインに落とし込むんだけど
この Part 1 では そこの どうやって落とし込むかっていう部分に あんまり細かく解説というか
こう 書いていなくて それを Part 2 で結構がっつり どんな感じ どういうことを考えて
その具体的なデザインに落とし込んでいかっていう部分を 細かく書いている部分が Part 2 なんですけど
その3週間前かな?にやってたのは まだ Part 1 の途中で ちょっと最後の部分の
パート1の最後の部分まで 今日は話そうかなっていうふうに思ってます
で まあ そのパート1で 前回まで話してたっていうのは
まあ そもそもゴールダイレクトデザインっていうのは 何なのかっていうか
どういう考え方なのかとか それになんか ちょっと付随して考える
その実装モデルとか脳内モデルの話とか
で まあ その基本的な部分を分かった上で
まあ 実際にユーザー調査っていう 調査 インタビューなどして
それを基に 仮想のターゲットユーザーというか
ものとして ペルスナーを作るっていうところまでが
前回までの話でしたね
で 今回は そのペルスナーっていうのを基に
また段階を置きながら 具体的なものに落とし込んでいくっていう部分の話なんですけど
まず そのペルスナーを基に 次に何を考えていったほうが良いのかっていう部分で
シナリオっていうのを考えようっていう部分が チャプター6 デザインの基礎っていう部分であるんですよね
具体的にはシナリオと要件って書いてあるんですけど 要件定義しようっていう部分ですね
その要件定義をするにあたって シナリオをまず書こうっていうふうに言ってるんですね
シナリオって最近 出口くん書いたりしてます?
シナリオは…
名字的に文章にするかは置いといても
でも やっぱり 何か サービスの設計するときとかは 頭には必ず描きますね
なるほどね
僕もね 最近行っても そんなにちゃんとシナリオを書いて みたいなこと あんまりできてないというか
そこまで時間が取れてないことが多いな というふうに思ってるんですよね
09:02
なかなかしっかり文章に落として チームメンバーに共有してみたいなことまでは
あんまりやれてないかもしれないですね
うん まあ なんとなくね 自分の中で イメージしてるものみたいなのはあるかもしれないですけど
そうですね
なんか それで止まっちゃってる部分は あるかなと思ってて
そもそも なんでシナリオを書くのかっていう部分なんですけど
やっぱりなんか この 実際にじゃあ ユーザー調査して
こういう課題を持ってる人が こういうゴールを持っててっていうのを
Personaを作ったんだけど
それをどういうふうに デザインに落としていくかっていう部分に
まあ ある程度 チームのみんなで 考えなきゃいけない部分だとか
まあ こう よりイメージしやすいものっていうのを
作っていかなきゃいけないんだけど
その上で まあ どういうふうにじゃあ その課題だとかゴールに向かって
そのユーザーが取り組んでいくのかっていうか
っていうのをイメージしやすいようにするために
いわゆる物語的なものに変えることによって
ストーリーテリング的なイメージを伝えるっていうのが
シナリオを書くっていう部分なんですよね
で なんでこの物語的なものにするのかっていう部分っていうのは
単にアプリとかサービスっていうのをどう使うかっていうことだけじゃなくて
例えばそのユーザーがどんな場面に直面しているのかとか、
なんかそこにどういう背景があるのかっていう、
なんか情景みたいなものも含まれるから、
その物語みたいなシナリオみたいなものを書くと、
他のメンバーに共有したり、なんか議論したりするときに、
まあすごく効果的だよねっていう話をしてるんですよね。
情景が結構大事ですよね。
そのコンテキストがちゃんと目に浮かぶように伝わるかみたいな。
なんか単純に課題をクリアするって言っても
なんかそれがどういう状況なのかとか
なんかさっきあの一番最初から言ってる
ゴールがどういうところにあるのかとかっていうのも含めて
なんかそういうサブ的な情報が
結構ねそのサービスの色というか
まあより良いものにするっていう部分に
必要になってくる部分なんですけど
それを落とし込めるツールとして
やっぱりシナリオみたいなものがあるっていう話を
してるんですよね
だからやっぱりシナリオを考える時も
シナリオを作るっていうところでも やっぱりそのなんだろう
その人間の行動のモチベーションが どこにあるのかというか
ゴールがどこにあるのかっていうのを意識して もちろん書く必要性はあるし
さっき言ったように 具体的に ただただ何々をしていく 何々をしていくっていうだけじゃなくて
そのなんか この人はどういう状況だから
今こういうふうなことをしようと考えていて こういうことをしているみたいなことを落とし込んでいくというか
よりその辺の描写を多分 小説化ばりにやっていくと
すごくイメージしやすくなるのかな というふうに思いますけど
あんまりそこに凝る必要性も もしかしたらないかもしれないですけど
そこはね
でも単純に何々をするとかっていう 書く 箇条書きで書いていくっていうよりも
12:04
もうちょっとその周り コンテキストみたいなものを落とし込んでいったもののほうが
やっぱりみんなイメージしやすくて いいよねっていうところですね
で なんか これ だいぶ前に 僕がクックパッドに勤めているときに
クックパッドのテック ブログってあったじゃないですか
今もあるのかな テックブログって
クックパッド デベロッパーズ ブログっていう 開発者ブログなんですけど
それで 昔 書いたことがあるもので
フェーズと目的に応じた プロレクタイピングの指法と意味っていうのを
僕は昔 エントリーとして 書いたことがあるんですけど
読んだ記憶があるかもしれないです
なんかそこで
僕はその
ある種
途中でシナリオライティングについても
書いてるんですけど
シナリオライティングっていうのも
ある種プロトタイプの一つの
手法なんじゃないかなって僕は思っている部分があって
要は
そのシナリオ自体も
まだ完全な
見た目としてのインターフェースなんていうのは
全くないわけだけど、考えるにあたってのあるし、一つのプロトタイピングの姿なのかなっていう。
そうですね。
どういう課題を持ってて、それをどうクリアしようとしてるのかっていうのを、なんとなくざっくり描いていくみたいな作業じゃないですか。シナリオを描くっていうのは。
だから結構そういう意味でシナリオを書くっていうのが一つのプロトタイピングの、すごく低レベルなプロトタイピングの手法で
まあなんか結構これ、なかなかね、実際に書くっていう話は後からまたしていくんですけど
なんか実際に書いていくとなかなか難しい部分も技術的な部分が実はあったりするんですけど
まあでもなんか、やっぱり言葉にしてみるっていうのはあるし、もう一番簡単な作業なんだけど
なんかそれもその一つのプロトタイピングであるっていうふうに考えていくと
もうちょっと気軽に取り入れていくっていうのも考えられるのかなっていうふうに思うんですよね
確かに
なんかあのアクティングアウトってあるじゃないですか
あれはまあシナリオをベースにして演技してみるっていうようなものだと思うんですけど
あれがある意味体験のプロトタイプだっていうふうに言ってる人とかもいますね
なるほどね
確かに 低レベルかつ 一番中小度が高い プロトタイプなのかもしれません
そうですね
で 実際にどういうふうにシナリオを 書いていくのっていう部分があるんですけど
ちょっと よくあるHCDの考え方って 構造化シナリオ法っていうのがあるんですけど
まあ ちょっとね ここ この AboutFace の中では まあ
構造化シナリオ法と まあ 似たような部分も重なってるので ちょっと合わせながら ちょっと話していこうかなと思うんですけど
15:03
構造化シナリオ法っていうのは なんかこう
アクティビティシナリオっていうものと インタラクションシナリオっていうのを 別々で書いていこうっていうようなもので
アクティビティシナリオっていうのは なんだろう
具体的な何かを操作するとかっていう話っていうよりは もうちょっと なんか
中傷化された 言葉で書かれたようなもの
具体的に検索窓をタップして キーボードで何々通り入力して検索ボタンを押すっていうようなことではなくて
何か探すだとか 検索するぐらいだったらいいのかもしれない
ちょっとその辺の具合っていうか 中傷度具合っていうのはあんまり明確に決まってるものじゃないんだけど
まあ そういう 具体的なアクションというよりは もうちょっと抽象化された行動レベルで 書いていくもの
何々を探すだとかっていうふうに
例えば 通勤途中に これが食べたいと思って クックパッドを開いてみてみたいな
その後 電車を乗りてスーパーに行くみたいな そういう感じの流れです
結構 アプリ自体のインタラクションをクリックするとか
何かどこどこタップするとかっていうのは置いといて
その周りにある時間だとか場所だとか
5WHHみたいなところを中心に書いていくようなものですかね
そうですね
アクティビティシナリオなんで
環境的にどういう状況なのかっていうことも もちろんこの辺には含まれるし
あと 例えば1日の中でサービスと接するポイントっていうのは
必ずしも1回じゃないかもしれないから そういう主要なポイントっていうのをいくつか書いていくみたいな そういうようなものですね
それに対してインタラクションシナリオっていうものがあって このインタラクションシナリオっていうのはさっき言ってた 具体的な操作みたいなものに入っていくようなものですね
で この本の中ではそれぞれ Activity Scenario は Context Scenario っていうふうに言ってて
Interaction Scenario は Keypass Scenario って 多分 ほぼほぼ同じようなことを言ってるんですよね
うん
それとは別になんか Check Scenario っていうのも この About Face の中では紹介されてるんですけど
まあ これはね 簡単に言うと レアケースとかエッジケースとか そういう細かい部分を詰めるための
もし こうなったら どうなる?みたいな質問をいっぱい並べていくみたいな そういうような感じのものですね
最後に詰めるためのものみたいな
なので 重要な部分は アクティビティシナリオの部分とか 実際にそれをどういうふうにインタラクションを落とし込んでいくのかっていう
インタラクションシナリオの部分だと思うんで チェックシナリオは 最後に詰めるために必要ぐらいの感じで考えとけばいいかなというふうに思いますけどね
18:01
うんうんうんうん
結構アクティビティシナリオ書くの難しいですよね
難しいですね
なんだろう、結構やっぱり
やっぱりさ、ユーザー調査とかしたりとか
まあ、ペルソナンもしかしたら作る場合もあるかもしれなくて
ペルソナンを作ったりとかしてるうちにさ
なんとなくこう、こういうなんか
もう具体的な機能としてさ
こういうものがあればいいのかなっていうのを
っていうのを なんとなく思い描いちゃいがちじゃないですか やっぱり
僕も多分 全然思い描いてると思うんですよね
だから やっぱり実際にじゃあアクティビティシナリオを 書いていくっていう段階で
なんとなく自分の中で思い描いてるものがあってさ
なんかそれに沿ってこう 書いてしまいがちというかさ
そういうとこがあったりして なかなか難しいんですよね
あと 僕もまあ その前の会社の時とか
ヒントアンスにアクティビティシナリオを書いてもらうとか
やってもらったことがあるんですけど
やっぱりなんか
インタクションシナリオとアクティビティシナリオを切り分けて考えるってのは
結構難しいんだなって
そのなんかUI的に綺麗なものが作れるぐらいスキルがある人でも
やっぱそこを切り分けて
ちゃんと体験のことにフォーカスして考えるってなかなか
訓練がいるんだなってのは見てて思いましたね
そうですね。ちなみに、ちょっと今いきなりシナリオの話に飛んじゃったんですけど、
このシナリオを考えていくにあたって、このアバウトフェイスの中ではまず、
まあ、ちょっと細かくいろいろあるんですけど、その前にブレインストーミングしろってステップとしてあるんですよ。
へー。
で、なんでブレインストーミングそこでするのっていうのがあるんですけど、
だいたいさっき言ったように調査とかしてるうちに
なんとなくこういうふうにこういうものを作ればいいのかなっていうのを
なんとなくみんな思い描くから
一回ブレインストーミングで全部吐き出せって言ってるんですよ
へーなるほどね
でも確かにそうかもな
なんかこうある程度正解を思い描いてやってしまうっていうのは
まあいい目もあるじゃないですか
なんかこうアウダクションじゃないけど
なんかこう正解をたどりたぐり寄せるじゃないけど
うん
でもなんかそういうのも含めて一回吐き出してみるっていうのは確かに大事かもしれないですね
うん そうだな
うん
そのなんかアクティビティシナリオを書くにあたってのなんかポイントみたいなところが書いてあって
うん
まあちょっと本書の中ではコンテキストシナリオを作成するっていう部分だったなと思うんですけど
うん
いわゆるサービスだとかデザインの部分っていうのを
魔法のブラックボックスとして扱って描いていくと
描きやすいんじゃないのっていうのを描いてみた気がしますね
なんか何でもやってくれるものみたいな
なんかそういうふうに捉えておくと
そこに対する具体的なインタラクションみたいなものを意識しないで
21:02
これやってってやったらやって返してくれるみたいなもの
として捉えられるようになるので
そうすると 本来の集中すべきところじゃない もともとあった根源的なゴールっていうところに
到達するためのシナリオっていうのが 書きやすくなるんじゃないのかっていうふうに書いてありましたね
確かに
さっき言ったアクティビティシナリオと インタラクションシナリオの切り分けみたいのを
強制的にやるために 一旦アプリの中身については ブラックボックスで考えるっていう感じですよね
そうそうそう
その辺ができると確かにアクティビティシナリオとかは書きやすくなるのかなっていうふうに
確かにこれは僕もミチキよくやるかもしれないですね
なんかこう、おてまさんもそうかもしれないけど結構
こうある程度プログラムとかも書いたりするから
なんかこういうものがどれぐらい大変なのかって分かったりするじゃないですかなんとなく
はいはいはい
だからそういうのはあえて考えなくするっていうことが必要になるじゃないですか
なんかこう制約かかんないようにするために頭の中で
だから一旦なんか実装する自分のことは一体忘れといて
もう完全に誰かがやってくれるだろうみたいな感じで
他人任せにした上でシナリオを書くってのは
無意識でやってるかもしれないですね
うん そうそうそう
で結構なんかこのアクティビティシナリオと
インタラクションシナリオを分けるっていうのは
他にもなんか重要な部分があるかなと思ってて
さっき言ったように 技術的に もしかしたら ものすごくハードルが高いとか
コースがものすごくかかってしまうっていう 可能性はあるわけですよね 考えてはみたけれども
そうなったときに インタラクションシナリオみたいなものしか 書いてなかったとしたら
全部巻き戻しになっちゃうわけですよね
全部ダメじゃんみたいな感じになって 一時からやり直すみたいなことになってしまうんだけど
そのアクティビティシナリオみたいな ある種 どう作るかとか 何を作るかっていう部分
具体的な部分に関しては ブラックボックスにしておくことで
後から差し替えられるようなものになるわけですね そこは
なので もう一回アクティビティシナリオンに立ち替えて
じゃあ ここはこういうのは無理だから
具体的にどういうふうに落とし込んでいこうっていうところに 立ち替えられるようになるっていう意味で
こう分けておくと いよいよっていうようなことですよね
なんか個人的にはこういう体験設計の手法って
いろんなものがたくさんあるけど
このアクティビティシナリオとインタラクションシナリオを切り分けて考えるみたいな考え方って
一番汎用的で何でも使えるし一番根幹なんじゃないかなって思ってますね
別にアプリとかサービスを作るっていう目的以外でも
やっぱりこのアクティビティシナリオって大事だと思うんですよね
なんかこうイベント企画するとか
うん
24:01
なんかこうね
飲み会を企画するかもしれないけど
そういうところでどういう体験をしてもらうかってことを考える上でも
やっぱアクティビティシナリオ的な考え方って大事だと思うし
結構サービス開発によらず使えるんじゃないかなと思ってますね
うん
結構ねなんかゴールディレクティブでもそうかもしれないけど
考え方的な部分がいっぱいあるじゃないですかやっぱり
そういうのは割と色々なことに汎用性が利くというか
使い回して考えることができそうだなというのが多いですよね
本当それはそう思いますね
営業のシナリオを考えるときとかもある意味でしょだと思うし
僕もたまに会社内でも話したりするんだけど
営業の人とかカスタマーサクセスの人とかそういった人にも
結構役立つ部分は 多いんじゃないかなって思ってますね
なるほどね
その次に だいたい それでシナリオ
シナリオもちろん 1回書いて終わりって話じゃなくて
書いて さっき言ったように みんなに共有したりとか
それをベースに議論したりして
いや ここ こんな行動しないでしょ みたいな話とかも含まれつつ
シナリオ自体で 磨き上げていくっていうか
プロタイピングの サイクルを回すっていうのを
やるっていう話の部分があるんですけど
うん
それがだいたい 仕上がってきたなってなってきたら
そこからいよいよ それをベースに
要件を定義していこうっていう部分に 入っていくんですね
うん
要件とは何かっていうのがあるんですけど
要件っていうのは イコール機能ではなくて
要件っていうのは イコールニーズっていうふうに言っていて
要は どういうものを作る
まあ 似てるんだけど どういうものを作るっていう 機能的な部分を要件として定義するんじゃなくて
どういうものが具体的に必要なのかっていう部分を 定義するのが要件定義だっていうふうに
まあ 書いていたような気がしますね この辺に関しては
>> 太田:うーん なるほど
>> めがる:なんか 具体的に 何が課題 要件として求められるかっていうのを
まず先に定義してから どういうふうに解決するのかっていう部分
インタラクションを考えていくのか アウトブットを考えていくのかっていうのを考えなきゃいけないんで
要件を定義していくんですけど
要件っていうのは
ここで要件っていうのは
どういう流度の話なんですかね
結構ね
結構ザクっとしてるんですけど
っていうのも
最終的には要件って
単純にユーザーの要件っていうのもあるんだけど
例えばクライアントの仕事をしてたら
クライアント先の企業側の
企業側の要件っていうのもあるだろうし、
はいはいはい。
その企業側の要件の中にも、ビジネス的な要件とか、
開発者的な要件とか、
まあ、いろいろあると思うんですよね。
ありますよね。
なので、結構ふわっとしてる部分は結構あるんですよ。
27:03
その要件っていう言葉の中に。
で、まあなんか、
それでもう要件を突き止めるっていう風に、
なんかサラッと書いてあるんですけど、
でもそれがそんなに詳しく
ほぼほぼインタラクションシナリオで
なんかもう浮かび上がってきてるだろうみたいな感じで
もうそこをひたすら落とし
一応なんかね 具体的に
こういうふうにやればよいよっていう
指法が書いてあるんですけど
だから結構インタラクションシナリオで
ほぼほぼ出来上がってるよねっていう
全体で書いてる部分が
なんかすごくあったかな ここは
たださっき言ったように
単純にユーザーがどうのっていうだけじゃなくて
そのビジネス的な部分だとか技術的な部分だとか
そのユーザー体験とか感情的な部分でどうなのかとか
まあ複数の制約っていうのを踏まえた上で
その要件を計当しなきゃいけないよねっていうとこが書いてありましたけどね
まあここはなんか一番難しいところかもしれないですね
なんかこう絶対にビジネス的な要件ってあるじゃないですか
なんか会社でやる以上
一番なんかというか、ドロドロしてくるところだと思ってて、
なんかこう、なんていうの、HCD的な綺麗な世界の考え方だけではできない部分があるじゃないですか。
まあでもそこはしょうがないよね。ビジネスだからね、そこは。ビジネスというか、欠かせないものだからね。
そうそう。で、そこのバランスを取るのって、本にはなかなかできない部分だと思ってて。
ただ、なんだろう、優先順位っていうのはあると思うんだよね。
ここが抜けたらもう無理だよねっていう 破綻するよねっていう部分はあると思うんで
それが最初のアクティビティシナリオを書く部分で 浮き彫りにできていれば問題ないと思うんですよね
これアクティビティシナリオをそもそも破綻してしまったら もうこのサービス破綻しますよねっていう部分だと思うんだから
そこである程度の優先順位っていうのが決まっていくと思うんですよね それを元にして
だからビジネス的にもうこの余計満たせなくなりますよっていうことが 言えるようにしましょうってことですよね
そうそうそう
っていうのがだいたいチャプター6のシナリオと要件っていう
調査してPersonaからシナリオを作って そこから要件を導き出すっていう部分の話ですね
次にもうその要件がだいたい決まりましたよねっていうところから 実際にどういう風にデザインとして
UIデザインとかっていうものとして落とし込んでいくのかっていう話に入ってくるんですけど
まあでも基本的にはなんだろう 簡単に言ってのはもうプロトタイピングしていこうねって話をしてて
ものすごく簡単に言って
要件からがしかし細かい部分をデザインして作っていくんじゃなくて
まずラフスケッチみたいなプロトタイプから始めようよっていう部分が
基本的な話ですね ここの話に関しては
そこはもういつの時代も変わらないんです
30:02
やっぱりこの時も単型のボックスみたいなのをいっぱい並べていくような、よくあるワイヤーフレーム的なプロトタイプとかから始めた方がいいよっていうふうに
これはもうよく言われてますけど、やっぱりリテールを細かく詰めていくとその分時間かかるっていうのもあるし、巻き戻しが入ったら大変っていうのもあるし
あと、それを見たときにその人が意見が言いづらくなってしまうんじゃないかとか、すごく頑張ってるのにもう否定できないとか
あと、指摘する焦点がディテールの方に行ってしまうんじゃないかとか、そういう話というところもあるから
そこは今 確認したいことは何かっていうのを考えるときに
もうちょっと根本的な情報構造の設計だとか
単純にアクセスしやすいかみたいな ユーザビリティー的な部分とかも含めて
考えるっていう意味では ワイヤーフレーム的なものでやったほうがいいよっていう話ですよね
この辺はよくある話なんで 多くの人はご存知かなって思いますけど
あれですね 時代を感じるのは そのためのツールとしては
Fireworksとか Microsoft VGOとか PowerPointがいいよって言ってますね
なんかここはちょっとね
そうだよね 僕がさっき言った 僕が書いたプロトタイピングの記事も
これも時代をすごく感じるなって思う部分があるんですけど
結構なんだろう アフタートークとかも含めて
なんかこの Resize.fm で何度かどういうふうなプロトタイピングをしてたかみたいな話を
たまにしてたかなと思うんですけど
僕の中にも結構流行りしたりみたいなのがあってですね このプロトタイピングには
一時期は鉛筆で本当に紙に鉛筆で描くみたいなことをやってた時もあったし
あとなんか筆ペンで描くっていうのをやってたこともあったし
なんで筆ペンなのかっていうと、基本的には太い線なのであんまり細かく描けないんだけど
ものすごく頑張ると筆先で細かいものが描けるっていう
そういう制約を持ったツールだから それを使ってたっていう部分
強弱をつけられるっていうことですね
そうそうそう
なんかでも基本的に太い線だから あんまり細かい部分は基本的には書けない
だけどここだけは重要っていう部分には 細かいところを書ける
そういうものとして筆ペンを使ってたりとか
あと僕が結構長く使ってたのはホワイトボードで
ホワイトボードって言っても 立てかけてるようなものじゃなくて
手元に置いとけるような B4かA3 大きくてもA3ぐらいのホワイトボードっていうのをすごく使ってた時期が長くあったんですけど
33:11
ホワイトボードもペンの種類によるんですけどもちろん 基本的にペンが太いんですよね ホワイトボードって
だからあんまり細かく書き込むことができない
かつ、僕として好みで使ってたのは、簡単に消せるというかさ
筆ペンはまず消せないっていうね、こう、欠点があったんですけど
で、鉛筆にしても消しゴム使わなきゃいけないっていう欠点があって
それがね、ちょっと嫌だなっていうか、消しゴムのカス出てきたりしちゃダメだなみたいなのがあったんですけど
ホワイトボードにすると、こう、指でも下手したら消せるし
なんかもう ストレスなく バババって 書いて消して 書いて消してってのをやっていけるみたいな
っていうのが 結構ホワイトボードを すごく使ってた時期が長かったんですけどね 僕の中で
僕も 多分モテますに影響されて NewBoardっていうホワイトボード持ち運びのやつ
よく使ってましたね 一時期
大体そのうち大事だろうと思って 取っとく
こう…なんていうの エリアが
アルコールが飛んで固まって消えなくなるっていう
あるある あるある
だからそれに気づいてから書いて これは重要だと思ったら
iPhoneで取って残しとくっていうのを やってた時もありましたけどね
でも ホワイトボードは やっぱり単純にワイヤーフレームみたいなもの
ラフスケッチみたいなものを描くっていうだけじゃなくて
思考するためのツールというか
うん
結構いろいろ何でも使えるじゃないですか
そういう意味でも すごい持ち歩いてた時期があったな
そうですね
唯一制約としては 制約というか枠があるというか
当たり前なんだけど
そうね 制限がね
制限があるじゃないですか
領域的な制限
B4だったらB4みたいな制限があるんで
僕はそこが僕をもどかしく感じて
その後でiPadを使うようになりましたね
僕もだからそれを感じた部分もあったから
iPadを使うようになって色々アプリを試した結果
全てなかなか気に入らなかったので
自分たちでiPadアプリを作るっていう
パトルスケッチっていうアプリがあって 今もう無料で公開してるんですけど
ずっと無料だったけどね 本当は
そういう経験が
これはだから そうそう
ホワイトボード的に一応書いて 指で消せて
領域的な制限がほぼ無限っていうようなものを実現したもので
そうっすよね
やっぱりラフスケッチとかアイデアスケッチみたいなものっていうのを
36:02
ここでやるっていうのを実現するっていうのを全体に考えてたから
かなり機能数が減って
普通のいわゆるお絵かけアプリみたいなものに比べると
かなり機能を限定して作っているんですよね
ペンの種類とかも含めて色も含めて
でもそこは僕はあえてそのふうにやって拘っている部分で作ってたところはありますね
なんかね、なんかピザ屋でもたやまさんに
こういう領域無限のホワイトバッドアプリが欲しいから
っていう話をした覚えがありますね
ありますね
まあなんか他にもね色々あったんですけどね
なかなかこう一番これに適してるってものがなかったりとか
なんかこうインターフェースが微妙だったりとかっていうのがあって
それで確か作った覚えがありますね
あとApple Pencilがちょうど出てきたっていうのもありましたよね タイミングとしては
なんだかんだスケッチでのプロタイプってのは ずっとやってるかもしれないですね ツールは違って
そうだね 結局だから僕も最終的にホワイトボードの機会はなかったけど
それやっぱりホワイトボード持ち歩くのも大変だし
さっき言ったように 保存しておくことが なかなか難しいっていう問題とかもあったから
結局 結果的に iPad アプリみたいなもとに
ホワイトボードをそのまま iPad アプリにしていくみたいなところに落ち着いていった
で それを使ってるってとこありますね やっぱり
あとはもうちょっと Hi-Fi なプロタイプになってくと
昔だとキーノート使ったりとかもありますよね
いやね これ そうですね
いやなんかもてあまさん一時期 キーノートにめっちゃハマってたよなっていうのを覚えてて
はい
いやなんかちょうどねこの頃まだ フリントとかの時代なんですよね
あのそのいわゆるまあアプリとか スマートフォンアプリとかのその画面繊維とかっていうのを伴う
なんかまあただのパラパラのなんていうの パラパラアニメ的になんかできるそのプロトタイプツール的なもの
紙芝居方式のツールですよね
そう そう そう そう そう
で、フリントとかがある、ようやくあるくらいの時代だったんですけど
だからその前っていうのは、本当に何もなかったんですよね
本当に、本当になんか、切り替えていくくらいの感じでさ
画像をいっぱい用意して切り替えていくだけって言ったようなこう
2014年とかそれぐらいかな、13、14年ぐらいですよね多分
うん
まあでもなんか多分ね、そのぐらいの時、まだフリントとかないぐらいの時から、僕はなんかだから、結構HTMLとかで
そのなんかモックを作るみたいなことをよくや、たまにやってたんですけど、本当に必要だなって思った時は
もう簡単にHTMLとCSSとJSで、もうさっき言ったように画像を切り貼りしてこう、なんか自分でコードを書いて作るみたいなインタラクションのモックみたいなものを
39:10
そういうのをやったりとか
あとやっぱりフリントはさっき言ったように紙芝居方式で
細かいインタラクションっていうか
なんかなんて言うんですかね
単純に画面繊維だけで表現しきれない
細かなモーションだとかアニメーションっていうのを
どうやったら作れるだろうかっていうのを考えた時に
キーノートを使うとキーノートにはなんだっけ
マジックアニメーションみたいな、スムースアニメーションみたいな。
マジックムーブ?
マジックムーブか。
そういう繊維のさせ方っていうのができて、
そのマジックムーブっていうのは、
同じ共通の要素が次のスライドにあれば、
その次のスライドを動かした位置に、
きれいにこう、ムニュミニュってアニメーションして動いてくれるっていうような、
もともとはもちろんスライドのための機能なんだけど、
それを利用して インタラクションモック的なものを作るっていうのを
頑張ってやった時もありましたね
インタラクションモックっていうとこまでいかないから なかなか
ほぼほぼアニメーションモックのモックというか
イメージを伝えるようなものっていうような感じでしたけど
いや なんか 本山さんがすげえKeynote頑張ってやってるのを
見た覚えがありますね 当時
いや でもKeynoteは実際そんなに僕は使ってなくて
試しに これでやれる やれそうだなっていうのに気づいたから
ちょっと頑張ってやってみた時期があったんだけど
めちゃめちゃ頑張んないとできないってことに気づいたから その後半端やってないんですけど
一時期だったんですね
だから この僕が書いた記事にも
例として お出かけサービスホリディの iOSアプリの
実際に動かしたときの動画っていうのがあるんですけど
もうここまで頑張ったのはこれしかないですね
そうだったんだ
まあ今だったらねいろんなツールがあるから
そうなんだよね楽になったよね
まあそれこそFigma上でねちゃちゃっとできちゃうわけで
そのさっき言ったキーノートのマジックムーブ的なものもできちゃうし
デザインつるとそこが完全に結合一緒になったっていうのは結構大きいですよね
大きいですね
以前は別にね
なんかもうそういうのもあって
なんか結構いきなりFigmaでやってしまいがちみたいなところも最近よくあるなっていうふうにも思ってて
別にそれが一概に悪いっていう話ではないんだけど
なんかちゃんとこう昔の低レベルのレイヤーから考えていくっていうのが
もしかしたらちゃんとできてないのかなって思うところはありますよね
42:00
確かに最近のデザインシステムとかあって
なんかもう作られたコンポーネントがもうすでにあったりして
それをじゃあ組み合わせていくみたいなデザインのやり方を取っていくこともあると思うから
あえてテレビにもう一回立ち帰って考えるっていうのは
なんかちゃんとやろうと思わないとやらないかもしれないですね
うん まあ 全部ね ステップを追ってやらなきゃいけないってことは全然ないと思うけど
とはいえなんか まあ 一つのやり方として その昔にやってたようなやり方っていうのも
まあ ある種 差差があるものなのかなっていうふうに思うところありますよね
ちなみになんか そのインタクションを考えていくにあたって そのこの本の中では
その製品っていうものが どういうふうに 振る舞うべきかっていう話もしてて
うんうんうん
簡単に言うと 知了深い人間のように 振る舞わせろっていうふうに言ってるんですよね
(笑) なるほど
これは単純にシステム的な応答をするような ものにするなっていうのを言いたいだろうと思うんですけど
はいはいはい
だから そのサービスとかアプリなりが
本当にそのサービスとかアプリが 人間だとして
それがその人間がそのユーザーのことを 本当に思った人間だったとしたら
どういうふうに対応するんだろう っていうふうに考えなさいって言ってるんですよね
結構この辺って だいぶ前にやった UX ライティングとかにも近い話だなって思って読んでましたけど
なんか乱暴にエラーアラートを出すな みたいなことですよね
そうですね ちゃんとコンテキストを理解した上で
振る舞いっていう話ですよね
そうそうそう
で、なんかこう、なんか言うにしても
その一歩先とか二歩先とかっていうのを考えた上で
ユーザーに対してこう言うとか提示するっていうのをしないと
した方が、本当は本当に優しい人間だったらそうするよねっていう
そういう話ですね
まあなかなかね、それをじゃあどうやるのかっていうのが
大変なところではあると思うんですけど
でもそこは案外イメージしたらいけるんじゃないですかね
うん
それこそさっき言ったアクティングアウトみたいな手法はこういうとこに効くと思うんですよね
まあそうですね
多分、経験を重ねてればそれが染み付いてるからそんなに大変じゃないんだけど
やっぱりそこにその状態になるまでにアクティングアウトとかアクティビティシナリオとか
インタラクションシナリオみたいな
まああえてそういう制約を課した上でシナリオについて考えていくっていうことが大事なのかもしれないですね
いやなんかアクティングアウトもさ単純にユーザー側のアクトっていうかアクションをするっていうだけじゃなくてさシステム側をするっていうのもあるじゃないですか
システムが別に人間がアクションするわけだけど、システムになりきる必要性はなくて、人間として多分アクションすればいいわけですよ。
45:01
そうなったときに、普通にやろうとしたら多分人間的な答えをすると思うんですよね、アクションとして。
それってある種 資料深い人間のようになったシステムのものの姿になるのかもしれないなっていうふうに
僕 ククパト時代に サマーインターンの講師をやったときに
中間発表としてアクティングアウトをやってみたことがあるんですよ
学生の参加者の人たちに こうやってくださいってお願いして
で、なんかそれをやったのは結構、それをやる前までって結構よく、まあクックパッドだとEOGSとかなんかそういうフレームワークに文章として落としてそれを発表してもらうみたいなやり方をやってたんだけど
それって結構理解する側にとっても結構大変で、こういきなりアプリの企画を即座に理解してフィードバック開発みたいなのって結構大変でしんどいなぁと思ってたんで
なんかそこでアクティングアウトっていう形で 寸劇方式で発表してもらって
それを見てフィードバックするみたいな やり方に変えてみたんですよ
でやっぱそう変えると見てる側っていうか 見てる側も結構理解が楽で
より本質的なフィードバック返しやすいっていうのがあるから
やっぱこうチームメンバーとか 例えば僕が同じ開発メンバーだったとしても
やっぱりより理解しやすいやり方で周りに伝えるっていうのは
周りへのコミュニケーションとしても大事だろうなとは思いましたね
そうだよね
もちろんそれをやったことによって自分が考える要素っていうのが生まれてくるところもあるだろうし
やっぱりそれを見た人たちもやるしね
それはやってみてすごい思いましたね
前までフレームワークに書かせるっていうことをやってると書くことが目的になってくるんで
なんかこうフィードバックもすごい大変なんですよ
なんだけど、Acting outをやってみてっていうと、自分で激するから、あれこれちょっと不自然だなっていうふうになってきて、
自分で直していくっていうことが自然に生まれてくっていう意味で、いいやり方だなと思いましたね、このActing outっていうのは。
UX writingの時もそういう話を確かしましたよね。
なんかそのなんだろう単純にこう例えばよくあるホームのエラーが出た時になんか
何々が間違ってますって言うんじゃなくて普通の受付の人だったら何々が間違ってますって言うだけでぶっ切ら棒に言うはずがないって
いうふうに思うんですけどそこがだからさっきみたいにアクティングアウトみたいな形で実際に人が対応するとどうなるのかっていうのを体験すると
これは変だなってふうに思う部分だと思うんですよねそこが
そういう効果みたいなのがありますよね やっぱり
うん ありますね
結構一人でデザインするときも
一人でマスン撃するのはあれだけど
実際頭の中にそういうのは 情景を描いてみるっていうのは
48:02
大事だと思いますね
まあなんか アプリとかサービスみたいなものを
自分で考えるときもあれですけど
アプリとかサービスっていうものを システムとして考えるんじゃなくて
一人の何か擬人化された人
すごく身近な人でもいいと思うんですけど、母親とか
そういうものとして考えておくと、結構
なんか全然考え方が変わってくるっていう部分も もしかしたらあるかもしれないですね
確かに
友達とかでもいいかもしれないし
なんかこれ職業病かもしれないけど
なんかそれをやるのが結構 癖になってるところってあると思うんですよ
僕らみたいな仕事をしてると
だからこうたまに行政系のシステムとか使うと
必要以上にイライラしてしまうっていうのが結構あるなって
なんでここでこんなアラートを見たいな
特にね最近のアプリケーションとかは結構そういうライティングとかにこだわっているアプリも多いからね
そういうのに慣れていくと余計になんかそういうイライラするところがあるんでしょうねやっぱり
全格価なで入力してくださいと怒られる
知らねえよっていうのは
いやお前がやれよっていう風に思っちゃいます
そういうのあるなぁ まぁあとね一応なんかこれすごく余談ぐらいの感じなんですけど
ビジュアルデザインフレームワークっていうのを考えるっていうなんかステップもあるんですけど
これ何かっていうと なんかインタラクションとか具体的なインターフェースのコンポーネントとかっていう話ではなくて
見た目とかスタイルとか色ぐらいの感じのブランドとか印象に関わる部分を定義するっていうのを
別でやろうねっていう話をしてて
へぇーなるほど
これももちろんだからユーザーとかのゴールに沿って決めなきゃいけないよっていう話をしてるんですけど
これを別でやってて後でガッチャンコして最終的なアウトプットにしていこうねっていう話をしてましたね
なるほどなるほど
これも一緒にやっちゃうと巻き戻しがどんどん多くなっちゃうから
別で考えようねって話だと思うんですけど
うんうんうんうんうん
でもなんかね、一つこの辺の話で面白かったのは
結構こういう感覚的な部分って
やっぱりなかなか人数が多いほど
ステゴロラが多いほど一致しないじゃないですか
うんうんうん
なんか俺はこっちの方が好きだなみたいな
そういう話になりがちで
だからこう、なんか選択肢として
できるだけ極端なオプションみたいなものを用意した方が
まあこう
このゴールだったらこっちだよねっていうふうな選択に
適切な方向に向かいやすくできますよっていうような話が書いてありましたね
うん
うんうんうん
で これなんか
なんだろう よくデザインの提案
そのまあ 単純にインタラクションとか
UIデザインの話だけじゃなくて
例えば ロゴのデザインとか
ブランディングのデザインみたいな
51:01
パッケージのデザインとかそういうので色々やったりするときに 複数案出すっていうのはよくやったりするんですけど
このボツ案を入れるなって言ってて絶対に
ボツ案入れて誘導 こっちの方がいいよねって誘導するっていうのもたまにやったり 僕もしたことあったんですけど
このボツ案を入れるなってこの人は言ってて なんでかっていうと自分が満足してないデザインを出して
それをもしステークホルダーが気に入っちゃったらどうするのっていう
その可能性もあるから少なくとも自分はある程度納得がいっているものを作って
それも選択肢に入れろっていうふうに書いてありましたね
なんでそんなことまで書いてあるんだろうと思いましたけど
なるほどね
僕クライアントワークやったことが少ないんでそういうのは経験がないんですけど
やっぱ 持山さんもやることあるんですね
結構ありますよ 普通にやってるとありますね
なんかいきなりこれだけでしょみたいな案にすることも もちろんありますけど
ある程度やっぱり参加してもらうって重要だと思うんですよ 決めていくにあたって
ステークホルダーの人が
その納得感みたいなところに繋がったりするし
もちろん適切な意見をしてくれることもあるので
それが実際に新しいデザインの愛やというか
そっちに繋がっていくというか
単純にA案とB案があります どっちにしますかってだけでは話しなくて
A案のここはいいけどB案のここもいいよねみたいなところで
じゃあここを合わせましょうかみたいな
そういうふうにも繋がったりするので
そういう意味では複数案出すってのはよくやりますね
それってロゴ以外にこう UI とかでもやったりするんですか?
Ui でやることはどうかな?
UI で複数の案を出すっていうのは あんまりないかもなぁ
そうっすよね
結構まあ ロゴとかあるいはブランドを
CFやりたいなところの話なのかな?
そうだね
まあ 複数案 UI で複数案出して どっちか選べっていうのは
感覚的に決められるようなもの じゃないと思うんですよ
そうですよね
どっちかっていうと それこそ この後の話で
ユーザビリティテストとか そういうときに出すとかっていうのは
全然あると思うんですけど
だけど複数こういうUIとこういう UIがあって どっちがいいですかねみたいなのは
あんまりやんないよね
まあ そうですよね
そこはまあ普通にこっちはこういう メリットデメリットがあってこっちはこうでこうでみたいな
でまあゴールに従うんだったら絶対こっちの方がいいよねっていう風になってくることの方が多いから
でまあそれで一回出してみてダメならこっちに変えましょうみたいなその感じですね
そうそうそう だからあんまりそうだね
54:00
どっちかっていうとやっぱりそのビジュアルデザイン的な方面の話
うんうんうん
なるほど 最終的に そのビジュアルデザインの イメージ的な部分と
インタラクションで なんとなく作ってきた部分
細かい部分置いといて フレームワーク的に 作ってきた部分を合体させて
実際の細かい部分を作りましょうね っていうところまでですね ここは
そこを具体的にやっていくっていう話は またパート2の部分に入っていくんですけど
その後に若干さっき言ってた ユーザビリティテストの話が
ここはあんまり そんな細かく書いてないんですけど
さらっと書いてあって
うん
だから ここでもね
ほとんどユーザビリテストの話が 書いてあったんですけど
一応なんかフィードバックテスト的なものも あるのかなっていうふうに思うんですよね
ユーザビリティっていうと 単純に使いやすさ的な部分だとか
うん
ちゃんと使い方が分かってもらえるかっていう部分のテストだと思うんですよね
うんうんうん
ただそれ以前にちゃんとこれが機能するのかみたいなテストみたいなのも
もしかしたらあるかなっていうふうには思うから
はいはい
そういうのも本当は挟んだりするんだろうなっていうふうには思ったんですけど
このAboutFace上ではそんなに書いてなくても
ガッツリユーザー調査して ペルソナ作ったから
AROぐらいの感じで 書いてあるのかなと思いました
結構そうなんだ
そんなこともないかなと思ったけど
結構ユーザーテストは薄いんですね 意外ですね そこは
うーん なんか
読んだ感じ 今パート1だけですけど
読んだ感じでは
なんかユーザビリティテストは いろいろ細かく書いてあったけど
いわゆる具体的なユーザーテスト的な部分は あんまり書いてなかったなと思って
なんか意外ですね 結構なんていうか
前半は重厚にやってた そのPersonaスクールあたりまでは
結構重厚にやってた印象だったんだけど
うーん そうそうそうそう
なんかここで またユーザーには立ち帰らないんだと思って
うーん それはちょっと意外ですね
まあでも本来ならでもそういうのを入れてった方がいいとは思いますよねやっぱり
うん
まあそうですよね
細かくテストしていった方がいいですよね
結構さっきの僕が書いたブログに立ち帰りますけど
場合によってはなんかこう
この辺の今まで話してきたペルスナーだなんだっていうのを
ペルスナーは まぁ入ってるのかな シナリオだなんだみたいなのを軽くして吹っ飛ばして
探索的テストみたいなことをやったっていうのも 結構クックパッド自体は何回かあったりして
はいはいはいはい
なんか これ使えそうかなみたいなぐらいのレベルで
57:03
エンジニアが軽くモックなり 実際に動くものみたいなものを作ってみて
どう感じるのかみたいなものを テストするみたいな
そういうのも結構クックパッド自体は よくやってましたよね
クックパッドはどっちかというと そういう文化ですよね
重厚に調査してみたいなことやるっていうよりは
軽くまずはプロトタイプ作ってみてみたいな
なんなら本番環境に出してみてみたいな
確かに テスト的に一部のユーザーに出したりとか
限定公開でね やったりとか よくしてましたよね
まあクックパッドの場合は 若干特殊なのかもしれないですけどね
ある程度もう本サービスというかさ ある程度柱があって
その上で改善していくっていう部分もあったし
もちろん体力的にもね 会社の体力的にもすごく
余裕がある感じであったから そういうのができてたっていう部分は
たくさんあると思うんですけど
まあ 前提6000万人とか ユーザーがいる上でやってたことだから
まあ なんかね 限定ユーザーしても ある程度のボリュームのユーザーがいたっていうのは あったりしますよね
うん
まあ だから テストっていっても やっぱり なんか いろいろ その探索的なテストなのか
まあ いわゆるユーザーテスト フィードバックをもらうようなテストなのか
それともなんか こう ユーザビリティテスト的な もうちょっと使い方に関するものなのかっていうふうに
いくつかあるので そこ辺はうまく使い分けるって感じなのかなって思いましたね
僕も昔 オクパッドのテックライフブログに記事書いたなって思い出したんだけど
データドリブンでユーザー体験を改善する試みっていう記事を昔書いていて
これが まさにテストの話を書いてて
なんかこうアクティビティシナリオを数値に落としてテストで実際にリリースして数値改善していくみたいなことをやってましたね
ツールとしてはMixpanelを使ったりしてやったりしてましたね
結構この頃、この頃というか今もちろんMixpanel全然使ってたりしますけど
この記事にも書いてありますけど
よくあるA/Bテストみたいな
点だけで考えるじゃなくて
実際にどういうふうにユーザーが行動していって
それが改善できているのかっていうのを見る
ファネルとか分析の方法としては
ファネル分析みたいに言ったりしますけど
そういうものを手助けするツールとしての
解析ツールとしては
ミックスファネルみたいなものが
結構よく使われてましたよね
そうですね やっぱ大事なのは デザインするときもそうだし
その後のテストするときにも このアクティビティシナリオが
どこでも効いてくるってのが すごく潰しが効くというか
1:00:03
スパがいいというか 主法だなって思いますね
その具体的にどういうふうに 作ったら
どういうふうに触っていくのかっていう部分を
さっき言ったように ブラックボックスにしておくことによって
そこをガチャガチャ変えていけるっていうところですよね
そうですね。
やっぱりそのシナリオベースで
デザインも実装もテストもしていくことで
全体としてブレない統一感が出てくるっていうのもありますよね。
そうだね。
ようやくこれでアバウトフェイスの4分の1が
終了しまして。
まあね、ちょっとね、さすがにこの最後のパート3の細かいインタラクションというか、コンポーネントの話?
本当に、なんていうの、エラーダイアログとか、メニューとか、そういうレベルのものなんで
そこに関しては結構やっぱり、まあこの本自体が古いっていうのもあって
まあ、あんまり、なんだもう、読んでもしょうがないってことはないけど
趣味的に読むぐらいでいいんじゃないの?ぐらいの感じの部分が、まあほとんど大半なんだけど
でも ただ パート2に関しては もうちょっとさっき言ったように
だいぶ最後 スッ飛ばしたじゃないですか
要件定義して デザインを起こし回す みたいなところまで
あの辺に対する考え方みたいな部分が
確かここら辺 書いてあった気がするので パート2は
その辺はもうちょっと 読んでもいいのかなって思ってますけどね
そうですね またちょっと別の回でやっていきたいですね
まあ やっぱ パート1なんていうか さらっと 本場では流されてるけど すごく深い話ってのが結構あるから
なんか やっぱりモデルダクサーになりますね 喋ると
うん そうだね
パート2はもうちょっと考え方とか そういうところがメインになってくるような気がしたので 確かに
環境の話っていうか 結構昔のやつなんで
ウェブとかそういうのが 中心だった気がしますけど
その辺もちょっと 全部は話さないかもしれないですけど
ピックアップしつつ話すと 良いのかなって思ってますね
じゃあ Powered Face Part 1は 以上で終了っていうことで楽しいですか?
はい お疲れさまでした
お疲れさまでした
リサイズヘムへのご質問やご感想リクエストなどは #リサイズヘムでTwitterにつぶやくか
ショウガオートにあるお便りのリンクから送っていただければ 配信内で取り上げたりしますので
どしどしいただければと思います
リサイズヘムは毎週金曜日に配信しています
Spotify、iTunesのPodcast、Google Podcast、YouTubeなどで配信していますので
よかったらチェックしてみてください
ということで今回はここまでまた次回お会いしましょう
さようなら
さようなら
♪~
1:03:09
ご視聴ありがとうございました!
