UXエンジニアの谷です。 「クリエイターHangout」はデザイナー数名のグループで構成される社内のコミュニティです。（Hangoutについては過去の井上の記事をご覧ください。）定期的ににテーマを設けての勉強会や活動をおこなっているのですが、その機会に今回講師として参加させてもらいました。 ▼今期のHangoutのグループ Webフロントエンドエンジニアでもある私が講師を勤めたのは「デザインとエンジニアリング」です。今回はデザイナーとエンジニアのコミュニケーションにおいて、課題となる「色」を主題に「デザインシステム」のトピックを交えておこないました。 1. デザインシステムの定義とは 2. 第1回 色の棚卸し 3. 第2回 & 第3回 色の整理 4. 第4回 コントラストチェック 5. 色と名前を決めることの難しさ 6. デザインシステムはどこまで作り込むか デザインシステムの定義とは 「

事業戦略と組織のビジョンデザイン〜デザイン的アプローチで事業・組織づくりにどう取り組んでいるかのリアル〜

Atomic design is now over 6 years old (which is nuts!). I’m thrilled that all these years later the methodology continues to help teams think of their user interfaces as a hierarchical, interconnected set of components that build real product screens. I thought I’d be sick of talking about this by now, but I’m still passionate about atomic design after hearing so many success stories, as well as w

CSS Utility Classes and "Separation of Concerns"（日本語訳）というTailwind CSS作者の記事を読んだ。そこでは「セマンティック」なコンポーネントと「コンテンツに依存しない」コンポーネントについて言及されていた。 セマンティックなコンポーネントは、 author-bio article-preview のように取り扱うコンテンツの種類をそのまま命名に反映させたものだ。コンポーネントの用途は特定のコンテンツのためだけに限定される。これを特定のコンテンツのためのコンポーネントと呼ぼう。 コンテンツに依存しないコンポーネントは、 media-card card-list button のようにUIパターンを区別するだけの命名がされる。コンポーネントの用途として取り扱うコンテンツの種類を制限しない。これはUIパターンとしてのコンポーネントと呼ぼ

2019/6/1 初夏のJavaScript祭りで使用したスライドです。 Atomic Designの考え方をNuxt.jsのコンポーネント分割に取り入れてサービス開発してみました。フロントエンドエンジニア、デザイナー両面からの視点でやってみて良かったことやハマりどころをご紹介します。

背景筆者が個人的に仕事を受けはじめた会社のフロントエンドのプロジェクトを立ち上げることになりました。 そこでせっかく新しく作る機会があるならコンポーネントの分割の仕方（コンポーネント設計）を明確に定義したいと思いました。 そもそもなんで分け方を定義したいとなったかというと、後からメンバーがプロジェクトに入ってきたときに、スムーズにプロジェクトに入ってもらうためです。 今まで作ってきたプロジェクトでのコンポーネントの分け方は、「2,3回使う場合はコンポーネントに分ける」 「長くなって見通しが悪いコンポーネントは分ける」など曖昧なところもありますがシンプルなものでした。 ただこの分け方をするとコンポーネント自体が大きくなりがちでした。 今のところプロジェクトに関わる人数も少なく、個々のメンバーのレベルも高いため運用できていますが、人が増えた場合や他のメンバーとなった場合は「苦しいのではないか？

がいた色4/26に開催されたDIST.26 「Webサービスの個性を支えるデザイン」でのLTをさせてもらったので、その内容と補足をnoteにしたためる。 Webサービスにおける「色」Webサービスのデザイン、開発をしていて「色」を何も考えずに決めるということはおそらく無い。もちろん創業者の好みとかそういった決め方もあるかもしれないが、何かしらの理由はある。一方、サービスの利用者にとっても色がサービスを使う動機となることもある。 色が人に及ぼす影響として下記のような研究結果があるらしい。 人は90秒以内にその製品が好みかどうかを判断し、その基準の90%は色だけに基づく。 The psychology of color in web design - 99designs また色相ごとで人に与える心理・感情、意味も様々であり、その側面でどの色を選ぶかを考えることもできる。Canvaの提供する色に

