法人向けソフトウェアに素晴らしいUIを実装するためにできること

enterprisesoftware


編集部記: Etan LightstoneはNew RelicのUXデザインのディレクターである。

ユーザーのサービスのUXに対する期待値は上がっている。コンシューマーが良いと思うエクスペリエンスを提供することは、市場における競合と差別化し、成功を得るのに重要だ。ソフトウェア開発者の多くはこの事実に気がついてはいるが、法人向けのプロダクトにコンシューマー向けソフトウェア同様の品質をどのように出すかが直近の課題となっている。

エンジニアのいないデザイナーの作品は、ただのアートだ。デザイナーのいないエンジニアの作品は、味気ない駐車スペースだ。

デザイナーとエンジニアの目線、あるいはデザイナーとプロダクトマネージャーのそれぞれの考えをバランス良く取り入れることが非常に重要である。デザイナーがプロダクト開発の最初か最後にまとめてデザインを作るのではなく、プロダクトを開発している間もエンジニアと密に連携し、デザインとプロダクトを融合させていくということだ。

プロダクト開発では、リードデザイナーとプロダクトマネージャーが同程度の権限を持つことで、双方の間に適切な緊張感を生むことができる。双方の立場からプロダクトをそれぞれの観点から見て、バランスが取れているかを確認する。

  1. デザイナー:プロダクトをデザインの観点から見る。ユーザビリティ、ワークフロー、ユーザーの情感に訴えられているかを確認。

2.プロダクトマネージャー:プロダクトをビジネスの観点から見る。自社のマーケットシェアを増やし、利益を出すことができるかを確認。

私たちのプロダクトデザインでは、デザインチームがエンジニアチームと「ハブアンドスポークモデル(訳注:ハブアンドスポークとは、自転車の車輪という意味。ハブとなる拠点を設け、他の拠点となるスポークとつなげる物流モデルのこと。)」で動くことが有効であることが分かった。一つのデザインチームがハブとなり、そこで課題に取り組み、プロダクトのレビューを行う。ハブと同じくらいスポークも重要だ。プロジェクトのリードデザイナーが、担当のプロジェクトチームにも在籍する。プロジェクトチームにデザイナーが深く関わることで、開発ライフサイクルの中で、エンジニアチームが日々の業務で取り組んでいる課題を知ることのできるデザイナーが一人はいることになる。

情感に訴えるデザイン

ユーザーへのリサーチは必要不可欠だ。ユーザーが目的を達成するのに最適なデザインとワークフローを作るために、適切なデザインパターンを駆使し、テストを何度も繰り返してインタラクティブなデザインを実装する。ユーザーが誤った操作をしてしまわないように、ストレスを感じる部分を減らすことで、使いやすいプロダクトになる。私たちがプロダクトのワークフローに関する決定を行うときは、ユーザーの目標を理解するために行ったリサーチ結果を参考にする。そうすることで、どの課題を解決すべきなのかが明確になる。

これで機能的な素晴らしいプロダクトデザインに近づくが、ユーザーの信頼とロイヤリティを獲得するためには、ユーザーの情感に訴えるデザインが必要だ。ユーザーが喜ぶ、小粋なアニメーションをチャートの中に施したり、チャートがロードしている間はロード状況を表示したり、メニューが元の位置に戻るときのジェスチャーを工夫したりするということだ。これらはユーザーがプロダクトに親近感を持つ瞬間だ。ユーザーの意識に上るようなことではないかもしれないが、ユーザーは無意識のうちにそれらを認識し、プロダクトへの信頼感が増して、また利用したいと思うようになる。

このような、感覚的なデザインは多くのコンシューマー向けプロダクトで見られる。例えば、iPhoneのドラッグやスナップ機能や電源を入れた時のチャイムの音や、Misfit Shineのウェアラブルデバイスをモバイル端末と同期させる時に表示されるちょっとしたアニメーションなどである。

ベータテストを行うその前に

