AMIVOICE / UI INTEGRATION
音声認識APIの結果を、
業務画面で使える形にする。
APIから値を取れた。
でも、 それだけでは業務画面としては使いにくい。
誰が話したのか。
どの順番で話したのか。
詳細をどこで見るのか。
感情レベルをどう確認するのか。
AmiVoiceから取得した会話データを、 実際にオペレーターが追える画面へ
落とし込んだ経験を整理します。
INTRODUCTION
APIから取れた値を、
そのまま出せばいいわけじゃない。
通信会社向けの カスタマーサポートシステム開発で、 AmiVoiceの音声認識結果を 画面に表示する機能を担当しました。
サーバー側で取得したデータを JavaScript側へ渡して、 会話履歴として画面に並べる。
大きく言えば、 やっていることはそれです。
ただ実際に画面を作ると、 単純に文字列を並べるだけでは 見づらいことが分かりました。
APIの値を取ることと、
業務で使える画面にすることは別だった。
そこから、 誰の発言なのか、 どう見せれば会話を追いやすいのかを 考えながら画面を作っていきました。
01 / GET DATA
まずは、
会話データを画面まで持ってくる。
実装としては、 サーバー側でAmiVoiceのデータを取得して、 JavaScript側へ渡していました。
JSP側だったかJava側だったかは 今となっては細かく覚えていません。
ただ、 サーバー側で取得した値を JavaScriptで受けて、 画面を組み立てていたのは覚えています。
会話データには、 発言内容だけでなく、 誰側の発言なのか、 感情レベルなど、 画面表示に使える情報もありました。
なので、 一つの文字列として扱うのではなく、 それぞれの情報を見ながら 表示を組み立てていきました。
02 / CONVERSATION LIST
会話は、
リストとして追えるようにする。
取得した会話データは、 時系列でリスト化しました。
電話のやり取りなので、 一件だけ表示されても あまり意味がありません。
どんな流れで会話が進んだのかを 上から順番に追えるようにする必要があります。
Customer
「○○について確認したいのですが」
Client
「承知しました。確認いたします」
Customer
「お願いします」
Client
「こちらの内容でよろしいでしょうか」こういうやり取りが 一つの会話として追える形です。
APIから返ってきたデータを 画面上の会話に変換するところが、 実際の作業ではかなり重要でした。
03 / SPEAKER
誰の発言か、
一目で分かるようにする。
会話履歴を全部同じ見た目で並べると、 誰が話しているのか 一瞬では分かりません。
そこで、 カスタマー側と クライアント側で 表示位置を分けました。
カスタマー側は左寄せ。
クライアント側は右寄せ。
左右を見るだけで、
どちらの発言か分かる。
チャット画面に近い見せ方です。
さらに、 それぞれにアイコンを付けて、 発言者を見分けやすくしました。
発言内容だけではなく、 配置やアイコンでも 情報を伝えるようにしていました。
04 / VISUAL CUE
アイコンでも、
誰が話しているかを補助する。
左右の配置だけでも 発言者は分けられます。
ただ、 会話が長くなると 視線を動かしながら読むことになります。
そこで、 発言者ごとに faviconのような小さいアイコンも 表示しました。
左右の位置。
アイコン。
この二つで、 どちら側の発言なのかを ぱっと判断しやすくしました。
こういう細かい見せ方は、 APIそのものとは関係ありません。
でも、 実際に業務で使う画面では かなり大事でした。
05 / MODAL
発言を押すと、
詳細をモーダルで開く。
会話一覧だけではなく、 発言を選ぶと 詳細を確認できるようにもしました。
リスト上の値を押すと、 モーダルウィンドウが立ち上がる。
その中で、 会話の詳細や 相手の感情レベルを確認できる形です。
一覧では流れを見る。
詳細は必要なときだけ開く。
最初から全部の情報を 一覧に詰め込むと、 逆に見づらくなります。
普段見る情報と、 詳細で見る情報を分けることで、 画面を整理しました。
06 / EMOTION LEVEL
文字だけじゃなく、
感情レベルも見る。
AmiVoiceから取得した情報の中には、 会話内容だけでなく 感情レベルもありました。
モーダルを開くと、 その発言ややり取りに対して 感情レベルを確認できるようにしました。
同じ言葉でも、 実際の会話では 話し方や感情によって 受け取り方が変わります。
音声認識結果を ただ文字起こしとして表示するだけではなく、 付随する情報も 画面上で確認できるようにする。
そこまで含めて、 カスタマーサポート向けの 画面になっていました。
07 / SCROLL
会話が増えたら、
スクロールもちゃんと動くか。
会話履歴は、 件数が少ないと きれいに見えます。
でも実際には、 会話が長くなれば リストもどんどん伸びます。
モーダルの中も同じです。
情報量が増えたときに、 スクロールできるか。
レイアウトが崩れないか。
下までちゃんと見られるか。
データが入るだけではなく、
増えたときに使えるかを見る。
こういう部分も 実装しながら確認していました。
08 / API TO UI
APIのデータを、
UIの意味に変える。
この機能で面白かったのは、 APIから取得した値が そのまま画面になるわけではなかったところです。
発言者の情報は、 左右の配置になる。
会話内容は、 リストになる。
感情レベルは、 モーダル内の詳細情報になる。
発言者を分ける情報は、 アイコンにもなる。
APIの項目を、
画面上の役割に置き換えていく。
この感覚は、 API連携を触るうえで かなり大きかったです。
09 / CHECK
値が取れた後も、
見るところは多かった。
この機能を作るときは、 API通信だけを確認すれば 終わりではありませんでした。
- 会話データが取得できているか
- JavaScript側へ正しく渡っているか
- 発言順が崩れていないか
- 左右の表示が正しいか
- アイコンが正しい側に出ているか
- 発言を押したときモーダルが開くか
- 感情レベルが正しく表示されるか
- 会話が増えてもスクロールできるか
API、 JavaScript、 HTML、 CSS。
一つの機能でも、 いろいろなところをまたいで確認しました。
FIELD NOTE
APIが動いたら終わり、
ではなかった。
AmiVoiceから 会話データを取得する。
それだけなら、 API連携の話です。
でも実際の機能では、 その先がありました。
会話を一覧で追えるようにする。
誰の発言か分かるようにする。
詳細を必要なときに開けるようにする。
感情レベルも確認できるようにする。
会話が増えても ちゃんと使えるようにする。
APIから取れたデータを、
人が使える形にする。
この機能では、 そこまで作って初めて 一つの業務機能になるんだと 分かってきました。