UI

寛大姿勢と厳格構造の間 デザインシステム開発における課題はいろいろありますが、いつも迷うのが『落とし所』を見つけることです。デザインシステムは下図のような軸のどこかにプロットされると考えています。コンポーネントやドキュメンテーションがほとんど用意されてない「寛大姿勢」と、様々な要素が細かいところまで決まっている「厳格構造」の 2 つです。 寛大姿勢 表現に自由があり過ぎる サポート体制がない 一貫性がない 改修コストが高い 厳格構造 トップダウン 守るべきルールと捉える人がいる 周りからの反発を受けやすい ユーザーニーズより現存コンポーネントを優先 デザインシステムはいずれかの状態に極度に寄るものではなく、軸のどこかにあります。ただし、間のどこが良いかは組織によって違うので落とし所が難しいわけです。デザイン組織の成熟度はもちろん、何を達成すると次のステップへ進めるのかを長・中・短期それぞれ考慮する必要があります。 変化し続ける落とし所 組織は常に成長・変化するものですから、最初に見つけた落とし所のままデザインシステムを維持・管理すれば良いわけではありません。 2014 年に発表された Material Design は年を重ねるごとに落とし所を変えてきている良い例です。 発表された当初は、どちらかというと厳格構造に寄っていたと思います。

公開しても終わらない コンテンツマーケティングの文脈でコンテンツの運用という言葉を耳にすると思います。いつ、誰に、何を、どのように配信するかを決めて、複数人で実践していくには運用が欠かせません。新しいコンテンツを作り続けなければいけませんし、現存コンテンツの維持・管理も必要になります。 コンテンツの運用で「公開したらあとは待つのみ」「納品したら終わり」という考えはありません。放置するとたちまち埋もれてしまい、存在していないのと同じになります。また、利用者の趣向・動向に合わせてチューニングをしていかなければ、ますます遠い存在になります。 公開したらデザインの仕事が終わるわけではないという意味でコンテンツの運用と似ていますが、デザインの運用は以下の点を解決することを目的とします。 コンテンツの量に依存した『固い』デザインにしない 基本的なことであれば短時間で実装ができる 誰が触っても最低限の品質が担保できる 一貫性のあるデザインが実装しやすくなる ひとりのスターデザイナーに頼り切らない 必要に応じて変更・改善し続けることができる CMS を導入してコンテンツを運用していくための体制ができていたとしても、デザインがそれに追いついていない場合があります。「こんなことがしたい」という施策に対して、デザイナーがひとつひとつ手作りをしていては商機を逃すこともありますし、人手がいくらあっても足りなくなります。新着情報しか更新できなかったり、特定のデザイナーが動くまで待つという状態は避けなければいけません。 運用という考え方の切り替え 事業会社で働いていたり、内製をしている組織であれば、デザインの運用ができるように日々試行錯誤していると思います。

崩れない色名にする 前回「デザインシステムに採用する色を決める5つのルール」を通して、色の名前の付け方や整理の仕方を紹介しました。これを受けてウェブデザイナーの深沢幸治郎さん（@witch_doktor）が「ウェブサイトに使われる色に固有の名前をつけてみる」という記事を書いてくれました。色の命名にまつわる苦労や工夫について読むことができるので、ぜひ参考にしてください。 前回の補足として、デザインシステムにおける色名の付け方の工夫を 3 つ紹介。色の整理をするときの参考にしてください。 色名＝変数 色の名前を付けるのに困っている方は、Kromatic がオススメ。カラーパネルのスライダーを動かすか HEX 値を入力するだけで、色名を提示してれます。他にも color-names という 10,000 以上の色名が収録されたライブラリもありますし、Wikipedia にも色名は幾つかあります。 🌈色にユニークな名前を付けると言っても良い名前が思いつかん！という方は「Kromatic」を使ってみてはいかがでしょう。 pic.twitter.com/S6P7k7NT02

始めの一歩としての色共有 ひとりのデザイナーに頼らず、チームで運用できる体制を作るためにも デザインシステム は有用なツールです。しかし、様々な UI コンポーネントと決まりごとが揃ったものを作るのは骨が折れる作業です。デザイナー（もしくはエンジニア）が独自で作って「さぁ使いましょう」と公開しても、使ってもらえるとは限りません。また、デザインシステムをどこで共有して、どのように使われるのかも考慮しなければならず、他社の真似事では済まないこともあります。 作る前から課題が山積みでなかなか手が出せないかもしれませんが、何か始めなければゴールに辿り着くことはありません。そんな現場でデザインシステムを作る場合、色から始めることをオススメしています。 色なんて単純なところは出来ていると思う方は多いと思います。デザイナーであればパレットにしてまとめているでしょうし、エンジニアであれば色は変数にして整理しているでしょう。しかし、現実は少し複雑です。 上図はある大企業サイトで使用されているコーポレートカラーらしき色を摘出したものす。HEX値が違うだけでなく、なぜ違う値にしたのか判断が難しいものがあります。恐らく最初は色の統一がされていたと思いますが、運用を続けていくうちに次第に色が増えてしまう場合があります。ドキュメンテーションがされていないまま外注をしてしまうと、新たなカラーバリエーションが増えるリスクも出てきます。 PSD, Sketch ファイルといったデザインファイルを見なければ色の使い方が分からない状態ではエンジニアはどれを使えば良いのか分かりません。デザイナー以外の人がアクセスできる場にルールを記載しておかなければ、数年前のソースコードから色をコピーされて流用される恐れもあります。 デザイナーとエンジニアの連携だけでなく、マーケッターや営業といった他の業種の方に使ってもらえる仕組みも忘れてはならない部分です。作った製品で色が統一されているのに、営業資料は違う色が使われてしまう状況を未然に防ぐことが理想です。