データや情報量の多いUIの場合そのソフトウェアは、そこで自分のデータや情報を見てもらえる人に試してもらうことが必要だ。UIデザインを正しく評価するためには、実際のデータを流し込み、違う表示を試みたりとプロトタイプを練る必要がある。バグを修正したり、エクスペリエンスを少し磨いたりするベータテストはその後で良い。

早い段階からユーザーに自分のデータと情報でプロダクトを試してもらうことの重要性を改めて強調する。ベータテストまでこれを取っておくのは非常にリスクが高い。ベータ版の段階では、既に開発が進みすぎていてコンセプト自体に重大な問題が発生した場合には対応できない可能性があるからだ。初めからやり直すには、コストがかかりすぎるだろう。

私たちが短期集中の開発を行う場合は必ずユーザーを揃えておき、プロダクトのレビューを行い、ユーザビリティについての助言をもらえる体制を築いている。初期の段階で、プロダクトの全ての要素が出揃っていなかったとしても、プロトタイプをいくつか用意し、ユーザーの課題を解決する手助けができて彼らの反応が良いものを探すのだ。

ほとんどのソフトウェア開発ではこれが当然のように行われているが、法人向けのデータを扱う場合、それらの提示方法は無限にあるため、コンシューマー向けよりデザインは難しいかもしれない。ユーザーが疑問に思うことに対応するためには、(彼らが何を聞きたいか見当がつかない場合も含め)リアルタイムでのフィードバックを得るようにすることだ。ユーザーに何が欲しいかを尋ねるのと彼らが実際に使用しているところを見るのは全く違うことなのだ。どちらも必要になってくる。

フィードバックのバランスを考え、ブレないこと

多くのコントロールと柔軟性をプロダクトに求める法人ユーザー向けにシンプルで強力なUIを作ることは、たくさんの役職を受け持つスタートアップの人にとって大きな挑戦である。そこのバランスを取るためには、得られたフィードバックに重み付けをし、時には重要に見える提案を見送る判断をすることが重要だ。

例えば、私たちが数年前にNew Relic Servers を初めて作った時、まずは必要最低限の機能しか提供しなかった。ユーザーを情報でオーバーロードしたくなかったのだ。ユーザーに対して、サーバーが行っていることを伝えるいくつかの指標を提供した。しかし一人のユーザーは、全く違うものを求めていた。メイン画面で考えつく限りの指標の載った、30以上のチャートを見たがったのだ。

ユーザーの意見を受け、より多くのデータを調べなければならない時はそのデータに簡単に行き着けるようにした。ただし、最初のメイン画面では全てを表示していない。なぜなら大量の指標が無造作に並んでいると、ほとんどのユーザーはそれに圧倒されてしまうからだ。それでは、私たちがユーザーに提供したい価値と一致しない。

シンプルだが、正しい実践を繰り返すことで、デザインは最適化されていく。初期の段階からユーザーに寄り添うこと、開発途中もユーザーとリアルタイムで協働すること、ユーザーに驚きと喜びを与えるユーザーエクスペリエンスを構築し、どのフィードバックを重要視してデザインに落とし込んでいくか判断すること。これを繰り返すことで、ソフトウェアが主流の時代に、他の競合から抜きん出るソフトウェアを作ることができるだろう。

[原文へ]

(翻訳:Nozomi Okuma /Website/ facebook

投稿者:

TechCrunch Japan

TechCrunchは2005年にシリコンバレーでスタートし、スタートアップ企業の紹介やインターネットの新しいプロダクトのレビュー、そして業界の重要なニュースを扱うテクノロジーメディアとして成長してきました。現在、米国を始め、欧州、アジア地域のテクノロジー業界の話題をカバーしています。そして、米国では2010年9月に世界的なオンラインメディア企業のAOLの傘下となりその運営が続けられています。 日本では2006年6月から翻訳版となるTechCrunch Japanが産声を上げてスタートしています。その後、日本でのオリジナル記事の投稿やイベントなどを開催しています。なお、TechCrunch Japanも2011年4月1日より米国と同様に米AOLの日本法人AOLオンライン・ジャパンにより運営されています。