Amazonが以下のブログで新しいAlexaのDesign Guideを発表した。これはSituational Designと呼ばれる。
とりあえず公開されている情報から自分なりを理解をまとめてみる。

今まで音声インタフェースの設計は graph-based な手法でやっていた。以下の図のようなやつ。

いわゆる Happy Path と呼ばれるユーザーとのやりとりが上手くいくパターンだけを記述するならこれでも表現できるが、実際にはユーザーから予想外のことを言われたりだとか、そもそも音声アシスタントが認識ミスをするなどの理由でうまくいかないことは必ずある。

うまくいかなかった時にどうするかは考慮しなければならないが、上記の graph-based な手法ではパスが複雑になりすぎるし、なんらかの修正のたびに壊れやすくなってしまう。

これを解決するために frame-based な手法であるSituational Designが導入された。具体的なのは以下のリポジトリにまとめられている。

上記リポジトリより引用

Situational Design では上記のテンプレートを組み合わせて会話のフローを設計していく。

テンプレートには「ユーザーからの発話」「会話のシチュエーション」「Alexaの返す発話」などを記入する。これらはまとめて会話の turn と呼称されている。

これを一通り作成したら、会話の開始から時間軸に沿って会話の終了まで横一直線に並べていく。

この時 graph-based な手法のように分岐は作らない。一直線の会話のやりとりだけを Storyboard として表現する。

公式ドキュメントより引用

分岐は作らないが、やりとりにバリエーションがある場合、例えば初めての会話の時と2回目以降の会話でユーザーからの発話が違う、Alexaのレスポンスが違うなど想定する場合はそれぞれ turn を作成し、縦一直線に並べておく。

最初に作るであろう Storyboard はおそらく Happy Path のものだろうが、それができたら何かしらうまくいかないパターンの Storyboard などもそれぞれ作成をしていく。

 graph-based な手法と違って、パス1つにつき1つの Storyboardを作成する。

ドキュメントには書いていなかったので正しいかはわからないが、Storyboardを作成する上でなんかやりとりに違和感がある場合は、それを補完する turn を作成して挿入すればいいのではないかと思う。

感想

結局のところ graph-based な手法と比較して、ノードが turn になって、 graph が Storyboard と呼ばれるようにだけなんじゃないかなと思ったが、公式の例を見たりすると、基本的に一直線に前にしか進まないところがまた一つの重要なポイントなんじゃないかなと思った。
Google Assistant のデザインガイドにも「会話に後戻りはない」みたいなこと書いてあった記憶があるし(細かい言い回しはちょっと違うかも)。

また、 graph-based な手法では色々なパスをひとつの graph にまとめてしまっているが、Situational Design では1つのパスに1つの Storyboard を用意することで複雑さを排除しているんじゃないかと思った。

というわけで次回はこのSituational Designを実践していく際に頭に入れておくべき4原則についてまとめる。