デザインシステム

A collection of 22 posts

UI

デザインシステムの落とし所はどこにある?

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

デザインシステム

デザインシステムに関わるいろいろなプロセスを図にしてみた

今までも何度か デザインシステム に関する記事を書いてきましたが、手段や考え方が中心でした。今回はプロセスに注目して、代表的な課題を図にしてみました。すべてのケースに当てはまるわけではないですが、参考にしてください。 大まかな進め方 「デザインシステムを作りました!」とドカンと発表したほうがインパクトがあるように見えますが、苦労したわりには誰も使わないものになる可能性が高いです。実際はデザインシステムの中にあるものを小さく切り出して少しずつ変えていくことになります。 正攻法であればデザイン原則から始めたほうが良いと思っていますが、組織としてどうあるべきかといった根本的なところが明文化されていないのであれば、そこからスタートしたほうが良いでしょう。デザイン原則があったほうがデザインの議論がしやすくなるので早期にもっておきたいですが、1 日でも早く成果を出したいのであれば、まず色からはじめてみるのも手段です。順番が重要ではなく、どういうステップを踏んで進むのが組織にとってベストなのかをロードマップを作って考えてみてはいかがでしょうか。 運用・開発に関わる課題 デザインシステムの設計と構築で大きな壁になるのがデザインシステムそのものの運用です。以下のような課題は、新しいプロダクトを作ることとほとんど変わらないことが分かります。言い換えるとデザインシステムにあるヒトの課題をどう解決するかに結びつきます。 ドキュメンテーションの執筆 レビュープロセス リリースタイミング Issue(課題)の整理と処理 デザインシステムのバージョン管理 実装ツールの開発 デザインシステムのサポート 今できることの決め方 デザインシステム本が出るなど、日本でもようやくデザインシステムが認知され始めました。やってみようと思って参考にできるものを探しても Lightning Design System

デザインシステム

要素名クイズから始めるUIの呼び名合わせ

あなただったら画面にある大きなテキストを何と呼びますか? 強調されたテキストが 2 つあるとしたら、それぞれどう名付けますか? 「見出し」「タイトル」「ヘッダー」など様々な呼び名が考えられます。HTMLの知識があると、「H1, H2」と呼ぶかもしれません。これらは情報の意味を表す言葉ですが、「テキスト(大)」のように見た目で呼ぶこともできます。見た目を呼び名にするのは良くないという意見もあると思いますが、汎用性のある実装にするのに適している場合があります。 よく目にする要素でも言葉が合っていないことがよくあります。役職・背景が異なれば呼び名が違うだけでなく、そもそも何と呼べば良いか分からない要素も少なくありません。 2年前から実施している「パターンラボ」というワークショップでは、一貫性のない UI を視覚化するだけでなく、言葉も一致していないことを体験してもらっています。ワークショップでは、デザイナー、フロントエンドエンジニア、ディレクターといった違う役職で構成されたグループにしていますが、そうすると見事に呼び名が違うことに気付きます。ここに web・アプリ制作に直接関わっていない人が加わるとさらに複雑です。 デザインシステムの第一歩として色から始めるのをお勧めしていますが、早期に始めておきたいのが言葉の共有です。せっかく UI のカタログを始めても、後のほうで「

デザインシステム

デザインシステムの最初の一歩として原則を作る理由

メンタルモデルから始める デザインする上でユーザーのメンタルモデルの理解は欠かせません。 UI やコンテンツに出くわしたとき、それをどう解釈・判断し行動するかを決めるのがメンタルモデル。 Web サイトであれば青色の文字に下線が入っていればリンクであると判断するのも、過去の経験や知識を基にメンタルモデルが築かれているからです。私たちが「使いやすい」「直感的」と感じるのもメンタルモデルとインタラクションが一致しているからと言えます。 同じデザインでも評価は変わる デザインをチームで評価するとき、メンタルモデルが共有されていないために議論が思わぬ方向へ進む場合があります。Web サイトのリンクのように広く使われているものであれば共通のメンタルモデルが築かれていますが、多くの場合そうでははありません。オンボーディング、アイコンの見た目、通知のコピーなど、UI に関わるあらゆる部分で意見の相違が発生します。 Sketch の Libraries、Figma の Team Library を使えば、チームで見た目を合わせることはできますが、プロダクトにおける『らしさ』まで共有できていません。つまり、プロダクトのコミュニケーションデザインを評価するためのメンタルモデルが共有できていない可能性があります。 デザインシステムを作る際、まずデザイン原則から始めるのも、チームで共有できるメンタルモデルを作るためのでもあります。 UI コンポーネントを作る前に、原則を作るというコンセプチュアルなところから入って感覚を合わていったほうがお互いが考える『