この記事はGoodpatch UI Design Advent Calendar 2018の10日目の記事です。 「デザインガイドライン」と聞くと、どのようなアウトプットイメージを持つでしょうか。 実際に検索するだけでも、VIの使用ルール、トンマナ、UIコンポーネントの設計思想など、多くの事例を見ることができます。これらのデザインガイドラインが作られる主目的は、ブランドやアウトプットの統一性を図るためですが、「文言」もその役割を担う要素の一つです。 ここでは、ソフトウェアにおける文言のガイドラインについて、その目的や具体的なまとめ方を記したいと思います。 ブランドらしさを表現する文言複数人のUIデザイナーがいる、比較的規模の大きなソフトウェア開発に携わる中で、アウトプットのトーンがばらつくことは何度か課題として挙げられていました。文言も例外ではありません。どのような言葉を発し、どのような言

こんにちは、クックパッド株式会社デザイナーの藤井(@kenshir0f)です。 業務では主にKomercoというサービスのデザインを担当しています。 Komercoは料理が楽しくなる料理道具やうつわ、調味料や食材など料理が楽しくなるモノが買えるアプリです。 料理に興味がある方はぜひ触っていただけたら嬉しいです。 さて、今日お話しする内容は新規事業でアトミックデザインを導入したお話です。これから導入を考えている方や、すでに導入している方の参考になればと思います。 Komercoでは立ち上げからリリースまでの間、サービスのデザインを一人で担当していました。 開発初期ではまだサービスの名前すら決まっておらず、ブランディングからロゴ、アプリの体験設計、インタフェースや開発用のデザインガイドラインなどを並行で作業する必要があり、上手に効率化を測りながらデザインしていました。 また、アプリは購入用、出

命名スルこと日本語には漢語由来の熟語がいくつもありますが、日本人からするといくらか記号的に見えてしまうことがあります。とはいえ漢字の意味を知っているので読んで差し支えはないのですが、それらの字の間に「の」を挟みこむことで記号的な記述であった熟語を和語的な言葉として読むことができるようになります。例えば「命名」という熟語でそれを試すと「命の名（いのち の な）」という具合になりますが、「命名（スル）」という言葉を思い浮かべるよりかは「命の名（を付ける）」の方が、より一層にある概念に命を吹き込む行為であることが強調されるので、それがとても尊い行いであると改めて理解することができます。 命に名前を与える、あるいは名前を与えて命を吹き込む、すなわち命名スルという行いは、名付けによってその存在の意味性を明らかにすることなのだろうと考えられます。親が生まれた子にまず与えるのは名前です。名前を与えること

2018年11月24日のFRONTEND CONFERENCE 2018で発表したセミナーのスライドです。EC-CUBE 4の管理画面をデザインした経験を振り返り、そのプロセスについてお話しました。

本稿は（序）（破）（Q）のシリーズの3番目の記事になります。 本稿では前回（破）で説明したAtomic Designを導入する際に工夫した点をふまえた実装例をJSフレームワークを使用する場合と使用しない場合の２つの場合について紹介します。 シリーズ（序）ではAtomic Designの概要 シリーズ（破）ではAtomic Designの導入に際して工夫した点 について説明していますので、そちらをご覧ください。 実装例題材 下のサイトテンプレートを題材に実装していきます。 https://html5up.net/prologue シチュエーションとしては、デザイナーからもらったデザインカンプをエンジニアが実装する想定で説明します。 コンポーネントの分割 エンジニアはデザインカンプをAtomic Designのコンポーネント単位に分割していきます。 コンポーネントの分割フロー図は（破）で以下の

