公開しても終わらない コンテンツマーケティングの文脈でコンテンツの運用という言葉を耳にすると思います。いつ、誰に、何を、どのように配信するかを決めて、複数人で実践していくには運用が欠かせません。新しいコンテンツを作り続けなければいけませんし、現存コンテンツの維持・管理も必要になります。 コンテンツの運用で「公開したらあとは待つのみ」「納品したら終わり」という考えはありません。放置するとたちまち埋もれてしまい、存在していないのと同じになります。また、利用者の趣向・動向に合わせてチューニングをしていかなければ、ますます遠い存在になります。 公開したらデザインの仕事が終わるわけではないという意味でコンテンツの運用と似ていますが、デザインの運用は以下の点を解決することを目的とします。 * コンテンツの量に依存した『固い』デザインにしない * 基本的なことであれば短時間で実装ができる * 誰が触っても最低限の品質が担保できる * 一貫性のあるデザインが実装しやすくなる * ひとりのスターデザイナーに頼り切らない * 必要に応じて変更・改善し続けることができる CMS を導

崩れない色名にする 前回「デザインシステムに採用する色を決める5つのルール [http://www.yasuhisa.com/could/article/design-system-colors/] 」を通して、色の名前の付け方や整理の仕方を紹介しました。これを受けてウェブデザイナーの深沢幸治郎さん（@witch_doktor [https://twitter.com/witch_doktor]）が「ウェブサイトに使われる色に固有の名前をつけてみる [http://suikoudesign.com/suikolog/design/2270] 」という記事を書いてくれました。色の命名にまつわる苦労や工夫について読むことができるので、ぜひ参考にしてください。 前回の補足として、デザインシステムにおける色名の付け方の工夫を 3 つ紹介。色の整理をするときの参考にしてください。 色名＝変数 色の名前を付けるのに困っている方は、Kromatic [http://kromatic.thoughtbot.com/] がオススメ。カラーパネルのスライダーを動かすか HEX 値を入力するだけで

始めの一歩としての色共有 ひとりのデザイナーに頼らず、チームで運用できる体制を作るためにも デザインシステム [http://www.yasuhisa.com/could/article/what-is-design-system/] は有用なツールです。しかし、様々な UI コンポーネントと決まりごとが揃ったものを作るのは骨が折れる作業です。デザイナー（もしくはエンジニア）が独自で作って「さぁ使いましょう」と公開しても、使ってもらえるとは限りません。また、デザインシステムをどこで共有して、どのように使われるのかも考慮しなければならず、他社の真似事では済まないこともあります。 作る前から課題が山積みでなかなか手が出せないかもしれませんが、何か始めなければゴールに辿り着くことはありません。そんな現場でデザインシステムを作る場合、色から始めることをオススメしています。 色なんて単純なところは出来ていると思う方は多いと思います。デザイナーであればパレットにしてまとめているでしょうし、エンジニアであれば色は変数にして整理しているでしょう。しかし、現実は少し複雑です。 上図はある大

先進的から最適化へ 3年前、Facebook が今までのニュースフィードを完全に変えた「Paper」というアプリをリリースしました。ネイティブコンポーネントが使われていないオリジナルの UI とインタラクション。今までありそうでなかった新しい操作方法を提案していました。Paper をはじめ、様々な実験的なアプリを Creative Labs としてリリースを続けていましたが、2015 年にラボは閉鎖 [https://techcrunch.com/2015/12/08/facebook-kills-creative-labs-its-internal-incubator-plus-some-of-its-apps/] され、その半年後には Paper も配信停止されました。 今でも Things 3 for iOS [https://itunes.apple.com/jp/app/things-3/id904237743?mt=8&at=1l3vvRc] のように新鮮な UI とインタラクションが生まれる場があるものの、

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

フロントエンドからの影響 昨年開催されたワークショップ「パターンラボ – 柔軟性と拡張性をデザインに取り込む方法 [http://www.yasuhisa.com/could/article/ui-pattern-workshop/]」をはじめ、記事やイベントを通して 維持・管理ができるデザインついて情報発信しています。CMS が広く普及して以来、コンテンツ配信を長く続けるための仕組み作りが模索されているものの、デザインは発展途上です。早く作る、効率よく作るまで議論されるものの、デザインをどう維持するのか、どうすれば最低限の品質を担保できるかまで発展しないことがあります。 1977 年に建築家クリストファー・アレグザンダーの著書「 Pattern Language [http://amzn.to/2gfm74M] 」で、パターンが街作りに柔軟性と拡張性を持たせると説いています。彼に異論を唱える人もいますし、街に個性が失われるという意見にも一理あります。しかし、彼の考え方が今の情報設計（IA）に多大な影響を及ぼしていることは間違いありません。情報や装いに一貫性を持たせることは、作

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

実装寄りの情報だけでは不十分 コンテンツだけでなくデザインも運用していきたいと考えたとき、デザインシステム [http://www.yasuhisa.com/could/article/design-system-language/] を作ることが不可欠です。属人性を省きつつ、最低限の品質を担保することが可能なデザインシステムですが、作りさえすれば組織で広まるのかというと、そんなことはありません。 Salesforce の Lightning Design System [https://www.lightningdesignsystem.com/]、MailChimp の Design Patterns [https://ux.mailchimp.com/patterns] をはじめ、自社でデザインシステムを取り入れるためのインスピレーションは幾つか見つけることができますが、フロントエンド寄りになりがちです。早く Web サイトやアプリを実装するためのガイドラインなので当然ではあるものの、これだけではデザイナーがデザインシステムへの参加が難しくなる場合があります。多くの要因