nlog

とめどなく流れるよだれ

デザイン原則をつくって「私たちが考える良いデザイン」を揃える

design

「デザインシステムを学ぶ 31 日」の 3 日目。今回はデザインシステムの前準備、デザイン原則について。

なぜデザイン原則は必要？

チームでデザインの善し悪しを判断するためにデザイン原則は必要だ。同じチーム内でもいろんな考え方を持つ人がいる中、原則をつくることで「これが私たちの考える良いデザイン」という認識を合わせやすくしておく。

そして、原則を守ってデザインを続ければ、やがてそれは外部からブランドと呼ばれるようになる。一貫された見た目や操作感がサービス全体の印象になるからだ。

デザイン原則があれば、これからつくろうとしているデザインシステムで役立つだけではなく、デザインレビューなど、様々な場面で役立つことになるだろう。

デザイン原則とは何を指すか

デザイン原則とは「チームで考えた "デザインのあるべき論" がまとめられたドキュメント」である。

たとえば Android デザインの原則 には、サービスを操作したときにユーザーに感じてほしいこと、そのために必要な設計方針がまとめられている。

また、デザイン原則ではあまり具体的な話はしない。Design Principles FTW や Design Principles にはいくつかデザイン原則のサンプルがあるが、どれも短い文章とそれを補足する 1 段落程度の文章で各原則が書かれている。あくまで原則なので、デザインを無理に縛り付けるようなことはしていない。

1 人でもデザイン原則は必要？

必要だと思う。

過去と現在の自分は考え方はよく違っていたりするが、デザイン原則のようにひとつ指標があれば、それをもとにして自分の考えを振り返ることができる。また原則を常に参照するようにしておくことで（本当はこれをデザインシステムでやりたい）、個人の制作物にも一貫性をもたせることができる。

デザイン原則のつくり方

実際チームでデザイン原則をつくるやり方を近くで見ていると、以下のようにしていた。

  1. デザイン原則の役割をチーム（または決裁者）に理解してもらう
  2. 原則を反映させたい組織やサービスを思い浮かびながら、それがどのようなデザインになっていれば理想かチームでアイデアを出し合う
  3. 話し合ったときに出てきたキーワードをもとにして原則を一度まとめてみる
  4. チームに共有しながら原則の内容や文章について推敲し、原則を完成させる

個人でデザイン原則をつくるときも 1 人でやるだけで基本は一緒。

参考

余談

デザイン原則はデザインシステムと切り離して記事にしても良かったかもしれないな。

Semantic UI Doc ( Collections - Grid ) を読む

css

Semantic UI の Grid を読んだ。グリッドにテーマはない。

グリッドはサイトのレイアウトを格子状に整理して並べるのに利用する。CSS の技術としては Flexbox を使っており、グリッドのセル同士の余白は padding を利用して空けている。また、セルの持つ余白がグリッド上下左右の余白に影響を及ぼさないように、グリッドは周囲に負のマージンを持っている。

よくあるのは 12 列のグリッドだが、Semantic UI のデフォルトのテーマでは 16 列を採用している。テーマ変数をの値を操作することでこの列数は変更可能。

セル同士の余白を padding でとっているため、グリッドのセルに内側の余白をもたせたい場合は 1 つ HTML 要素をネストしなければいけない。

<div class="ui three column grid">
  <div class="column">
    <div class="ui segment"> <!-- セルの内側に余白をもたせたい場合は、要素を追加してその要素に余白を持たせる -->
      <img>
    </div>
  </div>
   ...
</div>

グリッドはネストしたり、色つけたり、境界線をつけたりすることができる。

equal width を使えば行内を均等に分割した幅のセルがつくれる。このとき、子要素に当たる列の幅指定はいらない。

<div class="ui equal width grid">
  <div class="column"></div> <!-- 1 行を 3 等分した幅になる -->
  <div class="column"></div>
  <div class="column"></div>
  <div class="equal width row"> <!-- 行を指定したので、ここで改行 -->
    <div class="column"></div> <!-- 1 行を 2 等分した幅になる -->
    <div class="column"></div>
  </div>
</div>

グリッドの中身を中央に配置することもできるし、セルをそれぞれ左右の端に配置することもできる。

グリッドをレスポンシブに動作するが、固定幅で表示することもできる。

ここで書いたことの詳細は Grid (Definition) のページにまとまっている。

デザインシステムとは

design

昨日に続いて 「デザインシステムを学ぶ 31 日」の 2 日目。

デザインシステムとは

ブランドやプロダクトの一貫性を保つため、デザインをシステム化したもの。UI ライブラリー、フレームワーク、スタイルガイド、文章ガイドライン、ワークフローなどはこのシステムの一部にあたる。

