パターンライブラリーの継続運用
ウェブサイトやアプリケーションの開発や運営においては、UI コンポーネントを一覧化した パターンライブラリー (またはスタイルガイド) を用意しプロジェクト関係者の間で共有しておくと便利です。私自身そうですが、ウェブサイトのリニューアル案件などで、情報設計 (IA) と併せてパターンライブラリーをまとめることもあるのではないでしょうか。
パターンライブラリーは、デザインの品質を保持するうえで有効なツールですが、その一方で、適切に継続運用することの難しさも実感しています。たとえば :
- パターンライブラリーに定義されている以上のデザインをしない。よりよいデザインにしようとする思考が停止する。デザインしない/できない理由をパターンライブラリーのせいにする。
- パターンライブラリーの「ありあわせ」で済ませようとするあまり、ある UI コンポーネントを裏技的に、本来想定されていない用途で適用してしまい、かえってユーザビリティを損ねる。
...といったケースを目にすることがありますが、サイトの規模が大きくなり関わってくるコンテンツオーナーや制作者が増えると、このようなリスクが増えるように感じます。
本来パターンライブラリーはそういうものではなく、あくまでも品質基準を具現化したものとして、そこをベースに制作者によるクリエイティビティをどう伸ばすか、ひいてはどうよりよいユーザー体験 (UX) をもたらすか、が大事なはずです。そのためにはどうしたらよいのでしょうか。
パターンライブラリーの存在意義を言語化する
まずは、なぜこのパターンライブラリーがあるのか?という存在意義をきちんと言語化し、組織 (プロジェクト) 内で共通認識してもらう必要があります。
- UI の一貫性を維持するため。ユーザーの認知負荷や学習負荷の軽減、イディオム化の促進。
- 品質を維持するため。アクセシビリティの担保、マルチデバイスでの QA 負荷の軽減。
- (より積極的に) ブランドイメージ (自社らしさ) を訴求するため。
...など、パターンライブラリーの意義はいろいろあると思いますが、組織の実情に合わせてより具体的な言葉で、明文化し共有しましょう。
この共通認識があれば、パターンライブラリーが想定していなかった状況が生じた場合でも立ち返るべき拠り所が明確になるので、その解決方法について建設的な議論につながることが期待できます。
UI コンポーネント定義を言語化する
パターンライブラリーでは、個々の UI コンポーネントをただ並べるだけでなく、各コンポーネントの定義を明文化することがとても重要です。各コンポーネントのネーミング、用途、コード、使用上の制約、使用法のオプションなどを、実際に制作者が迷わず使えるように言語化しましょう。
ここがきちんと共通認識されていないと、制作者が各コンポーネントの使用法を見た目の印象だけで勝手に判断してしまったり、裏ワザ的に (パターンライブラリーが本来意図していない形で) ある UI コンポーネントを用いてしまったり、といったことが生じ得ます。
制約 vs 自由度のさじ加減を共通認識化する
パターンライブラリーの適用にあたって、何を/どこまで縛るのか、また逆に何を/どの程度自由裁量にするのか、というさじ加減を共通認識化することは、案外難しいものです。組織やプロジェクトの体制 (人的リソースのスキルレベル) によって、また制作/運営するサイトやアプリケーションの性質によって異なってくるので、ある程度の試行錯誤は必要だと感じます。
個人的には、パターンライブラリーそれ自体の役回りは控えめでよいと思っています。骨格となるグリッドシステムや基本的な UI 要素 (サイト内の各所で共通的に流用したほうが効果的な UI コンポーネント) が定義されていれば、それ以外はアクセシビリティが担保されていることを条件に、デザイナーが「遊ぶ」余地があってよいのでは、というスタンスです。あくまでもユーザビリティや UX を最優先に据えることが重要で、それらがパターンライブラリーによって阻害されるという本末転倒は避けたいものです。
このあたりのさじ加減を共有するには、実際にパターンライブラリーを参照しながら、プロジェクト関係者 (デザイナー、制作/開発担当者、サイトオーナーなど) みんなで一緒にプロトタイピングしてみるのが理想的です。あるいは、実制作のプロセスをパターンライブラリーの QA としても捉えてみることで、関係者にパターンライブラリーへの建設的な関与を促すのもよいでしょう。こうした過程で得られた知見をパターンライブラリー側に反映することを繰り返すことで、コミュニケーションツールとしてのパターンライブラリーの成熟度が高まってゆくことが期待できます。
変化に現実的に対応する
パターンライブラリーを継続的に運用していると、ウェブサイトやアプリケーションのデザインのありかたの変化に応じて、場合によってはパターンライブラリー側の修正を検討しなければならないことがあります。ユーザビリティの向上、ひいてはよりよい UX の実現を最優先に据えて、できるだけ柔軟に対応したいものです。
しかしその一方で、これまでパターンライブラリーにコミットし続けてくれた制作現場の人たちを尊重することも忘れないようにしましょう。パターンライブラリーは徹底されるべきレギュレーションであり、少なからず制作工程を縛っている経緯がある以上、急激なスクラップ&ビルドは、制作者のモチベーションに影響する可能性があります。
特に作業上の影響範囲が大きい (あるいは影響範囲の予測が難しい) パターンライブラリーの修正は、制作現場視点からの意見や次善策案を十分に聞きつつ慎重に議論し、現実的な落とし所を模索することが大事かなと思います。