最近なにかと話題になっているデザインシステムについて、実際に取り組んだ際の学びを記していこうと思う。 始めに述べておくが、デザインシステムを構築することは想像以上に泥臭いことの積み重ねであった。 デザインシステムとはデザインシステムとは、その名の通り、デザインの仕組みである。 デザインシステムとして、代表的でよく取り上げられているAtlassian Design Guidelines。また、ガイドラインとして知名度の高いHuman Interface GuidelinesやMaterial Designも当てはまるだろう。 何が揃っていれば、デザインシステムと成り得るのか、未だ定義されていない。 むしろ、私は定義する必要はないと思っている。システムというのは概念に近く、そのときの組織やプロダクトの状況に合わせてつくりあげていくものだからである。 ただし、デザインシステムをつくる目的だけはハ

｜DMM inside

6/29（金）に開催されたDevLOVEのAtomic Design回に行ってきました。 devlove.doorkeeper.jp 『既存のフローからアップデートする アジャイル・デザインフロー』というタイトルで、アジャイル開発を進めるうえでのUI変更に強いデザインフローについてのお話でした。 Atomic Design本には結構コードが書かれているんだけど、今回はコードの話ではなく、何故Atomic Designの考え方が必要なのか、Atomic Designの構造をどう考えていけばいいか、@ygoto3_ さんが実践してるデザインフローができるまでのステップの話がありました。 内容はスケッチノート置いておきます。 どう分割するかがいまいち理解できていなかったけど、ユーザーの行動と合わせて責務で考えるのがすごく分かりやすかった。スケッチノートに書いてる今までのデザインフローでまだやって

「コデアル」という求人サービスのデザインシステムを作ってみました。CIリニューアルに伴う全スタイル＆コンポーネントの刷新、エンジニア＆デザイナー間の協業、そして約3ヶ月運用してみた感想をつづってみます。 実際に使っているドキュメント、Sketchファイルはこちら↓ ・Codeal Design Guideline ・Codeal UI Kit.sketch ・Sketch Tips for Codeal Design Guideline Codeal Design Guidelineの中身はこんな感じ。 1. デザインシステムとは組織やサービスの形態によって解釈は分かれると思いますが、私はデザインシステム＝ブランド、設計、開発をつなげるガイドラインだと認識しています（引用：結局デザインシステムは何なのか） スタイルガイドやテンプレートだけではなく、それらをチームでどう活用するかを言語化して

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

UIデザインのお仕事を手がけるようになり、デザインガイドを作成する機会をしばしばいただけるようになりました。 また、Sketchのシンボルを用いてサイト内での使用色を管理する手法を積極的に取り入れるようになったことや、CSSコーディングの場面で繰り返し使う色をSassの変数に割り振って管理する場面が増えたこともあり、これまで以上に色に名前をつけて管理する機会が増えてきたと感じています。 その中で生じる新しい悩みは色の命名です。これまで私は色に名前をつける段で深く考えずに「red1, red2…」といった「おおよその色相+番号」という命名を試したり、またCSSフレームワークによくある「primary, secondary, success…」といったような「役割」ベースの命名を施したりしてきたのですが、それではうまくいかないケースも生じてきました。 これまでの色の命名の問題点 目下のプロジェ

フロントエンドの中でも、JS書くプログラマと、CSSを書くマークアップと、デザインカンプを作るデザイナで、コンポーネントという概念がズレる。だいたいこれらが一人だったり兼任だったりで1~2レイヤーの開発ステップになるが、完全分業だったり人が多くなると混乱の元になる。 誰かが決定的に間違ってるというつもりはない。正直、どっちかというと本来のデザイナ側の用語定義に倒した方がいい気がしているが、プログラム上の都合もいろいろ混ざってきて、話が簡単ではない。 自分の理解が間違ってる可能性もある。この記事はレビューをもらうために書いている側面もあり、指摘されたら追記していく。 読んだもの。 Atomic DesignとCSS設計 - Atomic Designとは何か | CodeGrid Atomic Designの考え方と利点・欠点 – wkr. Atomic Design の大雑把な理解 基本的