より良い UX・UI は地道な検証の繰り返しから : LINE Corporation ディレクターブログ

こんにちは、10 月からも引き続き livedoor Blog 担当の飯田です。

9 月末に livedoor Blog で新しい記事投稿画面β版 (以後β版) を、10 月頭にえもじメーカーという新機能をリリースしました。

この 2 つは開発にさしあたり「ユーザーインターフェース (UI)」や「ユーザーエクスペリエンス (UX)」を強く意識しました。今回はどうやって UI・UX について検証したかを部分的に切り出してカンタンに紹介したいと思います。

ユーザーインターフェース
ユーザインタフェース (User Interface) は、機械、特にコンピュータとその機械の利用者（通常は人間）の間での情報をやりとりするためのインタフェースである。
Wikipediaより引用

ユーザーエクスペリエンス
ユーザーエクスペリエンス（UXと略記されることが多い）とは、ユーザーがある製品やシステムを使ったときに得られる経験や満足など全体を指す用語である。ウェブ上での商品販売などソフトウェアやビジネスに関連して使われることが多いが、インタラクションデザイン全般に適用される概念である。
Wikipediaより引用

無理にゼロから考えない

β版とえもじメーカーのUI・UX を考えるとき、いきなりゼロから始めようとしませんでした。

β版では、現記事投稿画面と旧記事投稿画面をベースに UI・UX の改善を検討しました。ゼロベースから「こうあるべき論」で UI・UX の設計を行うと、逆にこれまで現記事投稿画面と旧記事投稿画面に慣れていたユーザーにとって改悪になり兼ねないからです。

また、競合他社で似たようなサービスを提供している場合、なるべく独自の路線を選択するのではなく、あえて UI を似たものにしておくのも UX という面では有利に働きます。ウェブでは統一規格なるものが存在しませんが、そのときのデファクトスタンダードに倣っておくのも手段の一つです。

ユーザーにとって「見慣れてないもの」は大きな壁になり、第一印象で「使いにくい」と思われてしまうと、そのイメージを払拭することが難しくなります。他のサービスなどで学習した知識をあえて無駄にする必要はありません。

β版の場合、旧記事投稿画面や他サービスを利用してるユーザーに違和感が無いようツールボタンをテキストエリア上部にまとめ、全体の印象は現記事投稿画面に近くしました。

director_01

Amazon や livedoor グルメのアフィリエイトボタンが旧・現記事投稿画面だと下部にありますが、上部に位置を変更しても過去の経験や「ここを探せば見つかる」という予測が働くためか、見失うということはさほど無かったようです。

えもじメーカーでは、他のサービスや、市販されているドローツールも参考にしてツールバーの UI に反映しました。

director_02

実際に動かしてみて検証

ある程度開発が終わった段階で、開発メンバーで機能部分を細かく分けて操作して、使いやすさを検証します。

やはりデザイン段階で想定した動作イメージと実際に操作した感触は違うもので、「あれ？思っていた動きと違う……」ということがよくありました。その場合はすぐに開発メンバーが納得がいくまで操作性・デザインを再考し、すぐさまコーディングや動作の変更を行います。

ショートタームで素早く検証・開発・反映を繰り返しすことで、ある程度カタチになった段階ですでに要求レベルに近いものになっています。

ただし、一度作った物が無駄になる時がたまにあるので、その辺りはあらかじめ開発メンバーで「覚悟」を決めておきましょう…… (笑)。

それと、一方の変更に気を取られるあまり、どこかで破綻が生じる場合があります。そのあたりは常にディレクターが全体のバランスに注意しておきます。

他の人に操作してもらう

開発メンバーの中で満足しても他の人が操作しやすいとは限りません。そこで開発メンバー以外の人に操作してもらいます。β版とえもじメーカーでは、二段階に分けて検証してもらいました。

まず、今開発している機能を普段使わないであろう人、今回はブログや絵文字を(書|描)いたことが無い人にカンタンなお題を与えて、どこで躓いたか・どういった操作をするかを確認します。

そして操作してもらった後、

分かりにくかったところ。
なぜ分からなかったのか。
それがどこにあれば分かったか (どこにあると思ったか)。

を軽くヒアリングします。

その次に、今度は普段ブログや絵文字を(書|描)いていそうな人たちに操作してもらいます。こちらもカンタンなお題を与えますが、普段使わない人と比較すると、躓いたポイント以外に普段から使い慣れているものと比較して足りない機能や改善案が出てきやすいようです。

出てきた結果をまとめ、先ほどと同じように検証・開発・反映を実施します。

末永く使ってもらうためにも、色んな角度から使ってもらってあらかじめ対処できる UX の改善はできるだけ行っておきましょう。当然ですが、受け入れることが難しいこともあるので、どこまで対応するかは残されている時間とターゲット層を考え、最終的にはディレクター判断になります。

えもじメーカーは特にこの工程で大きく変更が加えられ (デザイナー・フラッシャーのみんな本当にありがとうございます)、初期案とは見違えるほどのものになりました。

最終確認

これまでの反映が終わったら、最後に操作性・システム的に不整合やバグが無いかチェックを行います。よくある品質保証のテストですね。

これまでは機能を部分的に切り出して検証を繰り返していたので、重大なバグや思わぬところで別の機能の操作性に影響を及ぼしている場合があります。この工程で発見されたバグは他の部分に波及しやすいバグなので、修正には十分気をつけましょう。

当然ですがリリースした後もユーザーの反応を汲み取りつつ、これらのフローは続けていきます。

まとめ

とまあサラッとまとめましたが、各工程でかなり時間を要しています。たぶん、手を動かす時間より検証する時間のほうが長かったのかも？というぐらいあーでもないこーでもないを話していると思います。それぐらい検証に力を入れてました。

なのでこのような開発手法の場合、開発スタッフが近い場所に居ないと検証が素早くできなかったり十分な意思疎通ができなかったりと色々と困ることがあります。

そこで今回は開発スタッフが 1 箇所に集まって短期間の開発合宿を行いました。分からないことがあったらすぐ聞ける位置に居るので、IRC や Skype では伝えづらい微妙なニュアンスも的確に伝えられ、対応時間が短縮し、検証時間に充てることができました。

一見ただ開発工数がかかってるだけに見えるかもしれませんが、チーム内で悶々と熟考して開発し、形式的にユーザーテストを行ってデータをただ蓄積するより遙かに建設的です。

ただ、開発するプロジェクトの性質や開発メンバーの得手不得手に左右されるため、この手法が全てに適用できるとは限りません。開発終盤になっても心が折れなかった (笑) のは一重にモチベーションを保ち続けられたからのように思います。

やりきった後の達成感はひとしおなので機会があれば一度試してみてもいいかもしれません。