デザインシステムがあるとどうなる？

つくったデザインに一貫性が生まれる。プロダクト内のどこかで「ボタン」の見た目を学習したユーザーは、別の場所でも同じようにボタンを発見・認知することができる。このような体験をユーザーにさせたいときにデザイナーはデザインで迷わなくて済むようになる（すでにコンポーネントがあれば既存の選択肢から選ぶだけ）。

そしてよくできたデザインシステムはデザイナーとエンジニアのコミュニケーションコストを下げる。Sketch などで作成したデザインデータとプロダクトのコードがシームレスにつながり、一部はデザイナーの意図した変更をエンジニアを介さずにプロダクトに反映させることもできるだろう。また、コンポーネントの選択と配置で基本的なデザインができるようになるので、エンジニアがデザインできる範囲も広がるはずだ。

デザインシステムがデザインシステムであるために

システムの前に原則がなくてはいけない。システムを構築する上で判断軸が必要になるため、原則なしでデザインシステムはつくりにくい。

また、システムをつくったら知りたい情報に素早くたどり着けるようになっていなければいけない。そしてたどり着いた情報は正確でなければいけない（バージョンが古くてもダメ）。これを実現させるためには情報が一箇所で管理されていることが理想であり、この考えは Single source of truth と呼ばれている。 

最後に、「デザインシステム」なのでガイドラインを文章にまとめただけではいけない（我々はすでにドキュメントだけでルールが守れないことを知っている）。ルールは可能な限り仕組み化し、自動的に保守・運用できるようにしていく必要がある。

デザインシステムをつくるには何が必要か

原則と仕組みが必要。今思いつくのは以下の通り。

  • デザイン原則 ... システムをつくるにあたって指針となる考え
  • 言葉のトンマナをまとめたドキュメント ... ブランド全体の印象をつくるもの
  • 変数 ... 色、タイポグラフィなどブランドの印象をつくるもの
  • コンポーネント ... ブランド全体、またはプロダクトごとに用意されたデザインパーツ

これらを用意してワークフローに取り入れることでシステム化したデザインが完成する。

じゃあ具体的に何を、どうするの？というのをこれから学んでいく。

CSS 関連の記事を眺めて

css

ワンランク上のコーダーは万が一の配慮も欠かさない、リンク切れの画像要素をスタイルするテクニック - コリス

つい最近考えることがあった。パスの入力ミスや影響範囲の確認漏れはないほうが良いけど、絶対ないとは言い切れない。そういったときにリンク切れ画像にスタイルを定義しておけば余計に慌てずに済む。

CSS のポイントとしてはブラウザが標準で出してくるリンク切れ画像を擬似要素で置換してる点かな。これだけで見栄えがどっと変わる。リンク切れ画像は置換要素で外部からリソースが読み込まれるため、疑似要素が通常使えないみたいなので、スタイルを当てるときは注意が必要。

 

CSS Grid — Responsive layouts and components - Medium

縦横比の違う画像を上から順に敷き詰めたグリッドのつくり方解説。各ステップにイメージが差し込まれていてわかりやすいから、時間のあるときに試してみる。

 

コーディングをするときに鼻血がでるほど便利なwebツールリスト(随時更新予定) - Qiita 

書いたコードをさっと確認したいとき、コードレビュー中にコンパイル結果が知りたいときがあるから、SassMeister はきっと役に立つ。

 

5000人に聞いた、2018年最先端のフロントエンドツールはこれだ - Qiita

いくつか新しく知ったデータがあった。

  • Stylus、PostCSS の使用経験がある開発者はそれなりにいるが、現在利用している CSS ププロセッサーは Sass が断トツ多い。これは一回他のプリプロセッサーに心変わりしたけどやっぱり Sass に戻ってきたのか、これから試そうとして他のプリプロセッサーを見ているのかどっちだろう。多分前者だと思っている
  • フレームワークは Bootstrap が一番人気。ついでカスタム（自社フレームワーク？）。他には Foundation、Materialize、Bulma、Semantic UI、Pure CSS が使われている

CSS Gridベースのを作成できるジェネレーター・「CSS Grid Layout Interface Builder」 - kachibito

CSS グリッドのジェネレーター。あの難解なコードを書くのはつらいから、セルのサイズなどを決めて配置したい複雑なレイアウトをつくるのに重宝しそう。

デザインシステムを学ぶ宣言と、今感じるデザインシステムのメリット・デメリット

design

「デザインシステムを学ぶ 31 日」の 1 日目。

