使いやすさをデザインする上で心掛けていること

Mackerelのサービス詳細画面のスクリーンショット

こんにちは。デザイナーの id:murata_s です。Mackerelのリリース当初からMackerelの画面設計やUX、ユーザビリティなどのデザイン業務全般を担当しています。

今回は、主にエンジニアさんのためのツールであるMackerelをデザインする際に id:murata_s が気をつけている点を紹介します。ユーザーにとって必要な情報を分かりやすく伝え、迷わないデザインを施すにはどういった配慮が必要か、製品の振る舞いのデザインについてMackerelの事例を交えながら考えてみたいと思います。

Mackerelは言わばソフトウェアであり管理画面ですから、一般に言われるウェブサービスよりもツールとしての側面が強いサービスだと思います。雑誌の誌面ではなく、車のダッシュボードをつくっているようなもので、グラフィックデザイン的な情報設計の考え方が前提となりつつも、それに加えてプロダクトデザイン的な身体性を視野に入れた発想が求められます。

毎日の道具に与える意味

Mackerelのデザインをする上で気を使っていることの一つが、いま何が起きているのかがわかるということ、次にどのような行為が可能かがわかること、それから行為の結果どういうことが起こるのかがわかること、といったユーザーの一連の行為に寄り添った製品の見え方の定義です。

先にも触れましたが、ツールとしての側面が強いMackerelにおいては、日常的に反復される行為が安心感を持ってスムーズに行えることや、緊急事態の時に迷わず最小限の操作でミスをすることなく目的が達成できることが重要になってきます。そのためには容易に製品の振る舞いを予期でき、それとの相互作用の結果として自然な反応をしてくれる製品に仕上げることが重要になってきます。

ひとことで言えば<普段使いの使いやすい管理画面>がMackerelのデザインのゴールです。

それ、ほんとに動いてるのかい?

2015年3月にグラフの自動更新を制御できるボタンをリリースしました(グラフの自動リロードに対応しました・サービスメトリックの監視を正式化しました・ほか)。これは、サービスやホストの画面内にあるすべてのグラフを1分間に一度の頻度で自動的に更新する機能です。

グラフの自動リロード機能のスクリーンショット

メトリックはmackerel-agentから1分間に一度の頻度で投稿されますので、グラフについても1分間に一度の更新をすることで、ユーザーの特別な操作を必要とせずに最新の状態を常に表示できるようになりました。画面を開きっぱなしにして常時モニタリングをするときに便利です。これまではブラウザの更新ボタンを押して、画面全体の更新を都度する必要がありました。Mackerelのユーザーさんに重宝されている機能の一つです。

さてここで、この自動更新ボタンの最も素朴なUIを考えてみましょう。きっとこうなるはずです:

グラフの自動リロード機能のスクリーンショット

チェックボックスにチェックを入れることで有効にするかしないかということを決められます。

あるいは、類似する機能をもたせた既存の製品ではこのようなUIも見受けられます:

グラフの自動リロード機能のスクリーンショット

プルダウンメニューの中から項目を選択すると、このように「10秒間隔で更新します」と表記されます。

なんだか不安になりませんか? 本当にこれにチェックを入れるだけで、もしくは選択をするだけで自動で更新をしてくれるのだろうかとすこし心配になります。

そこで、Mackerelではこの機能にこのようなデザインを充てることにしました:

グラフの自動リロード機能のスクリーンショット

製品はどのような振る舞いをしたか

ユーザーを不安にさせる自動更新のUIに欠けていることがありました。それは「いまどうなっているか」という情報です。チェックボックスにチェックが入っているだけでは、実際に動いていることを実感できません。機能を有効にしても、1分間待って実際に画面が更新されることを確認しないと、これが本当に動いていることがわからないもどかしさと不安があります。

そこで、Mackerelの自動更新UIには、動いていることが分かりやすく理解できるように緑色のランプで動いている状態を示すことにしました。更新機能が有効になっている状態と、それが実際に作動していることを示す状態との2種類の情報を示すことで、ユーザーの行為に対するフィードバックに説得力を持たせ、安心感が得られるような配慮をしました。ただし、実際の実装としてはこの2種類の状態を別々に扱ってはいませんので、あくまでデザイン上での扱いです。

ユーザーと製品とのやり取りを分解してみると、どのような振る舞いを製品に与えるべきかをみつけやすいと思います。恐らくこれよりも詳しくユーザーと製品とのやり取りを捉えることは可能でしょう。

ユーザーと製品とのやり取り
ユーザーと製品とのやり取り

大事なのは、デザイナーが製品に適切な振る舞いを与えることができるかどうかということで、それは、ユーザーが持っているメンタルモデルとデザイナーが描くデザインのモデルとにズレがないかどうかを確認することでもあります。

この場合、ユーザーが知りたい情報は、それが動作しているかどうかですから、そういった「動いている証拠」をデザイナーが製品に与えることが必要でした。それを示すために点滅するランプをタイマーの動作のメタファーとして配置することにしました。ユーザーの行為に対応するフィードバックは、その大小に関わらず、安心感を抱いてもらうために必要不可欠な情報です。

グラフの自動リロード機能のスクリーンショット

その他のデザイン例

このような特別に情報を整理することで使いやすさを向上させた例をMackerelから探すとすれば、監視機能の動作を制御するUIや、ホストのステータスを変更するUI、グラフの値を表示するポップアップ、あるいはアラートの現在の状態を示すラベルなども挙げられると思います。

監視機能の動作を制御するUI
監視機能の動作を制御するUI

ホストのステータスを変更するUI
ホストのステータスを変更するUI

当然のことですが、どういう情報を提供するべきかという問いの答えはつくるものによって違ってくると思いますし、誰がいつどこでどういうふうに使うのかという利用状況についても様々あると思います。ユーザーがどのように製品を理解しているかをデザイナーが理解することや、有用性のあるユーザーの物語に寄り添ったデザインを提案することといった人間中心的な発想が、ある複雑さを備えた人工物のデザインにおいては、特に強い意味を持つことは言うまでもありません。

まとめ

上記のような考え方はMackerelに限らず、あらゆる製品の開発現場で適用できる考え方だと思います。ユーザビリティを向上させるためのチェックポイントはほかにもたくさんありますので、多角的な視点でデザイン品質を精査してゆくことが必要です。

今回はMackerelのUIに着目してデザイン例を紹介しました。ユーザビリティは当たり前品質ではありますが、これが欠けてしまうとサービスの信用を失くしてしまいますので、馬鹿にはできません。サービスのデザインにおいては、これを満たすことを前提としながらも、サービス全体の体験や、製品のエコロジーについてもステークホルダーを巻き込んで熟考してゆく必要があるでしょう。

Mackerelでは、今後も使いやすさに配慮したデザインを目指した開発を行っていきます。

採用情報

はてなではサービスのデザインに興味のあるデザイナーやScala/Perlでの開発に関心のあるエンジニアの積極採用を行っています。ぜひご応募ください!

採用情報 - 株式会社はてな