デザインシステム

良いデザインの原則と『立ち止まる』こと

「ブラウンとアップル」という記事で、デザイナー Dieter Rams(ディーター・ラムス)が提案した良いデザインの10の原則を紹介しました。1970年代に提案されたものですが、現在にも通じる普遍性のあるメッセージです。これのアップデート版のようなものを、Co.DesignのSuzanne LaBarre さんが提案しています。特にアプリや web サイトをはじめとしたデジタルプロダクトを意識した内容になっています。 良いデザインは様々な影響を考慮している 良いデザインは『スロー』である 良いデザインは正直である 良いデザインは政治的である 良いデザインはシステムを意識している 良いデザインは良いライティングである 良いデザインは多面的である 良いデザインは人とマシンのためにある この中で特に気になった「良いデザインは『スロー』である」から、今後のデザイナーの仕事についてぼんやり考えてみました。 スローなデザインは可能か 走り続けなら改善すれば良い。ダメなら壊してやり直せば良いというスピード感のある進め方は今風と言えばそれまでですが、偏った視点を作り出す恐れもあります。 パソコンも使える web に強いユーザーが主なターゲットだった 5, 10 年前であれば、

UI

デザインの運用って何ですか?

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

UI

デザインシステムにおける色の命名ルール

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

UI

デザインシステムに採用する色を決める5つのルール

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

UI

成熟期に入ったUIデザインとデザインシステム

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

UI

意外と難しいボタンのお話

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

UI

結局デザインシステムは何なのか

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

UI

デザインしやすい部品の分け方を考える

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

UI

デザイナーがデザインシステムに参加するための課題と対策

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

コンテンツ

コンテンツモデルからデザインシステムを作り出す