先進的から最適化へ 3年前、Facebook が今までのニュースフィードを完全に変えた「Paper」というアプリをリリースしました。ネイティブコンポーネントが使われていないオリジナルの UI とインタラクション。今までありそうでなかった新しい操作方法を提案していました。Paper をはじめ、様々な実験的なアプリを Creative Labs としてリリースを続けていましたが、2015 年にラボは閉鎖され、その半年後には Paper も配信停止されました。 今でも Things 3 for iOS のように新鮮な UI とインタラクションが生まれる場があるものの、あまり見かけなくなりました。今のアプリ UI デザインは、目新しいものを作るより、今まで培われたノウハウを基に使いやすさ、見やすさを磨き上げるフェイズに来ています。斬新なアニメーションと目新しい形状のメニューを作るより、ガイドラインにある Tab Bar / Bottom Navigation を実装したほうが開発しやすいですし、利用者も迷わず操作ができます。

ボタン？それともリンク？ 昨年からデザインシステムをテーマにしたセミナーやワークショップを何度か開催していますが、ワークショップに参加した方から「ボタンは難しい」という感想をいただくことがあります。ボタンの見た目を作ることも奥深いですが、もっと難しいのが、いつ、どこで、どのように使うかを共有すること。考え始めると「そもそもボタンとは何か？」といった疑問が浮かび上がります。 フォーム要素と一緒にあれば、ボタンだと断言しやすいです。HTML であればマークアップも <button> になりますし、アプリでも　iOS であれば UIButton を使えば良いと判断できるはずです。 文章のあとに「今すぐ始める」というラベルが付いた要素があるとしたら、これはボタンと呼べるでしょうか。角丸のような装飾、注目されやすい色が使われているので、ボタンと見なすことができます。見た目はボタンっぽいですが、果たして本当にボタンと呼べるでしょうか。ただ、見た目がボタンになっているだけで、リンクと呼ぶこともできると思います。 Material Designではボタンのような見た目のもの（Raised Button）と、

フロントエンドからの影響 昨年開催されたワークショップ「パターンラボ – 柔軟性と拡張性をデザインに取り込む方法」をはじめ、記事やイベントを通して維持・管理ができるデザインついて情報発信しています。CMS が広く普及して以来、コンテンツ配信を長く続けるための仕組み作りが模索されているものの、デザインは発展途上です。早く作る、効率よく作るまで議論されるものの、デザインをどう維持するのか、どうすれば最低限の品質を担保できるかまで発展しないことがあります。 1977 年に建築家クリストファー・アレグザンダーの著書「 Pattern Language 」で、パターンが街作りに柔軟性と拡張性を持たせると説いています。彼に異論を唱える人もいますし、街に個性が失われるという意見にも一理あります。しかし、彼の考え方が今の情報設計（IA）に多大な影響を及ぼしていることは間違いありません。情報や装いに一貫性を持たせることは、作り手の効率化だけでなく、使う人・みている人も学習がしやすくなります。形状、色、インタラクションが毎回違うボタンでは、それがボタンと認知されるまで時間がかかってしまいます。 Web サイトにおける UI パターンをカタログした「デザイニング・インターフェース」は良書ですが、パターンを設計していく上で個人的にインパクトがあったのが

Atomic Design の課題 デザインシステムを作っていく際、Atomic Design は非常に参考になる考え方です。Atomic Design は以下の 5 つの要素によって構成されていて、Pages へ近づくほど、より複雑で大きなものになります。 Atom : UI を構成する最小かつ基礎要素。ラベルやボタンなどが含まれる。 Molecules : 2 つ以上の Atom によって構成された小さなグループ。ラベル、インプット、ボタンで構成された検索フィールドはその一例。 Organisms : 2 つ以上の Molecules もしくは Atoms によって構成されており、画面上で独自の枠組みになっていることが多い。 Templates : コンテンツ構造が分かる大きな枠組みで、利用文脈によって分類できるレイアウトになっている。 Pages : テンプレートが実際どのように扱われているか、Atoms から構成された部品が効果的に使われているか分かるもの。 Atomic Design

実装寄りの情報だけでは不十分 コンテンツだけでなくデザインも運用していきたいと考えたとき、デザインシステムを作ることが不可欠です。属人性を省きつつ、最低限の品質を担保することが可能なデザインシステムですが、作りさえすれば組織で広まるのかというと、そんなことはありません。 Salesforce の Lightning Design System、MailChimp の Design Patterns をはじめ、自社でデザインシステムを取り入れるためのインスピレーションは幾つか見つけることができますが、フロントエンド寄りになりがちです。早く Web サイトやアプリを実装するためのガイドラインなので当然ではあるものの、これだけではデザイナーがデザインシステムへの参加が難しくなる場合があります。多くの要因は「デザイン」と「コード」にある溝と大きく関わっています。 コードが分からないと参加が難しい デザイナーが作ったものに対してエンジニアがコードに変換してドキュメント化するわけですが、これではデザインシステムと直接的な関わりが持てないので、システムの運用・改善に消極的になる可能性があります。簡易 CMS が導入されていなければ参加の敷居は高くなります。 デザイナーはデザインツールでデザインする コードにまで落とし込まれた文書があっても、デザイナーから見れば遠い存在です。コードをデザインツールに取り込んでデザインできるわけではありませんし、すべてのデザインをコードから始めるには無理があります。日々使うデザインツールとはまったく別の場所にデザインシステムがあるように見えます。 対外向けのドキュメントとして、実装寄りのルールを明確にするためにデザインシステムは有効です。