ARTICLES

コンテキストを把握する | 非エンジニアのための SPA / PWA 的世界におけるコンポーネントデザイン入門 (2)

2019-04-23

前回、SPA / PWA のコンポーネントをデザインするにあたって、以下の 4 つの観点も考えると漏れがないですよという話を書きました。

  • どういうときに保存済みになるのか、どういう使われ方をするのか (コンテキスト)
  • 状態は「保存する」「保存済み」の 2 点のみか (状態 : ステート)
  • 文言や時間といったデータは外部から与えられるものか、そうでないのか (外部からの影響 : データ)
  • 状態変化や外部に影響を与えるのはどう言う時か (アクション)

今回は、一つ目の「どういうときに保存済みになるのか、どういう使われ方をするのか」という点について話をします。

括弧内にコンテキストと書いていますが、まずは、このコンテキストという用語について。

まず、考える拠り所を作ろう

コンテキストは文脈という意味ですが、ここで取り上げる文脈は、そのコンポーネントをユーザーが使う文脈になります。ユーザーが使う用途という意味合いでユースケースという言葉がありますが、コンテキストはもう少し操作の流れや時間的側面に視点を置いたものになります。というのも、コンポーネントは時と場合により変化し、それがデザインするべきポイントを把握しづらくさせるからです。

混同しないように書いておきますと、文脈自体をデザインするという話と文脈に沿ってデザインをするという話は違います。ここで取り上げるのは、文脈に沿ってデザインするという部分です。つまり、ある程度具体的なところまで落とし込まれており、手を動かして具現化をしていくというフェイズの話です。

さて、ユーザーインターフェースをデザインするにあたり、コンテキスト自体をデザインしましょうという話ではないので、今回の観点における具体的な制作物はありません。どちらかというと、コンポーネントをデザインしている中でよくわからなくなったときに立ち返る場所を整理するという認識でとらえていただければと思います。

複雑なコンポーネントをデザインしていると、どんどん考慮すべきポイントが増え、よくわからなくなることがあります。そんな時「これってどういうコンテキストで利用されるんだっけ?」ということを思い出せば、おのずと結論は出てくることでしょう。

ひょっとしたら、そんな複雑なコンポーネントである必要はないかもしれません。標準の HTML コンポーネントを使えば済むのであれば、それに越したことはないのです。

コンテキストに沿って、保存ボタンについて確認する

前回、例としてあげた保存ボタンですが、コンテキストに沿って考えて抜けがないか書き出しつつ、確認していきましょう。

保存するボタン

保存済み 10:15に保存というラベルのボタン

動的に変化することが前提のコンポーネントは、考えることが多くて大変ですよ。

  • 保存ボタンは、フォームと組み合わせて利用される
  • 保存ボタンは、フォームの内容を保存するために利用される
  • 保存ボタンは、サーバーに保存される場合に使われることを想定している
  • 保存ボタンは、保存可能な状態のときにアクティブになる
  • 保存ボタンが、保存可能でないときの状態は?
  • 保存ボタンは、保存された場合に保存されたことを伝え、2度押しされないようにする
  • 保存ボタンは、保存された場合に保存時刻がユーザーに通知される
  • 保存ボタンを押したのに、保存されなかった場合 (エラーなど) の状態は?
  • 一度保存されているデータが編集され、保存可能な状態になった場合の状態は?

この保存ボタンは非常に小さなコンポーネントですが、意外にもいろいろな考慮ポイントがあったことがわかりますね。
また、実際の用途に沿って保存ボタンについて書き出してみると、考慮漏れがあることもわかりました。

現場では、一旦デザインが仕上がった後の工程にて、考慮漏れが指摘されて「うーん、じゃあ保存が完了した状態と同じ灰色のボタンにして時刻表示はなしにしましょう」みたいな感じで場当たり的に決めてしまうということの繰り返しがおきます。もちろん、統一感を保ちつつデザインを進めていければこれでもいいかもしれません。ただ、コミュニケーションコストも増えますし、そこまで考えていなかったんですか、というデザイナーの評価の低下を招くことになりかねません。

これら考慮漏れ事項は、いざ実装を始めると割と簡単に気づく点です。事前に観点を持ち、より深くコンポーネントのデザインをしていきましょう。

ところで、複雑なコンポーネントであればあるほど、考慮漏れは増えます。
そのため、複雑なコンポーネントをデザインすることになったら、まずは、同じ用途を保ちつつ、複雑なコンポーネントにしなくていい方法がないか検討するというのは大事な点です。

コンポーネントデザインクラブの第一原則は「複雑なコンポーネントをデザインするな」と言えるでしょう。

前回の例に戻って、コンポーネントの利用用途に沿って考えた場合、ボタンの中に必ずしも最終保存時刻を入れる必要はないと考えることもできます。そうすると、最終保存時刻はボタンの外にしてもいいでしょう。ボタンにはラベルのみが表示され、実装もシンプルになります。

保存するボタン改

ボタンのラベルについても、「保存する」「保存済み」「(保存に失敗した場合のラベル)」などを考慮すると、状態によって文言を変えてもいいですが、最初の 1 回目の保存は「作成する」などにしたくなる可能性もあります。 いろいろとユーザーのストーリーを想定した上で、シンプルなところへの落とし込みとして、あえてラベルは「保存」のみにし、最終保存時刻は外出しにするということで進めていくことにしてみましょう。こうすることで、文言の状態について頭を悩ます必要はなくなります。

保存するボタン最終版

コンポーネントについて、実際どう使われるのかという点を考えることは 4 つの観点において最も重要なことです。他の 3 つについては、コンテキストを踏まえてデザインしていくことで、おのずと方向性は導き出されます。ただ、もう少し細かいチェックポイントがあるので、引き続き書いていきます。


ARTICLES


    AUTHOR

    原 一浩 の顔写真

    (はら) 一浩(かずひろ)

    カンソクインダストリーズ代表 / グレーティブ合同会社代表

    1998年に独立し、同年、ウェブデザイン専門のメールメディア DesignWedgeの発行を開始。Webデザイン業の傍ら、海外のWebデザインに関する情報発信を行う。
    雑誌への寄稿多数。主な著書に『はじめてのフロントエンド開発』『プロセスオブウェブデザイン』、『Play framework徹底入門』、『ウェブデザインコーディネートカタログ』など。自社製のWebデザインのクロール&キャプチャシステムvaqumをベースに、様々なリサーチを行っている。Web 検定プロジェクトメンバー

    著作一覧はこちら