1人design system advent calender を見てやる気が湧いたから、「デザインシステムを学ぶ 31 日」という連載をやる。記事は毎日 17:00 毎日 17:00 以降に投稿予定。

個人・チームともにデザインシステムの必要性を感じていた。ガイドラインなどのドキュメントだけでは一貫したデザインを保ちづらいため、デザインとコードをより近づけるための仕組みがほしい。

まわりには同じ意見を持つ人もいて、そのためデザインシステムは一部進みつつある。しかし、自分でデザインシステムの全体像を把握できていないので、システムを完成させるまでの道のりで自分（または自分たち）が今どの地点にいるかわかっていない。今回の連載を通して、残りの作業を明確にし、今後のデザインのシステム化をスムーズに進めたい。

連載のゴール

個人のデザインのシステムはメリットが薄いと思うけど、練習を兼ねてつくる。

  • 学びながら個人（ @namikuguri ）のデザインのシステムをつくる
  • デザインのシステムについて学んだことをひとつにまとめる

連載前に感じるデザインシステムのメリット・デメリット

今感じているデザインシステムのメリット・デメリットをまとめる。一通り学んだあと、考えが変わった点はないか振り返る。もしかしたら学び終えたあと、デザインシステムは運用が大変だからいらない、となってるかもしれない。

  • メリット
    • 一貫性のあるデザインをユーザーに提供できる
    • 一貫性のあるデザインはデザインをつくりやすい
    • デザインをまとめることでエンジニアとのコミュニケーションコストを下げる
  • デメリット
    • 最初の仕組みづくりに時間がかかる
    • 本当に使えるシステムをつくるには触れる範囲が広く、デザイナーだけではおそらくつくれないので人手が必要
    • つくったシステムの保守・運用にコストがかかる

Semantic UI Doc ( Collections - Form ) を読む

css

Semantic UI の Form を読んだ。フォーム にテーマは 4 個ある。

  • フォームは項目と入力フィールドのセットを構造化して見せるのに役立つ
  • コンテンツには項目と入力フィールドをセットで表示する Field と、Field のグループを表示する Fields 、そして各入力フィールドがある。用意されている入力フィールドは以下の通り
  • 状態がいくつかある
    • 読み込み中 ... ローディングイメージを表示する
    • 成功、エラー、警告 ... 意味の照らし合わした色でメッセージを表示する
    • フィールドエラー ... 入力フィールドごとにエラーを表示する
    • 無効フィールド ... 入力フィールドごとに無効状態を表示する
    • 読み取り専用フィールド ... 入力フィールドごとに読み取り専用状態を表示する
  • 見た目のバリエーションもいくつかあり、サイズ、フォームの幅、反転色、インラインフィールド、必須オプションマークの指定ができる

Semantic UI Doc ( Collections - Breadcrumb, Form ) を読む

css

Breadcrumb

Semantic UI の Breadcrumb を読んだ。パンくずリストにテーマはない。

.ui.breadcrumb でパンくずリストを表示できる。リストアイテムの区切り記号はスラッシュだが、アイコンフォントなどで別の記号に変更することもできる。

リストアイテムは通常テキストかリンクテキストを含めることができ、またアイテムのアクティブ状態を示すためのクラスもある。

パンくずリストはサイズ変更もできる。

Form

Semantic UI の Form を読んだ。フォームにテーマは 4 個ある。

フォームは入力欄とラベルを構造的に見せるのに使う。

<form class="ui form">
  <div class="field">
    <label> ... </label>
    <input type="text" name="..." placeholder="...">
  </div>
  <div class="field">
    <div class="ui checkbox">
      <input type="checkbox" tabindex="0" class="hidden">
      <label> ... </label>
    </div>
  </div>
  <button class="ui button" type="submit"> ... </button>
</form>

上記には以下のフォーム部品が含まれている。

  • .ui.form
  • .field
  • .ui.checkbox

これら以外にもセレクトボックスや、トグル型のチェックボックスなどがある。

フォームフィールドにはラベルと入力欄を含むことができる。複数行のテキストは textarea 要素で表示することができ、高さは rows 属性で変更できる。チェックボックスやラジオボタン、ドロップダウンリストは JavaScript を使ってユーザーエージェントの見た目を変更することもできる。

状態もいくつかあり、読み込み中、フォーム入力の成功・エラー・警告、フォームの無効状態、読み取り専用の見た目のフォームなど。

フォームには見た目のバリエーションがあり、サイズを変更したり、入力欄の幅を調整したり、反転色の見た目にしたりできる。また、フォーム全体ではなく、フィールド（ .field ）やグループの見た目を変更するバリデーションクラスも用意されている。