コンテンツモデルは平等ではない サイトの構造や配信経路を把握するために、早期の段階でコンテンツモデルの作成が必要になります。サイトマップのような全体構造ではなく、画面ひとつひとつにあるコンテンツが何かを小さな要素まで切り取って整理することで、以下の課題が発見しやすくなります。 サイトを横断して表示されるコンテンツの形状と種類 サイト外での見せ方と必要な情報(ソーシャルメディアなど) ユーザーから見えないが必要な情報(メタデータなど) CMS への格納の仕方(すべて本文は好ましくない) ページという概念から一度切り離してコンテンツについて考えるのがコンテンツモデルの良いところですが、不動産サイト、eコマースといった複雑なサイトだと、コンテンツモデルを作るのは難しくなります。まずブログのような「記事」というひとつのコンテンツタイプしかないものから練習すると良いでしょう。 例えば、WordPress や Movable Type のような CMS にはブログをすぐ始めることができるように「記事・投稿」と呼ばれるコンテンツタイプがあらかじめ用意されています。そこには以下のような要素が含まれてます。 タイトル 本文 カテゴリー タグ 抜粋(概要) これらはどの種類の記事にも含まれる共通要素ですが、場合によって十分ではない場合があります。例えば私のサイトでも、記事には以下の要素を追加して運用しています。 カバー写真(

デザインシステム

デザインシステムが作り出す明文化への道

明文化をテーマにしていた2016年 今年の初めデザイン SDK のようなものが欲しいという記事を書きました。開発者から提案されているフロントエンド寄りのスタイルガイドはコードの品質管理と、見た目の再現性を高める上で有効な手段です。しかし、これだとコードを理解していることがスタイルガイドの利用・関与の大前提になります。すべてのデザインがコードから始まるとは限らないですし、デザイナーであれば Sketch や Photoshop といった日々使うツールを活用して最低限の品質を保つ手段が必要になります。 共通言語を作っていく。 これは文字通り言葉だけでなく、UI を始めた視覚的な部分など、今まで好みや感覚で済ませていたこともきちんと言葉にすることも指しています。デザイン批評も共通言語を作り上げるために必要なプロセスです。 建築家クリストファー・アレグザンダーの著書「Pattern Language」で、単語が集まって文章ができるように、様々なパターンを自由に組み合わせることで大きなものが生まれることを学びました。つまり、パズルのピースのような硬いものを作るというより、柔軟性のある言葉を揃えていくことを意味しています。数十年前からある考え方ですが、成長・運用が必要な今のデザインにおいて参考になります(IA に興味があれば、チェックしておきたい書籍です)。 仕事現場で模索しながら、得た知見を活用してセミナーやワークショップを続けていましたが、最近は Salesforce の Lightning Design

ガイドライン

NASAのマニュアルからデザインシステムを学ぶ

Web サイトやアプリのデザインにおいて、再利用可能な部品(UI)をカタログしたスタイルガイドが必要とされています。公開されてから次のリニューアルまでデザインが変わらないという状況はまれですし、即座に対応しなければならない場合もあります。制作時は想定されていなかった要素も出てくるでしょうし、対応できる技術が変われば、コードから見直しも考えられます。変わり続けるのはコンテンツだけででなく、デザインにも同様のことが言えるわけです。 Web サイトやアプリといったデジタルプロダクトだけでなく、紙媒体やソーシャルメディアなどあらゆる場でデザインの一貫性が求められています。そうした場合、フロントエンド寄りのスタイルガイドだけでは不十分で、ロゴ規約や書体の扱い方などデザインに関わる様々な素材・ツールを揃えた何かが必要です。デザインSDKのようなもの。特定のデザイナーに知識やスキルを集約させない、拡張性と柔軟性を可能にするデザインシステムを作ることが、デザインの運用に欠かせなくなります。 幸い Material Design のような参考になるサイトがありますが、もっと以前からデザインの『システム化』を試みた組織があります。デザイナー Richard Danne と Bruce Blackburn が 1975 年に作成した NASA Graphics Standards Manual は、

デザインシステム

デザインシステムにあるヒトとコトの課題

今なぜデザインシステムなのか 4月16日 Webridge Kagawa 主催で「パターンラボ – 柔軟性と拡張性をデザインに取り込む方法(#wmsp20)」というワークショップを開催しました。昨年はコンテンツ戦略やペルソナなど企画・設計寄りのワークショップを実施していましたが、パターンラボは少し実装に寄り添ったカリキュラムにしました。ポッドキャストでも話したことがありますが、「考える」と「作る」の間にはちょっとした溝があると思います。ペルソナやカスタマージャーニーマップで利用者像や彼らのもつ課題を視覚化すれば、現実的な実装ができるというわけではありません。実装へ近づけるためには、考える人と作る人が一緒に課題共有するための場が必要と考えています。 例えば Web デザインでは数年前から、パソコンではなくスマートフォンやタブレットをはじめとしたモバイル機器での使いやすさを優先するモバイルファーストという考え方があります。多くの制作者がこの考え方に同意できると思いますが、具体的にどのように進めて作れば良いのかハッキリ分からないという問題が残ります。制作工程を変えるとしても、それをクライアントも含めて説得・理解してもらわなければならないわけですから、「モバイルファーストです」と宣言するだけでは足りないわけです。こうした設計思想や、運営方針といった考え方を、作り方に転換するのが難しい場合があります。 今回のワークショップは数年前から続けているコンテンツ設計の手前、もしくは別アプローチとして捉えています。近年、コンテンツマーケティングという言葉が広がったおかげで、運営すること、それができる体制をつくることの重要性が理解されるようになりました。しかしデザインで同じように「運営できることを」が意識されているのかというと、

Webデザイン

Webデザインシステムはじめの一歩

CSS フレームワーク活用のタイミング Bootstrap、Foundation をはじめとした CSS フレームワークを一度くらい使ったことがあると思います。制作はもちろん、どのように CSS ファイルを整理すれば良いのか、どのようにデザインのルールを設計するのかといった CSS の書き方を学ぶ際にも使えます。もちろん CSS フレームワークはたくさんありますし、 Gridlex のように Flexbox を活用したグリッドシステムだけといった UI の特定要素のみを提供しているツールもあります。 CSS フレームワークは制作において非常に便利なツールですが、最終成果物として扱うかは注意が必要です。以下のような場合を除いて、CSS フレームワークはなるべく使わないようにしています。 プロトタイプ作成 Photoshop や Sketch のようなグラフィックツールで Web サイトをデザインしても、Web ブラウザで見るまで実際どうなるか分からないことがたくさんあります。例えばテキストの描画ひとつとっても、グラフィックツールと Web ブラウザでは異なります。少しでも早く Web