1. resize.fm
  2. #162 デザイントークンの現在地
2023-12-08 1:22:55

#162 デザイントークンの現在地

「デザイントークンのつくりかた」という本を読んで、デザイントークンを設計する勘所や難しさ、デザインシステム周辺ツールの対応など2023年末時点の現状について話しました。

📝ShowNote: https://resize.fm/ep/162-design-token-2023

おたよりお待ちしてます💁‍♀️
おたよりフォーム(Googleフォーム): https://forms.gle/hkHbCpdTfe54MSyq9

サマリー

resize.fmの最新エピソードでは、音楽のトーンを変える話や、ティーンエイジエンジニアリングのサンプラーについて話されています。このエピソードでは、デザイントークンについてのさまざまな話題が取り上げられています。デザイントークンのディスプレイやインターフェースについて言及しながら、自動車やバイクの購入に対する思いなどについても話し合われています。デザイントークンの作り方について述べられた本を読んで、デザイントークンの必要性について考えることがあります。デザイントークンの設計は、マルチブランドな会社や関連のない複数のプロダクトを持つ会社にとって重要です。デザイントークンの設計やキーの構成方法についても考えています。W3Cのデザイントークンフォーマットモジュールは、草案として策定され、デザイントークンの共有やエキスポート・インポートがより簡単になる予定です。デザイントークンの設計では、共通項を見つけてグルーピングし、階層化することが重要です。色の設計では、最初に全ての色相と明度を定義することがバランスを取る上で有効であることがわかります。UI系のライブラリでは、カラースケールやタイポグラフィー、余白などの設計を決めるためのツールが提供されています。また、iOSでの日本語フォント表示の問題やラインハイトの設定についは悩みの種です。デザイントークンの現在地では、命名やファイルの形式についての話が主になされています。具体的には、Adobeのデザインシステムでの命名規則やJSONを用いたデザイントークンの定義方法などが説明されています。W3Cに関わることの重要性やデザインツールでのトークン管理ツール、デザインシステムの重要性についても話がされています。本山さんのデザインファイルを通じて、エンジニアリング的な視点で実装しやすいデザインが作れるデザイナーの背景についても話されました。また、デザイントークンの進化やデザインシステムを設計する際のおすすめの本についても触れています。

目次

音楽のトーンを変える話
Takaya Deguchi
こんにちは、Deguchiです。
kudakurage
こんにちは、Motoyamaです。
resize.fmは、MotoyamaとDeguchiが最近気になっているサービスやデザイントピックスを取り上げてのんびり話すポッドキャストです。よろしくお願いします。
Takaya Deguchi
お願いします。
kudakurage
3年終わって、4年目に入って、少し変えたの気づいてますか?
Takaya Deguchi
何がですか?
kudakurage
気づいてないですか?
Takaya Deguchi
はい。
kudakurage
いや、音楽変えたんですよ。
Takaya Deguchi
ああ、そういうことね。
kudakurage
え?気づいてました?
Takaya Deguchi
いや、それは分かりますけど。この最中に変えたのかと思いました。
kudakurage
いやいや、どういうこと?この最中に変えるって。
Takaya Deguchi
冒頭の挨拶、実は変えてたとか。
kudakurage
いやいや、それは変えてないんですけど。変えようかなと思いつつ、変えてないんですけど。
何かちょっと変えようと思って。
特に意味もないんですけど。
3年目終わったっていうタイミングで、
ちょっと音楽変えてみようと思って。
Takaya Deguchi
ああ、そういうタイミングだったんですね。
kudakurage
音楽変えたんですよ。
Takaya Deguchi
うん。それは分かりますけど。
分かってます。
kudakurage
今回も前と同じプレミアムビートから、いろいろこの曲いいかなとかいろいろ探して、
短めのジングルで結構いろいろ探すとか、いろいろ探すとなかなか見つからなくて、いろいろ探してたんですけど。
うん。
まあでも、なんかね、2つ実は候補があって、今回採用したやつともう1個あったんですけど。
うん。
で、最初はそのもう1個、今回採用しなかった方にしようかなと思って、それ入れて編集してたんですよ。
うん。
そしたら、なんかね、その曲がね、結構明るい曲なんですよ。
うん。
なんかね、ちょっと、音色がちょっと変わるしいいかなと思って。
うん。
入れてみて、まあ最後まで編集したんですよ、本当に。
うん。
だけどなんか、ちょっともう1回一応聴いてみようと思って、その出だしと最後との部分、音楽入るから。
はいはい。
聴いてみたら、そのなんか、ギャップがすごすぎちゃって。そのなんか音楽めっちゃこうさ、めっちゃ明るい感じでさ、なんかこう、いくぜーみたいな感じでさ、こう流れるのに、こんにちは出口です。こんにちはお手当てです。みたいな、なんかトーンが。
トーンがちょっと違いすぎちゃって
そこの
これはちょっと
なんかおかしいなって思って
でまあやめてもう一個の今
採用してる方にしたんですけど
結局
まだこっちの方がちょっとアンダーグラウンド感
あるからなんか
なんかちょっとまだ合うかなと思って
Takaya Deguchi
じゃないですかその方
kudakurage
いやでもなんかそのねトーンのギャップが
違いすぎて
なんか面白いなと思って
それが逆に
Takaya Deguchi
僕今
こんだけこの出だし毎週やってんのに
今一瞬どういう出だしだったっけって忘れましたね
kudakurage
どういうこと
Takaya Deguchi
いやちょっと
風邪ひいてただ
頭ぼーっとしてんだなって今
それやって気づいたんだけど
あれ最初出だしなんだっけって
一瞬思っちゃった
kudakurage
いやでも今回の曲も僕は結構
気に入ってる曲だから
なんかいいなぁとは思ってるんですけどね
まあでも
なんか割と3年ぐらいさ
前の曲でやってたから
多分ちょっと最初なんか違和感僕もあったんだけど
まあでも慣れてくれば
全然こういうもんかって感じはしてるんですけど
Takaya Deguchi
毎年変えてもいいんじゃないですか
kudakurage
というか僕本当は
あの曲作りたいんですよね
本当は専用のというか
ビサイズエヘムの
テーマ曲みたいなの作りたくて
でまあ
僕が作るのでもいいんだけど
まあなかなかね難しい
部分もあるから
なんかあの最近
あのクランの時にも出てもらった
神の小屋さんが結構いろいろ
音系
ETMなのかBPMなのか
あの辺やってるから
なんかあの辺でちょっと
お願いして一緒に作りませんかって
やりたいなと思ってるんだよね
Takaya Deguchi
いいっすね
オリジナルいいですね
kudakurage
そうそう
なんかいい感じのやつをね
ぽちぽち作りたいなみたいな
Takaya Deguchi
ちょっと僕もそういうの興味あるな
kudakurage
うん
なんかね最近もなんだっけ
Takaya Deguchi
ティーネイジ
kudakurage
ティーネイジエンジニアリング
Takaya Deguchi
あれいいっすよね
サンプラーね
kudakurage
そうそうそう
KO2だっけ
あれめっちゃ欲しくなりました
Takaya Deguchi
いやー僕もなんかこう音楽
楽器とか全然やってないけど
あのサンプラーは可愛くて
欲しくなりましたね
kudakurage
あれはねめっちゃ欲しくなった
なんであんな
ただの板にボタンがいっぱい
ついたものが欲しくなるんだろうと思ったけどね
Takaya Deguchi
いやーねピコピコ
鳴ったりするだけなのに
何か欲しくなるんだろう
kudakurage
あれはちょっと欲しくなったね
高いからちょっとなかなか
高い
ドルだから
ちょっと高いっていうのもあるし
送料もちょっと高いとかあるじゃないですか
やっぱり
Takaya Deguchi
物をドルベースで見ればそんなめっちゃ
手が出ないっていうわけでは
kudakurage
なんか買ってみてもいいかなってちょっと思えるぐらいの値段ではあります
そうそうそう
そうなんだけど
なんかねこう
気軽にとはいかないぐらいの感じなんだよね
やっぱりちょっと
Takaya Deguchi
なんか結構サンプラー使ってかっこいい音楽作ってる人
いっぱいいるし
なんかそういうインスタとか
動画見たりするけど
まあでもなんか真似なかなかできないよな
っていうのも
冷静になると思うんだけど
あーでも300ドルだったら
ちょっと買ってもいいかもなとか
思ってしまう
kudakurage
そうね
いやちょっとねこれ僕もね
欲しいなってずっと思ってるのね
Takaya Deguchi
いやさすがですよね
ティーネイジ
kudakurage
いやこれはほんと
かっこいいおしゃれめっちゃおしゃれ
だなと思った
Takaya Deguchi
かっこいい
かっこいいこれは
kudakurage
ちょっとだから
今年はじゃないか今年はもう終わりだから
この1年の間になんとか
オリジナル曲作れないかなって
ちょっと思ってるんだけどね
Takaya Deguchi
まあ確かにねそこを目的にする
ティーンエイジエンジニアリングのサンプラー
Takaya Deguchi
目標にすればよいのか
kudakurage
うんうん
Takaya Deguchi
まあマジね
正当化をするっていう
kudakurage
これを買って
なんか神の子屋さんのところに持ち込んでって
ちょっとポチポチやって
作れないかなとか
Takaya Deguchi
でもこれでかっこいいの作るの相当センスいるだろうな
と思うんですよね
kudakurage
なんかでも
最近なんだっけあの
キングヌーの
常田さんとかもなんか
なんかで話してたけど
もうなんか
ずっともうなんか面白がって
ずっとなんかこう重ねまくる
音を入れまくるみたいな
なんか最近あのスペシャライズ
スペシャルですかっていうさ
あの
事実回線のテーマ曲
もうなんか
やってる作ったけどあれもなんかもうなんか
160個か
それぐらいの音を使ってやってる
みたいななんか
もうだからひたすら部屋に
こもってなんか
もういじり続けてるみたいな
その1曲に対してね
みたいな話してたから
まあなんかだからそういう感じで
もう根気よく常にこう
いじりまくってればなんか
面白くなってくんじゃないかなって思ったりして
Takaya Deguchi
キングヌーの人がいるとだいぶ変態的だと思うから
なんかこう
次元が違う話のように聞こえるけど
kudakurage
まあまあまあまあ
でもなんか
結構いろいろ重ねてたら
それっぽくなるってところあるから
音楽ってなんか
Takaya Deguchi
あのあれ
雷のyoutubeのチャンネルの
出だしも
自分たちで作ってた
あれも結構かっこいいっすよね
kudakurage
なんかいい感じの曲だよねあれも
あれもなんかいい感じに
なんかこういろいろ入れてけば
なんかそれっぽくなってきたなみたいな感じで
自作PCのケース作りなど
kudakurage
どんどん面白くなってくんじゃないかな
なるほどね
なんか僕もすごい昔に
そういう音楽をポチポチ作ったりとか
まあギターも弾けるからギターやったりとかしてたけど
なんかねその
単純に一個の音だけで
例えばピアノだけでみたいなのやると
なかなかこうねやっぱり
厚みがないからさなんか
微妙だなみたいな感じになっちゃうところもあるけど
いろいろ音入れてくとなんか
結構テンション上がってくみたいなさ
とこあるから
Takaya Deguchi
じゃあ買うか
kudakurage
買うか
ちょっと音楽作っていきたいな
Takaya Deguchi
めちゃくちゃ売れてましたよねあれ
なんか今ソウルアウトしてるし
kudakurage
あそうなんだよ
ソウルアウトしてんだ
なんか限定セット
なんかセットみたいなの売ってたよね確か
スピーカーみたいなのとかと一緒に
Takaya Deguchi
あれもね気になるんですよね
なんか
アナログレコード
DJみたいなやつがついてて
ちょっと巻き戻せるみたいなね物理的に
kudakurage
そうそうそうそうそういうやつね
面白いよね
プロダクトとしては
やっぱTNAG
Takaya Deguchi
エンジニアリングどれもいいね
いやいいっすよね
kudakurage
なんかこのKO2に合わせてさ
なんか変なスポーツウェアみたいなの作ってないな
Takaya Deguchi
作ってた作ってた
kudakurage
ボクシング
ボクサーパンツみたいなやつとかさ
Takaya Deguchi
なんか
あと地味に気になってんのが
あの自作PCの
ケース作ってるんですよね
kudakurage
あそうだねあったね
Takaya Deguchi
これもかわいいなと思って
オレンジ色
メタリックな感じの
kudakurage
普通になんかこれも
なんかだから箱が
これもなんかだから箱が組み合わせるような
組み合わせるっていうの多分組み立てる感じでね多分
そう
なんかいっぱいパネルみたいのが届いて
Takaya Deguchi
それをなんか
kudakurage
そう基地みたいなやつね
Takaya Deguchi
カチカチプラモデルみたいになんか
あと机も作ってますからね
うん
kudakurage
机もねよくPVPVっていうのね
あのなんかねそういう動画になんかよく映ってますよね
Takaya Deguchi
なんかこの机
前カバンを買ったんすけどTNAGの
kudakurage
あそうなんだ
Takaya Deguchi
うん
結構使い勝手良くてよく使ってますね
kudakurage
へーTNAGのカバン
Takaya Deguchi
トートバックみたいなやつ
kudakurage
はいはいはい
いやなんかでもほんとKO2は欲しいなと思ったね
Takaya Deguchi
うん
あとマイクも欲しいんだけど
でもマイク今それなりにいいの使ってるからな
みたいので踏みとどまったな
kudakurage
まあそうだね
まあ僕もそうだね
まあいいの使ってるから
まあ別にいいかって思ったけど
マイクは
まあでもなんか変わってるよねちょっと
あんまりこういう形のマイクないよなっていう
Takaya Deguchi
そう
モバイルレコーダー的なやつも
出してましたよね最近
kudakurage
モバイルレコーダー
Takaya Deguchi
なんか外で収録する用の
みたいな
kudakurage
そんなのあるんだ
Takaya Deguchi
なんか出てた気がするけど
そういうポッドキャスター向けの
ポッドキャスター向けというか
そういう収録用の
kudakurage
これかな
Takaya Deguchi
TP7ってやつ
なんかちょっとカセットテープを
カセットテープのレコーダーを
今風にしたみたいな感じの
コンセプトの
実際くるくる回る部分があるんですよね
デザイントークンの機能とデザインについて
kudakurage
これやっぱり回るんだ
面白いね
いやなんかでも
分かるなでも
いいね
いいね
Takaya Deguchi
いいっすよね
kudakurage
いいね
買って使うかって言われてると
うんってなっちゃいそうだけど
Takaya Deguchi
そうね
kudakurage
物として良さそうなんだよね
物として持っておきたいみたいなのあるよね
Takaya Deguchi
しかもアプリもあるんだ
書き起こし用アプリみたいのがあるんですね
自動書き起こしアプリみたいな
やっぱこういうとこがすごいよな
ハードとソフト両方
kudakurage
これしかもあれなのかな
回るのこれ
円盤みたいなのついてる
ついてるっていうかさ
クリックホイールみたいな
回るんだと思って
クリックホイールみたいなのついてる
クリックホイールっぽいインターフェースなんじゃないかって
ちょっと今写真見てて思ったけど
Takaya Deguchi
初代iPod的な
kudakurage
そうそうそうそう
だからさあのさっきのさ
レコードをぐるぐるって回すみたいなさ
これもなんか戻せたりするとかさ
例えば
Takaya Deguchi
そういうことかな
物理的に回って戻せるのかと思ってたけど
UI的にそれをやるのかな
kudakurage
でも回りそうな雰囲気もあるね
Takaya Deguchi
雰囲気を醸し出してるから
kudakurage
だからなんか写真見るときに
見るとさなんかこう回ってるから
そのなんか柄がちょっと傾いてたりするからさ
いろんな写真によっては
Takaya Deguchi
いやそうですよね
kudakurage
だから多分回るんだよね
Takaya Deguchi
ロゴみたいなのが
うんやっぱ位置が変わってるから
kudakurage
位置変わってるもんね
Takaya Deguchi
うん
kudakurage
ちょっと動画がないから分かんないけど
Takaya Deguchi
あれが紙の白?
まだ発売してないのかな
kudakurage
あでも回ってる回ってる
今なんかビデオ
ビデオ見たら回ってた
Takaya Deguchi
へぇ
kudakurage
回ってるわ
くるくるって
いいねなんか
Takaya Deguchi
いやぁ
kudakurage
いいよ
あーすげぇいい
あーすげぇいいって
多分伝わんないけど
いや今なんかね
あのその数字がさ
カウントが増えてくじゃないですか
そこもなんかね
すごいなんかパチパチ切り替わるんじゃなくて
Takaya Deguchi
あー
kudakurage
なんか数字が
Takaya Deguchi
UI
kudakurage
そうそう
Takaya Deguchi
UIね
kudakurage
くるくる回るみたいな
なんか
うん
ディスプレイのところが
可愛いね
Takaya Deguchi
いいですね
ティーネイジは
kudakurage
うん
いやでもKO2ちょっと欲しくなったねやっぱり
Takaya Deguchi
うん
多分買っちゃう気がするな
どっかのタイミングで
はははは
kudakurage
ほんとだね僕もちょっと買いたいな
Takaya Deguchi
うん
kudakurage
まぁじゃあ
あそうだな
車の購入について
kudakurage
お便り頂いてるんで
ちょっとお便りを紹介しようかなと思います
Takaya Deguchi
ほい
kudakurage
ラジオネームチェゾーさん
車買い楽しみました
あさっ
えっと先週のやつですかね
多分自動車業界の話ですね
僕も車はCOVID-19と
の時に買ってから
生活の変化に気づいたのですが
この空間が得られるのは
買い難いものだと思います
合わなければ売ればいいので
まずは気になる車を買うのをお勧めします
とのことですね
Takaya Deguchi
うん
kudakurage
買ったらいいと思います
まあそうね
Takaya Deguchi
うん
kudakurage
いやなんか僕も買ったらいいなと思ってた時期あったんですよ
Takaya Deguchi
そう
kudakurage
そういう同じように
Takaya Deguchi
うん
kudakurage
ただ
僕が今
買ってない理由は
Takaya Deguchi
うん
買ったらいいなと思ってた時期あったんですよ
kudakurage
うん
買うと
その
買ったことによって
こう世界が広がるじゃないですか
Takaya Deguchi
うん
kudakurage
その世界を
今ちょっと広げちゃうとまずいなと思ってるんですよ
Takaya Deguchi
その
kudakurage
逆に
Takaya Deguchi
いやちょっとよく分かんなかったですけど
kudakurage
だからその
車買うとさなんかいろいろ
あれも行けるとかあそこ行けるとか
あれもできるみたいなさ
なるじゃないですかやっぱり
うん
で世界広がるじゃないそうやって
うん
今広げちゃうと
今はもう
今やりたいこととか
あってそれも広がってんのに
さらにこう広げちゃうみたいになっちゃって
あのもう
あーまずいなと思って
それで買ってないとこもあるんですよだから
Takaya Deguchi
うん
やりたいこといろいろあるからってこと
kudakurage
そうそうそうそう
あえて狭めてるために
その
買っちゃうとまずいなって思う
っていうのもあって
買ってないとこ買って実は
買ったらいいなって思うのはもう分かってんだよなんか
Takaya Deguchi
うん
kudakurage
多分
多分いいんだろうなっていうのはね
Takaya Deguchi
なるほどね
kudakurage
まあでもなんかこの個の空間が得られるっていうのは
Takaya Deguchi
そうだと思うよねやっぱり
うん
kudakurage
自分の空間がもう一個増えるみたいなことだもんねやっぱり
Takaya Deguchi
そうですね
kudakurage
それはやっぱりね自動運転とかでもどんどん変わると思うんだよね
Takaya Deguchi
うん
やっぱり僕は
kudakurage
自動運転
今だったらさ僕が買ったらさ
個の空間だけど
自分が運転しなきゃいけないわけじゃないですか
Takaya Deguchi
うん
kudakurage
だから
まあもしかしたら電車乗ってた方が
なんか
本読めるとかあるかもしれないから
あれだけど
自動運転だったらさ
もうこの空間だし本も読めるみたいなさ
うん
って考えると
別に本じゃなくて普通に仕事をやりながら移動するとかもあるかもしれないしね
Takaya Deguchi
うん
kudakurage
って考えると
Takaya Deguchi
めっちゃいいだろうなっていうのは思うよねやっぱり
うん
kudakurage
そうなったら全然もっと遠くに住んでもいいですよね
うん
Takaya Deguchi
車前提の場所に住んでも
うん
kudakurage
もうね
移動しながらリモートワークやって出社するみたいなさ
なんか
Takaya Deguchi
謎の
移動しながらご飯食べてもいいしね
kudakurage
まあそうそうそうそう
Takaya Deguchi
もう何もいろんなことできるのねやっぱり
移動しながら寝ててもいいしね
kudakurage
うん
そうそうそうそう
いやだからもう
いやもう移動しながら寝てていいとかさ考えるともう
お酒飲みに行けるなとか思うよねやっぱり
ああ
Takaya Deguchi
確かに
kudakurage
その法律的にどうなるのかってのは分かんないけどね
その
運転できるやつが誰もいない自動運転者になんかその酔っ払ったやつが一人乗ってるっていうのはいいのかみたいなさ
Takaya Deguchi
うん
そうね
まあそれが許されるのは結構先の先でしょうね
kudakurage
結構先っぽいけどねそういうなると
うん
まあでもなんかそうなってくると本当いいよなって思うよね
Takaya Deguchi
そうね
kudakurage
そうなってたらもうなもう今すぐ買うけどなやっぱり
Takaya Deguchi
まあでも逆に
言えばエンジン車に乗れるのは今だけっていう考え方もできますよ
kudakurage
まあ今後も残る
いや残んないかまあ法律によっては残んない可能性あるんだよなエンジン車が
Takaya Deguchi
うん
kudakurage
もうダメってなっちゃう可能性あるんだよね
Takaya Deguchi
逆に自分で運転するのは今だけっていう考え方もできる
kudakurage
うん
いやでもそれで言ったら僕なんか今朝急になんか見つけたんだけど
Takaya Deguchi
うん
kudakurage
あの女優の長い時間に乗ることができるんだよね
長野芽衣さんって知ってる
うん
長野芽衣さんがなんかいつの動画だったのか分かんないんだけど
あのハーレーダビットソンに乗るっていう
ハーレーダビットソンのなんか多分動画があってオフィシャルの
Takaya Deguchi
へえ
kudakurage
のまあギャップがまずあるじゃないですかそのなんかね
かわいらしい女優の方が
アメリカンバイクみたいに乗るっていうさ
Takaya Deguchi
うん
kudakurage
でも僕もなんかその結構アメリカンバイクに憧れた時期あって
Takaya Deguchi
へえ
kudakurage
あの一時期乗ってたんですよその大学生ぐらいなんだけど
ヤマハナドラッグスターっていう
Takaya Deguchi
うん
バイクの魅力とEVの可能性
kudakurage
なんかバイクに乗ってたんですけどまあ
その後他のまあバイクにすぐ乗り換えちゃったりとかいろいろしたんだけど
うん
まあでも結構僕も好きなんですやっぱあれ系のバイクとかも
Takaya Deguchi
うん
kudakurage
まあ普通のバイクも好きなんだけど
Takaya Deguchi
うん
kudakurage
なんかあれ見ててもうすっごいバイク乗りたくなったね
Takaya Deguchi
うん
kudakurage
バイクもさやっぱりもうエンジンやっぱエンジンこうグーってこう振動
グーってさ音の振動がこう伝わってくる感じがあって
Takaya Deguchi
うん
kudakurage
まあそれも込みで
やっぱり楽しいから
うん
乗ってて
いやそれも乗れなくなっちゃうのかなって思うとちょっと寂しいよね
Takaya Deguchi
バイクってEVあるんですか
kudakurage
まあEVEVっていうかまあスクーターみたいな感じだよねもう
Takaya Deguchi
多分
kudakurage
まあでもあるあるんじゃないそういうのは
Takaya Deguchi
うーん
kudakurage
EVEVっていうかまあまあそうだよねモバまあモーターとバッテリーみたいなやつも
うんなくはないですよね
でもあんまり乗ってる人いないんじゃないかな
うん
そのスクーター系は多いけどね
たぶん
Takaya Deguchi
うーん
kudakurage
でもそんなに効かない
ていうかやっぱそのねバイクわざわざ乗る人ってやっぱそれ乗らないもんね
Takaya Deguchi
まあそうですよね
kudakurage
そうそうそう
それはやっぱりさエンジンガーって吹かしてさ
Takaya Deguchi
ドゥラーっていう
まあそうですよね
kudakurage
振動も込みで楽しんでる人多いから
わざわざさそれに変えてまでバイクに乗る人いないよね
Takaya Deguchi
そうね
まあ原付とか乗ってる人がそういう
kudakurage
うんまあまあまあまあそうね
Takaya Deguchi
うん
kudakurage
バイク乗れなくなっちゃうのちょっと寂しいな
うん
kudakurage
エンジン車まあね
その車もマニュアル楽しいとかあるけど
まあでもどっちかっていうとやっぱ僕だったらバイクの方がちょっと乗れなくなっちゃうと寂しいって思うかな
Takaya Deguchi
じゃあバイク買ったらいいんじゃないか
kudakurage
うん
いやバイクはねたまに買いたいなって気持ちになる時あるね
バイクね本当にあれはもう贅沢な趣味だと僕思ってる
Takaya Deguchi
そうなんですか
kudakurage
うんだって乗れる期間が短すぎんだもんあれ
Takaya Deguchi
ほう
kudakurage
マジで
まあ
乗れるけどもう冬とか寒すぎるからねマジで
Takaya Deguchi
僕北海道時代原付乗ってたんですけどね
kudakurage
はいはいはいはいはいはいわかるよ
Takaya Deguchi
まず車買おうがねなかったから原付買ってたんだけど
kudakurage
うん
Takaya Deguchi
まあ超短いですよね
kudakurage
うん
Takaya Deguchi
それに比べたらまだ乗れはするじゃないですか東京関東だったら冬では
kudakurage
まあまあ
Takaya Deguchi
うん
kudakurage
まあね
Takaya Deguchi
寒いだけで
kudakurage
いやもうだからさそのバイク乗っておくとね
なんかね僕あのケーキ屋で働いてた時通勤とかしてたけどバイクで
うん
もうやっぱりもう冬とかはさ
Takaya Deguchi
いや
kudakurage
ズボンの下になんかなんていうの肌着みたいなのあるじゃないですか
Takaya Deguchi
わかるわかる
kudakurage
それも着てさやっぱり
Takaya Deguchi
やってたやってた
kudakurage
でさらになんかねこうウィンドブレーカーじゃないけどさそういうのも履いてとかさ
しないともう寒すぎて
Takaya Deguchi
手袋はね手袋しないとマジで運転できないですからね
kudakurage
もちろんもちろんもちろんそれはねグローブしてマフラーつけてとかね
うん
ほんと
Takaya Deguchi
うん
うん
うん
うん
うん
Takaya Deguchi
うん
マフラー顔にぐるぐる巻きにして乗ってたのが
kudakurage
そうそうそうそう
でも最近あんまり着てないけどだからそれで結構僕よくもうそのバイク乗るのやめてからも
あのなんかライダースの革のジャケットみたいなのよく着てたんですよ
Takaya Deguchi
うーん
kudakurage
まあ好きでね
Takaya Deguchi
11月とかや北海道雪降り始めるギリギリなんですけど
そのギリギリを責めて責めてて大学まで来て帰ろうと思ったら雪降り始めて
ああ終わったと思ってでも行けるだろうと思って乗って
まあ何度か死にかけましたね滑って
うん
kudakurage
まあまあまだね降り始めぐらいだったらいいけどね
もう完全に降った後とかも氷になっていると危ないからねさすがに
Takaya Deguchi
ブラックアイスバーンとかになっているとね超怖いですよね
kudakurage
うーんそうそうそうそう
いやでもバイクはねやっぱ乗れる時期楽しめる時期が一瞬だからねほんと
Takaya Deguchi
うーん
kudakurage
なんか夏は暑いし冬は寒いしみたいなのがあるじゃないですか
Takaya Deguchi
そうね
夏の北海道は最高でしたけどね
うーん
kudakurage
まあそれはね僕もバイク乗ってた時は夏北海道を横断したいなっていうのをいつも思ってたよねやっぱり
Takaya Deguchi
うーん
kudakurage
絶対気持ちいいじゃんあんなのもさもうハーレーみたいなのでさ
ガーってさ
ドーンみたいな感じで走ったら絶対楽しいだろうなみたいな
うーん
いやでも長野芽衣さんはねすごいなと思った
なんかねちょっとギャップありすぎてちょっとハーレーがドーンとしてるのになんか細い体でさ
細い足とか細い手足でなんかなんかこう乗ってるからさなんか
チョンってやったらなんか倒れそうじゃないかなと思いながら見てたけど
でもすごいなああいうのに興味あるっていうのもすごいなと思ったけど
Takaya Deguchi
好感度が上がったねなんか
そうなんだ
kudakurage
じゃあ本題に行きますか
はい
Takaya Deguchi
今日はまたデザインシステムの話しようかなっていう
デザイントークンの必要性
kudakurage
デザインシステムね
Takaya Deguchi
うん
まあちょっとなんか仕事でデザインシステムかかってて
まあちょっといろいろこう調べたりしてるので
まあそれも似ともなって話そうかなっていう感じなんですけど
kudakurage
うん
Takaya Deguchi
まあ直近だと銀行とデザインっていう本を読んだ時の話
はい
したと思うし
あとスマート1Rのデザインシステムの本
小さく始めるデザインシステム
これの時の話も春ぐらいに
したんですけど
それに続いてっていう感じですね
ちなみになんかスポッティファイまとめ
なんかあったじゃないですか
ポッドキャスター向けも
それ見たらなんか
今年の1位は小さく始めるデザインシステムの会が
スポッティファイ内で一番
1位でしたね
スポッティファイユーザーの中で
はいということで
今回はデザイントークンについて
はいはいはい
話そうかなと
はいはいはいはい
kudakurage
はいはいはいはい
Takaya Deguchi
はいはいはいはい
はいはいはいはい
話そうかなと
話そうかなと思うんですけど
デザイントークンの作り方っていう本がね
あって
それをちょっと読んでたので
ちょっとそれを取り上げ軸につつ
話したいなと思うんですけど
そもそもデザイントークンって
なんだっていうところなんですけど
なんかイメージあります
kudakurage
デザイントークンとは
なんかなんだっけ
アトミックデザインっていう
一番小さいやつみたいな
それより小さくて
小さい可能性あるけど
Takaya Deguchi
そうですね
kudakurage
トークンだと
うん
なんかそんなイメージですけどね
Takaya Deguchi
そうですね
なんかデザイントークンって
言われ始めたの
多分ここ
3年とか4年ぐらいなんじゃないかなって気がして
確かにそれより前は
なんかアトミックデザインが結構なんか
一時期話題になった時
うん
はなんかアトムみたいな
kudakurage
そうなんだね
Takaya Deguchi
言われ方をしてた
kudakurage
うん
Takaya Deguchi
まあそれをアトムをさらに
まあ分解したようなものなのかなっていう
うん
気がしますね
kudakurage
まあそんなイメージですね
Takaya Deguchi
でまあよく言われるものとしては
まあ色とかタイポグラフィーとか
あと余白スペーシングとか
あとレイアウト
まあグリッドとかそういうのやつとか
あと角丸とか
あとエレベーションっていって
シャドウとかオーバーレイとか
まあなんかZインデックスが
親切的につくようなやつ
まあシャドウはつかないけど
まあ見た目的に階層がつくようなやつ
うん
このあたり結構デジタル帳の
まあ僕よく参照するのは
デジタル帳のデザインシステムがあって
まあかなりなんか
そのデザイントークの部分も含めて
なんかこう必要十分な感じで
日本語で整理されてるので
まあなんかよく見てるんですけど
デジタル帳のデザインシステムも
まあ今言った色からタイポグラフィーから
っていうのがまあ定義されてるっていう感じですね
kudakurage
うん
Takaya Deguchi
でまあそれはまあ分かるんだけど
じゃあデザイントークンを設計するって
どういうことなんだろうっていうと
なんか僕もいまいちなんかこうイメージつかない
かったんですよ
うん
Takaya Deguchi
何したらいいのかなみたいな
まあまあまあ
でまあそれでちょっとこの本を読んでみたんですけど
そのデザイントークの作り方っていう本を
kudakurage
うん
Takaya Deguchi
で書いてるのはプチャムさんっていう
あの今スマートバンク
リーヨンさんの会社にいらっしゃって
でも元々GMOペパボにいて
でまあその時にペパボのデザインシステムを
立ち上げる中でこう色々
あの試行錯誤した中でこう
本にしたっていう感じだと思うんですけど
まあまあ
あの元々これこの本技術書店で
多分自費出版というか同人というか
まあそういう形で出してる本だと思うんですけど
まあpdfでも読めるような本ですね
でもなかなかデザイントークンっていうテーマで
取り扱ってるの
なんか多分日本語だとこの本以外
なんか見たことないと思うんで
なかなかあの面白いなと思って
デザイントークンの作り方
Takaya Deguchi
読んでたんですけど
ちょっとそこから中から
まあちょっと自分僕的に面白いなと思ったポイントを
こうかいつまんで話せればなと思うんですけど
まあまずなんでデザイントークンの設計が必要なのかっていうところ
まあまあ必要性みたいなとこなんですけど
まあ元々この著者の方が
まあペパボに至っているところから
まあちょっと関連するんですけど
まあペパボって
まあ色々こう
色んなプロダクトを
複数ブランドを持ってるような会社じゃないですか
なんかスズリとか
まあ色んなサービス
だからなんかこういう方って
まあ要はマルチブランドな会社
まあ特にこういう方って
マルチブランド
ブランドをたくさん持ってる会社の中でも
まあいくつかパターンってあると思ってて
まあ例えばなんかGoogleみたいな
Googleホゲホゲって付くような
なんかGoogleホームとか
なんかそういうやつって
なんかブランデッドハウス型とかまあ言うんですけど
でまあ
多分特にこのペパボとかって
まああとなんだろうな
外資系のなんかこう
生活材扱ってるメーカーとか
なんかP&Gとかそういうのって
P&Gって傘の中に色んなブランド
個別の全然違うブランドがぶら下がってるみたいな
kudakurage
はいはいはい
Takaya Deguchi
うん
があると思うんですけど
まあこういうなんか
まあこれはハウスオブランズ型とか
言うらしいんですよね
最近知ったんですけど
でなんかその
特にそういうブランド独立型の中に
中においても
まあデザインシステムが
あの機能を機能するというか
そういう中でデザインシステムを作ったっていう例が
まあ一個ペパボの
デザインシステムの特徴かなと
まあ個人的に思ってるんですけど
まあそういうまあブランド独立してる
ある程度こう
一見関連性がないような
プロダクト群があったとしても
まあその中の中から
まあやっぱ共通項みたいなのが
やっぱ同じ会社でやっていく以上あって
そこの共通項をうまいこと取り出して
まあそうするとやっぱ抽象的なレイヤーが残ってくので
まあそれってまあつまり色とかタイプグラフィーとか
まあそういったところ
まあなのでブランドが複数あったとしても
その共通項を取り出すとそこが残るので
まあそれをうまいこと定義していく
必要性があるっていうところが
まあやっぱこうバックグラウンドにあると思うんですけども
このデザイントークンの必要性みたいな
だからまあそういった
こうブランドが複数あった場合に
まあエンジニアリング的に言えば
キーバリューのバリューを差し替えるだけで
まあブランド間で
まあテーマを切り替えるみたいな形
でなんかこう
まあ車輪の再発明みたいなことをしなくて済むみたいな
状況を作るっていうのが
まあ一個必要性としてあるのかなと思うんですよね
デザイントークンの設計の重要性
kudakurage
はい
Takaya Deguchi
だから結構マルチブランド的な会社においては
まあデザイントークンやる意義ってのはかなりあるのかなと
思う
ただ一方でエンジニアリング的な観点で見ると
なんか僕とかがよくやる
実際やるけど
なんかこうLPとか
LPとかまあペライチのページとか
まあもしくはこのポッドキャストのサイトみたいな
まあなんかブログの延長線みたいなサイト
シンプルな構造のサイト作るだけでも
まあやっぱなんかデザイントークン.jsみたいなファイル作るんですよね
だいたい
なんかコード書き始めるときって
でその時ってそのデザイナーが
例えばデザインシステムを作って
なかったとしても
やっぱコードを書く上では
色の定義とか
まあやっぱ
あの
デフォルトの例えばフォントサイズの定義とか
あのボーダーラジウスの定義とか
っていうのがまあ絶対必要で
まあその時に名前を付けるっていうのを
行為を絶対すると思うんですよね
でその時エンジニア的なマインドとしては
まあデザイナーの
あの作ったデザイン
まあフィグマを俯瞰してみて
まあだいたいなんかこう
このパターンがよく出てくる
なとか
まあデザイナーがそこまで
あの考えてなかった場合
ですけど
あのまあそういう平面のUIを
まあ俯瞰してみて
なんかそこから構造を読み解いていって
でその構造から
じゃあここ共通項っぽいから
なんか変数定義しておこうとか
まあなんかそういう思考になると思うんですよね
だからそう考えると
結構まあマルチブランドとか
そういう会社
そういうプロダクトじゃなかったとしても
まあ結構やっぱ構造を作ってくっていう上では
まあデザイントークンの設計みたいなことは
まあ絶対必要になるなと思ってて
kudakurage
はい
デザイントークンの設計とキーの構成
Takaya Deguchi
まあだから結構デザイントークンを設計するってのは
デザインシステムの最初単位を作るものなんじゃないかな
っていうふうに
まあ思うんですよね
個人的に
kudakurage
まあまあそうね
Takaya Deguchi
まあまあ今の話はまあ僕個人的な話なんですけど
まあじゃあ実際そのデザイントークンって
まあ何をもたらすのかっていう話が
まあこの本の最初の方に書いてあるんですよね
でまず一個が
まあ
シングルソースオブトゥルースみたいな
そのまあ一つの
よりどころみたいなのをちゃんと定義しておく
まあなんか色
同じようなオレンジ色が
プロダクトのコード上にいっぱいバラバラたくさんあるとか
なんかいっぱい似たようなグレーがたくさんあるとか
まあすごい起きがちだと思うんですけど
まあそういうのをなるべく防ぐとか
あとはやっぱ
ブランドが複数あるっていう状況だけじゃなくて
その一歩手前に
なんかまあ
プラットフォームが複数あるっていう状況って
まあ生まれやすいと思うんですよね
その一個のプロダクトがウェブにもアンドロイドにも
はい
なんちゃらかんちゃらいっぱいあるみたいな
でそうなってくとやっぱコードベースがどんどんどんどん増えていくと思うんで
まあそういう時にまあ一箇所を参照した方が
まあ効率的だし統一感が保てますよねっていうような話
まああとはもう一個あるのはやっぱそのテーマっていう話で
なんかどうしても最近の流れだと
そのダークモードに対応しなきゃいけないとか
あとはもっと言うと
まあダークモードってライトが
ダークモードって
ダークがその2パターンに見えるんだけど
まあさらに言えばそのマテリアルユーみたいな
そのパーソナライズみたいな文脈でのテーマっていうのもあると思うんですよね
その人だけのテーマみたいな
だからまあそういうことしていくと
まあやっぱこうさっきの色とか書体とか
そういったものの決め打ちっていうのが
まあどんどんできなくなってきてるのから
まあだからデザイントークの設計っていうのが
必要になってきたっていうような背景があるのかなと思うんですよね
kudakurage
そうね
実装的には
まあそういうふうにしておかないとっていう文脈も
Takaya Deguchi
かなり大きくなってきてるしね
だからこの本読んでて思ったのは
確かになんかこう
最近デザイントークンってワードが出てきたのは
まあかなりそういうダークモードとかパーソナライズとか
そういう文脈の影響を受けてるだろうなと思うし
まああとなんかスペーシャルデザイン
スペーシャルUI
ビジョンプロの出たときの
WWCのセッションの話とかしたとき
あの日までに
Takaya Deguchi
インターフェースガイドラインに
スペーシャルUIみたいなのまとまったと思うんですけど
なんかその中でも
よりなんか空間のそういう世界に行くと
バリューが流動的に変わっていくというか
例えば確かあの
WWDCの中でも
そのスペーシャルUIの中では
フォントサイズだとか
そういうのも決め打ちは絶対するなみたいな
話が確かあったと思うんですよね
だからそれってやっぱ
空間デザインの世界に行くと
物理的にどの角度から見てるかとか
見てる距離だとか角度だとか
あとなんかその周りの明るさとかによって
特にビジョンプロの場合
ガラス的なUI使うから
それによって色の見え方とかが変わってきて
その辺ビジョンプロがOS側で
うまいこと調整してくれるから
それってある意味
テーマがテーミングされてるというか
テーマによってその
色がうまく調整されるから
そういう時に
決め打ちしてしまうと
それがうまい調整が入らなくなってしまうっていう
だからこういうデジタルプロダクト使うシーンが
色々こうプラットフォームが増えていくとか
なんかそういう単にオンスクリーンだけじゃなくて
空間の世界にが始まるとか
なんかそういう
なんかいろいろ多様化してた結果
もう決め打ちができる世界が
終わったっていうことなんだろうなっていう風に
思うんですよね
で本に戻ると
そういうデザイントークンの話の中で
じゃあ具体的に
何をやるかって言ったら
やっぱその
キーとバリューで言うと
そのキーを
どう設計するかっていうところに
やっぱ
が話の
主題になってくるのかなと思うんですよね
例えば具体例で言うと
この本の中でもアトラシアのデザインシステムが
取り上げられてたんですけど
アトラシアのデザインシステムを
こう見ると
色々デザイントークンっていう
ページがあって
色々こう細かい解説が書いてある
丁寧に書いてあるんですけど
例えばこう
簡単に言うと
カラーコード
例えば00CC00
これグリーンを指すカラーコードですけど
っていうバリューがあった場合に
それを
これまで何も考えなければ
これをそのまま
CSSのフォントから
この
ヘックスを指定する
っていうような感じで
決め打つと思うんですけど
そこをまず一個
グリーン100みたいな
名前に変えましょうっていう
これをベーストークンって
このアトラシアの中では呼ぶらしいですね
さらにそのグリーン100とか
この100っていうのは
だいたいメイドとか
W3Cのデザイントークンフォーマットモジュール
Takaya Deguchi
メイドのレベル感みたいなのを
示すことが多いんですけど
そういうベーストークン
生の値を参照したキーを
ベーストークン
さらにそれを
さらにそれだけじゃなくて
さらにそこから
なんかセマンティックトークン
セマンティックデザイントークンって
このアトラシアのデザインシステムで
呼んでますけど
カラー.テキスト.ディスカバリー
みたいな
わかりやすく
カラー.テキスト.サクセスみたいな
要はこのカラー
これはテキスト要素に
色です
テキスト要素に使われてます
サクセスの色ですみたいな
なんかそういう
なんか意味を付加するみたいな
そういうことして
単に
カラーコード
生の値じゃなくて
ちゃんと意味を持った
トークンを設計する
っていうような話ですね
このキー
今言ったカラー.テキスト.サクセスみたいな
このキーをどう設計するかっていうのが
デザイントークンの
前半なのかなと思うんですよね
アトラシアの場合は
このカラー.テキスト.サクセスみたいな
このセマンティックデザイントークンって
呼ばれてるものを
もうちょい整理すると
ファウンテーションプロパティ
モディファイアって
3つに分けられますみたいな
話をしていて
ファウンテーションってのが
カラー
今の例で言うと
カラーに値するところですね
ここがカラーとか
エレベーションとか
スペーシングとか
四角要素のカテゴリーみたいなもの
真ん中のテキストっていったのが
プロパティって
アトラシアの場合呼んでて
ここがバックグラウンドとか
そういうUIの要素
最後サクセスっていったのが
モディファイアって呼ばれていて
ここがワーニングとか
ホバーとか
UIの役割とか
インタラクションの状態を示している
だから四角要素
UI状態って
その3つでキーを構成するっていうような
アトラシアの場合は
そうなってるっていう感じです
アトラシアの場合だけど
でもかなりこれは
原則的な話なのかなと思いますね
kudakurage
僕も色とか
ピグマで今だとできるから
作る時はだいたいこういう感じの
あんまり階層付けがきしすぎちゃうと
それはそれで管理とか大変になってきちゃうから
Takaya Deguchi
そうそうそう
kudakurage
だいたいこんな感じ
これが一番シンプルな形かなと思ってるけどね
Takaya Deguchi
結構この話って
10年くらい前遡ると
CSSの頃にVEMとかあったじゃないですか
そのCSSの設計
要は昔はCSSインジエースとか
そういったものなかったから
クラス名をいかに設計するかってところが
やっぱこう
特にデザイン寄りのエンジニアに
求められるところでは
あったりしたと思うんですけど
そういう時もやっぱ
クラス名をどう設計するか
っていうので
VEMとかいろんな手法が出てて
それって結局今言ったような
ファウンデーションプロパティモディファイヤー
みたいなところを
クラス名に込めて
それによって
クラスが何を示してるのか
分かりやすくして
かつ被りがないようにするっていう
それによって上書きを防ぐっていうような
ことをやってたと思うんですけど
やっぱこういうところに向き合うことになるよな
っていうのは改めて思いましたね
kudakurage
そうね
Takaya Deguchi
でなんか僕もこの本読んで
へーって思ったんだけど
なんかこの辺のやっぱ
キーの設計とか
どうしてもやっぱプロダクトに
よる影響は大きいんだけど
ただなんかここをうまく標準化しようとする
動きがあるらしくて
なんかW3Cに今
デザイントークンフォーマットモジュールっていう
kudakurage
なんか見たことある
Takaya Deguchi
ワーキンググループがあって
なんかそこが
今草案を作ってるみたいですね
でなんかこの草案の策定に
アドビフィグマとか
スケッチとかグーグルとか
あとMSGitHubとかが
関わってて
なんかそれによって
そういう
一回デザイントークン決めてしまったものを
ツール間とかで共有したりとか
以降エキスポートインポートしやすいようにする
っていうのを今やろうとしてるらしいですね
っていうのが
デザイントークンの全体ですね
デザイントークンの具体的な決定方法
Takaya Deguchi
じゃあまあ
ここから具体的にどうやってそれを決めていくのか
っていう話になってくんですけど
そうですねその分類をまずは
プロダクトが既にあるって前提で
なんかそのプロダクト内で
使われているとか
プロダクトだけじゃなくて
その中に出てくるバナーだとか
そういったビジュアルデザイン
要はユーザーとのタッチポイントになるような部分
っていうのをやっぱ
くまなく観察して
デザイントークンの設計
Takaya Deguchi
まずはその共通項みたいのを見つけて
グルーピングしていくっていうことが
まず第一歩だみたいな話があって
この辺は
さっき冒頭に言った
LPを作る時とか
なんかそういう時でもやっぱ
いかに共通項を見つけるかっていうのは
特にコードに落として
デザインをコードに起こして
落としていくっていう上では
大事になってくのかなと思うんですよね
でその上で
共通項を見つけてグルーピングしたら
それをなんか
次は階層化していくみたいな話があって
その階層ってのが
さっきアトラシアの例だと
ファウンデーションプロパティ
モディファイヤーって言ったけど
もうちょっとなんか汎用化すると
まずなんか原始的な
プリミティブな値のレイヤーがありますと
さらにそれを参照する
参照レイヤーっていうのがありますと
さらにその上に意味のレイヤーがあって
さらに最上位の
最上位に成果物のレイヤーがあるみたいな
整理がこの本の中でされてて
プリミティブな値ってのが
カラーコードみたいなやつですね
でその上の参照レイヤーってのが
なんだろうな
この本の中の例だと
キャロット80みたいな
要はなんかオレンジ色がありました
それに対してキャロット80
メイドレベル80のキャロットっていう風な
意味付けをする
kudakurage
そこは色名みたいなとこだよねまだ
Takaya Deguchi
そうそうそうそう
まあそうですね
カラーパレット
物理的なパレットに色を乗っけたみたいな
そういうようなイメージですよね
でさらにそこから
それを何に使うのかっていう
アトラクシアンディーセマンティックトーク
この本日本語的に言うと
意味のレイヤーっていうのを作ると
例えば
アテンション用のコンテナで使う
コンテナUIで使う
キャロット
アテンション用のコンテナで使うための
色ですよキャロット80ですよみたいな
そういったレイヤーを作ると
でさらにその
最上位の
最上位に成果物
それがどのコンポーネント
どのUIコンポーネントで使われているのか
カードコンポーネントであるとか
それによって
例えばカードコンポーネントの
アテンションのコンテナのキャロット80だったら
なんとなくそれを
文字列を見たときに
なんかカードコンポーネント
注意を引きたいカードコンポーネントの
バックグラウンドとかで使われているのかな
みたいなのが分かるみたいな
そういうことですよね
でそこで例えば
テーマ
ダークモードに変わりました
みたいなことがあったら
ダークモードに変わったとしても
カードのアテンションのコンテナって
そこは変わらないわけですよね
ただそこから参照している
意味レイヤーから参照レイヤーにかけて
参照しているときの参照先が変わって
もともとキャロット80って
割と明るい色を使ってたんだけど
割と暗い
明るい色を使ってたんだけど
それをちょっと暗い色に変えますみたいな
ダークモードにしたときに
キャロット20に参照を変えますみたいなことによって
ダークモードを実現する
みたいなことが
おまかに言うと
デザイントークンでやること
っていう感じですよね
っていうこの辺は
口で言えばこういうことなんだけど
その
共通項を見つけてグルーピングして
回想化するっていうそこがやっぱ
一番難しいところだし
プロダクトが複雑化してればしてるほど
そこにやっぱ時間がすごいかかってくるところかな
っていうふうに思うんですよね
だからここを新規プロダクトであっても
最初の方に整理しとくと
後から継ぎ足すのも
楽だし
いい塩梅で
やりすぎてもダメだけど
いい塩梅でやるってここが結構
腕の見せどころなのかなっていう感じがしますよね
さっきもたよさんが言ってたように
むやみに細かくやりすぎて
ネストしまくっちゃって大変とか
kudakurage
いやだから
割とクランにいるメンバー
割とそうだけど
ここをどう作るかを考えるのが楽しい
っていうね
そこばっかやってるみたいな
Takaya Deguchi
そうなんですよね
kudakurage
そういう人が多いみたいな
Takaya Deguchi
結局すごい抽象化したい話すと
やっぱそのVEMの時代からそうだけど
UIをどう捉えるかっていう話になってくると思うんですよね
kudakurage
まあまあそうね
Takaya Deguchi
コンポーネント一つとってもカードとして捉えるのか
あるいはもうちょっとバナーみたいな
もうちょっと意味的
視覚的な捉え方をするのかとか
kudakurage
実際のアウトプット変わんないのにさ
それをどう設計するかを
あれやこれやこうじゃないああじゃないみたいな
Takaya Deguchi
あれやこれやこうじゃないああじゃないみたいな
考えてやってるのが楽しいなと思ってずっとやってたりするんだけど
まあそうなんですよね
そうまあだから
kudakurage
結構ね難しいんですよね
難しいというか
なんかね僕も結構
最近後から話すかもしれないですけど
Figmaのバリアブルズっていう機能がついて
割と色系とかちょっとした数値は
変数として扱えるようになったから
こういうデザイントークン的な設計がやりやすくなって
僕もやったと思って
結構ガシガシ
もうすでに関わってるプロジェクトとか
そういうものに入れてって
勝手に設計してやったりとかしてるんだけど
やっぱりなんかどれぐらいのレベルで
まとめていくか分解していくかみたいなのを
探るのが結構難しいんですよね
Takaya Deguchi
難しいですよ
kudakurage
それはもうなんかね
多分僕一人でやってても
いやこれちょっと失敗だったかなと思うことが
あったりとかするし
多分もっと人増えたら多分ね
もっと大変になるような
それの塩梅っていうのが
まだ完璧には掴めてないような気がする
Takaya Deguchi
そうですね
一個ポイントがあるとしたら
なるべくベタにやるというか
早すぎる抽象化をしないっていうところは
一個ポイントとしてあるのかなっていう気は
するんですけどね
kudakurage
そうだよね
結構ね僕も最初やって
これ失敗だったかなと思ったのは
テキスト用のカラーと
それ以外のカラーと
エレメント用のカラーっていうのを分けたんですよ
Takaya Deguchi
意味的に
kudakurage
だから例えばプライマリーカラーを使いたいテキストだったら
そういうプライマリーテキストみたいなのがあったりとして
それとは別に
例えばプライマリーカラーを使いたい
テキスト以外のちょっとした
四角とか丸のかの
そういうエレメントに使いたいっていうときの
色はプライマリーエレメントみたいなとかに
分けたりしたこともあったんだけど
分けても意味ねえなとか思ったりして
そういうのがあったりして
最終的に一緒にしたりとか結局
テキストもそういう
汎用的なエレメントも全部一緒にした方がいいな
っていう風に思って
一緒にするっていう風に別のプロジェクトで
やってみたりとかっていう風にして
結構ねまだ試行錯誤してるっていうような感じは
自分の中でもあるんだけど
Takaya Deguchi
分かる
名前付けも難しいなと思ってて
なんかこうLPレベルであっても
例えばなんかブランドカラーみたいのがあったら
何も考えずにやるとしたら
じゃあ例えば青があったとしたら
そのブルーに
ブランドカラーって名前を付けたくなっちゃうんですよ
kudakurage
はいはいはいはいはい
Takaya Deguchi
それやるとブランドカラーの青なんだけど
ちょっとここではちょっとその青の明度を
ちょっと変えたいですとか
なんかそういうことが起きたりして
でそうすると
あれこれちょっと明度変わってるけど
ブランドカラーと言っていいんだろうかみたいな
ものとか
kudakurage
なるほどね
Takaya Deguchi
なかなかこういい塩梅で
かつ意味的に整合性を取った状態で
設計するって
まあ初手で正解を出すな
まあまあまあまず無理ですよね
kudakurage
そうだね
いろいろ他の会社のやつとかも見たりして
なんか参考にしながら
取り込んでいってね
やってるみたいなとこあるけどねやっぱり
Takaya Deguchi
そうですね
この本でも書いてあったけどやっぱ
将来的に必要かもっていうのは
なるべく後回しにするっていう
必要になった時に必要なことをやるっていうのが
一個ポイントなのかなと
色の設計
Takaya Deguchi
思いますね
kudakurage
基本的やね
でもなんか最近ちょっと
それで言うと同じようにやって
設計してた時に色の設計だけどそれも
思ったのは
まあいろんな
基本的な
ブランドのカラーは設計するんだけど
最初に決めちゃうんだけど
まあそれ以外の
青だの赤だの黄色だのみたいな
そういうのも
一応なんか使う
ところがありそうだから
それも一緒に設計するんだけど
緑はそれなりに
明度差があるものを
用意しなきゃいけないんだけど
それ以外の色は別に用意しなくてもいいみたいな
この基本的な色だけあれば別に問題ないみたいな
ことがあって
結構まばらにだから
必要なところだけ
定義してたんだけど
なんかいろいろやってると
バランスが取れなくなって
いうか
結局全部
決めて全部の色相と
明度のサイドのやつを
定義して
その上でもうなんか
ここここここを使うみたいな
した方が結局良かったっていう風になったことがあって
グレースケールの設計
Takaya Deguchi
確かに
kudakurage
なかなかその辺難しいなと思ったね
Takaya Deguchi
色は相対的な要素が強いから
最初から全部考えておいた方がいいっていうのはあるかもしれないですね
kudakurage
そうそうそうそう
結構ね設計
だからグレーとかも
僕最近もう全部作るようにしてるんですよ
マテリアルカラーみたいな感じで
グレー50からグレー950ぐらいまで
12段階ぐらいのやつ
のグレースケールも
最初に全部作るようにしてて
それ全部使わないんだけど
多分全部は
ところどころしか使わないんだけど
でも最初に設計しておかないと
後々バランスが取れなくなった時に
また調整必要だなと思って
ぐちゃぐちゃやってるとあれになっちゃうからって思って
Takaya Deguchi
確かにね
UIライブラリの設計ツール
Takaya Deguchi
結構最近の
こういうUI系のライブラリ
フレームワークとか見ると
そういうカラーパレットというかカラースケールが最初から
完璧に定義してあるみたいなのがよくありますね
うん
確かに色は最初からやりきっちゃうのがいいのかもしれないですね
kudakurage
そうだね
ある程度なんかもう
バンって作る時には
もう一通りバーって作って
でその中からこれとこれとこれ使うぐらいの感じでやってた方が
なんかもしかして後からなんかやっぱりこれのちょっと薄い色も必要だったみたいになった時に
なんかすぐ使えたりとかして
Takaya Deguchi
そうですね
kudakurage
いいなと思ったりしたね
Takaya Deguchi
まあちょっとこの本の中に戻ると
その次の章に定義するっていうのが出てきて
まあその今さっきの話はキーをどうするかって話なんだけど
このそのバリューをどう決めていくかっていう話で
まさにその色の決め方みたいな話が出てきて
kudakurage
はいはいはいはい
Takaya Deguchi
まあここは別にいろいろやり方はあると思うんだけど
まあこの一例としては
まあ例えばそのまあだいたいその明度のカラースケールみたいな
レベル0が真っ暗でレベル100が明るいみたいな
その中でまあスケールを作るじゃないですか
一定の流度で
そういうのの設計をどうやるかみたいな話も触れられていて
まあ例えばあのプライ
まあだいたいこうアクセシビリティ的に考慮しなきゃいけないじゃないですか
その問題ないコントラストとか
みたいなところ
kudakurage
はいはい
Takaya Deguchi
だからこの本だと
あのプライマープリズムって
まあギターブがプライマー
プライマーでいいのかなやり方ちょっと分かんないけど
あのデザインシステム作ってて
その中の一部にプリズムっていうツールがあるんですよね
そのカラーパレットの設計ツールみたいな
でまあそれを使うとそういうアクセシビリティ的に問題ないように
あの明度とかをまあうまいこと設計してくれるっていうようなツールがあったりとか
まあこういったものを使いながら
まあアクセシビリティ的に問題ないように
問題ないコントラスト比保って
カラーパレット作るみたいなことをやるといいですよみたいな話があったり
まあこの手のツールはいろいろいくつかあると思うんですけど
なんでさっき言った他の色との兼ね合いもあるし
アクセシビリティの兼ね合いもあるから
まあいろいろそういうツール使いながらやりきるのがいいですよっていうのと
あとそのネーミングもやっぱり色の命名って結構難しいところあると思うんですよね
文脈に応じてチームで議論しながら
ネーミングするしかないですねみたいなことが
分かれてましたね
あとはタイポグラフィー周りの話になると
例えばフォントのサイズとかどう決めていくかみたいな話
ここは鈴木嬢さんって方の音楽数学タイポグラフィーっていう記事
もしかしたら見たことあるかもですけど
エクリっていうメディアに
kudakurage
ああはいはいはいあれか
ああはいはい
Takaya Deguchi
わかってて
この記事がこの本の中でも参照されてるんですけど
この記事はフォントサイズとか行間とか
そういう人間が見てるときにリズム感みたいのが重要になるような
そういう視覚要素を音楽とか数学的な理論から決めていきましょうっていうような記事なんですよ
例えばフォントサイズとかって
なんとなく16ピクセルぐらいが基準で
下が14ピクセル一番小さくて12ピクセル
上は20ピクセル24ピクセル2832みたいな
なんか大体あるじゃないですか
その感覚
kudakurage
ありますね
Takaya Deguchi
そういうのをグラフィックデザインとかやってる人は多分
感覚的に決められるんだと思うんですけど
それをもうちょっと数学的に決めていくっていうような記事ですね
この記事の中だと調和数列っていうような数列
フィボナッチ数列みたいな一定の感覚の数列が出てきて
それの掛け合わせによってフォントサイズを決めたらいいなと
よいですよっていうような決め方が書いてあったりとか
あとラインハイトも基本は4ピクセルにしつつ
リズム感がいいように決めるにはこうした方がいいですよみたいな話があったりとか
kudakurage
ラインハイトどうしてます?いつも
Takaya Deguchi
ラインハイトね迷いますよね
kudakurage
僕はなんとなく自分の中である程度ルール結構作ってて
もうこうしちゃおうみたいな
なんかやっぱり見出しと
本文テキストとあともう1パターンぐらいあって僕の中で
見出しはちょっと詰め気味にしてるんだよね
だいたい1.2か1.25倍ぐらいのやつ
ラインハイトの設定に関する悩み
kudakurage
で本文は場所によるんだけど長い文章みたいなやつだったら
割とその2から200%から160%ぐらい1.6ぐらいの間ぐらいに設定してることが多いかな
そこの辺は多分トーンというかサイトの雰囲気によって変えるんだけど
でさらにその間ぐらい1.4ぐらいっていうのも使うことがあって
それはなんか例えばなんかサムネイルの下に表示するキャプションみたいなやつとか
そういうぐらいの見出しほどじゃないんだけどちょっと短めのテキストみたいなやつの時は
それぐらいの狭めたりとかっていう感じの自分の中で感覚はなんとなく決めてたりしますね
Takaya Deguchi
ラインハイトって結構エンジニア的視点で見ると
扱いが変わるんですよね
扱いが変わるんですよね
難しいものでもあるなと思って
やっぱこうどうしてもツール的フィグマ的にもなんていうのかな
うまく表現できてない時があるっていうか
デザイナーのデザインの仕方によってラインハイトがうまく数字取れないとか
kudakurage
はいはいはい
Takaya Deguchi
あと実装的にもそのフロントエンドエンジニアの実装方法によって
うまくラインスペースがちょっとずれた形で実装されてるとか
あとフォントのフォントに何を選ぶかによって変わってくるとか
変わってくるとか
いろいろなんかいろんな要素あるじゃないですか
大分大分で変わるとか
だからなかなかこう難しいなんだろうな
うまいこと統一するのが難しいポイントだなと思いながら
いつもやってますね
kudakurage
うーんそうだね
なんかフィグマとかで作ってても割とその辺
まあ適当にパーってとりあえず作ろうみたいな感じでやっていって
最後までそうなってるみたいなこともあったりすると
なんかそのオートになってて
Takaya Deguchi
ああそうね
kudakurage
業界の部分が
そのままだと結構多分実装的に迷ったりとか
あとあとなんかやっぱこうしたかったみたいな風になったりとかしちゃって
あれだから割と最近は設定するようにしてたりすることあるけどね
まあフィグマだったら100%表示で120%とか
Takaya Deguchi
そういう風に結構そういう設定
例えばこの3種類で基本をデザインしていきますっていうような
なんかルールベースが決まってるだけでも
デザインエンジニア的にもありがたいかもしれないですね
そうだね
kudakurage
だから本当なら
そのタイポグラフィー周りも今フィグマまだできないけど
マリアブルズでこういろいろ定義できたらいいなっていうのは結構あるんだよね
Takaya Deguchi
確かスマートHRはタイトリラックスなんちゃらみたいな
なんか3,4種類ぐらいって決まってたような気がしますね
kudakurage
まああとね
タイポグラフィー
これもう技術的な問題でしょうがないんだけど
タイポグラフィーっていうかフォントサイズに関しては
どうしても僕の中でiOSの問題っていうのが常に
iOSでの日本語フォント表示の問題
kudakurage
今は付きまとっているなって思っているんだよね
Takaya Deguchi
問題
kudakurage
大文和文っていう意味で
iOSで表示される日本語フォントがちょっと大きめ
ちょっと小さめに表示されるんだっけ
どっちだったっけな
ちょっと小さめに表示されるんだったっけな
Takaya Deguchi
うん
kudakurage
からフィグマで指定したやつでそのままでいくと
場合によってはアルファベットの方が変な風になっちゃうとか
そっちのアルファベットの方に合わせちゃうと
日本語の方が変になっちゃうとか
日本語の方がおかしくなっちゃうとか
そういう問題がなんか今ずっと付きまとってるから
いつもなんかめんどくさいなって思います
Takaya Deguchi
それは常に悩みますよね
kudakurage
そうそう
ほんとね悩んで
いつもそれを悩むんだよね
Takaya Deguchi
日本語系
kudakurage
基本ね日本語系のアプリ作ってることが多いから
日本語をベースにしたフォントサイズを指定はするんだけど
なんかいつもそこをねまだ悩んでるね
早くだから対応してほしいなって僕は思っているんだけど
どっちかフィグマが対応するか
Appleがなんかそのフォントも渡すかしてみたいな
うまく対応できるようにしてほしい
Appleが早くフォント作ればいいんだよな多分日本語の
Takaya Deguchi
そうねそれはすごい幸せになるよな
kudakurage
そうそうそれが一番多分幸せになれるんじゃないかなと思うけど
Takaya Deguchi
なんか全然関係ないけど
なんかU-Gothicもそろそろこう
基本なんかデバイスフォントで使ったりするじゃないですか
U-Gothic Macとかだと
でもそれもブラウザが結構
会話指摘観点で参照できなくようにするみたいな対応を最近してるらしくて
要はなんかそのフィンガープリントっていって
フォントが何が入ってるかによってその個人を特定できてしまうから
だからそうブラウザ的にはそれを防ぐ
防ぐまあ括弧Chrome以外なんですけど
まあChromeは広告やってるからねGoogleが
だからまあそういう基本的にデバイスフォントだけでいいんじゃないかっていうような
流れが最近はできてるらしいです
kudakurage
そうなんだ
Takaya Deguchi
iOSだとね
まあすでにそういう流れだけど
kudakurage
よりそういうのが強化されていくのかなとは思いますね
Takaya Deguchi
まあちょっと話それだけど
まあそういうフォントサイズとか
まあそういったものをリズム感とか
そういう理論的なもので決めるっていうのも
まあ一個の手としてありますよみたいな話ですね
あとなんか余白とかもそうですね
そのスペーシングみたいなのも
フィボナッチスレッドベースでこの本だと
決めるっていう話もあるし
あとはやっぱ最近のUIライブラリとか見てると
やっぱ4ピクセルがデフォルトになってたりとか
その辺の規定値はあったりするから
まあそういうのも
まあそのこの辺は結構
サイトのトーンとかにもよるとは思うけど
kudakurage
そうね
まあでも結構もうなんかテールデザイン出てきたぐらいから
だいたいもうやっぱり8の倍数
Takaya Deguchi
そうですね
kudakurage
まあそれ小さい場合は4とか2とかなるんだけど
にするのがいいかなと
Takaya Deguchi
だいたいもうそれに沿えてるところがあるような気がするけどね
結構僕も実装やってて
なんかこれだけなんか倍数気持ち悪いなって時は
勝手にそれの倍数に直したりとかしますね
kudakurage
分かります
Takaya Deguchi
なんでここだけ17なんだろうみたいなのを
勝手に16に直したりとかしますね
まあ結構まあ今なんかスペーシングと
ダイアポグラフィーの話しましたけど
まあその他にもボーダーとかラディウスとかシャドーとか
オパシティとか
まあその辺の具体的な話が結構書かれてて
この辺そういうのもね
すごい実践的で
参考になるかなと思いますね
でまあそういう感じでキーとバリューをこう決めていったら
まあ次にあるのが今度はコードに落とすっていうところですね
ここからエンジニアの仕事になってくかなと思うんですけど
コードに落とすっていうと
もうちょい分解すると命名をするっていうのと
あとはそれを定義する
ファイルに定義するっていうような話になるかなと思うんですね
デザインの命名規則
Takaya Deguchi
で命名するっていうのは
さっきの整理の段階で
階層構造とか意味によって
UIの整理がされてると思うので
それを名前を付けていくっていう行為をすると思うんですけど
ここはなかなかこうしろっていうのはなかなかないとは思うんですけど
例えばAdobeとかの
Adobeのスペクトラムっていうデザインシステムがあって
この中のデザイントークンっていう項目を見ると
命名の付け方というか
ネーミング構造はAdobeのシステムではこうしますっていうのが決まってたりとかするらしいんですよね
例えばこのスペクトラムっていうデザインシステムの中では
人間ヒューマンリーダブルな名前にしましょう
人間が読みやすい名前にしましょうとか
あとさっき本山さんが言ってた
なるべくネストしすぎずフラットな構造を作りましょうとか
あとは予測可能であるような名前にしましょうとか
構造は文脈とか共通単位明確化っていう要素が振れられてるけど
そういった観点で名前を決めていきましょうみたいな
ガイドラインみたいなのがあったりしますね
デザイントークンのファイル形式
Takaya Deguchi
もうちょい細かい命名の話をすると
例えばフォントサイズのMサイズをどう名前を付けるかみたいな
ミディアムってするのかMDってするのかMにするのかみたいな
ここも結構揺れがちだし
この本でもなるべく略さない方がいいですねみたいなこと書かれてて
自分もそう思うんだけど
だからやっぱ下手になんか略称されてるとMDって何の略だっけみたいな
思い出すのがだるいなと思ってしまうから
だったら多少長くてもミディアムって書いてほしいなっていうのが
エンジニア的な視点では思ったりしますね
結局なんか後から出てくるんですけど
エンジニア的には型が付いてたら大体エディターによって保管されるから
Mって言ったらミディアムって出てくるから
だから別に名前は下手に略さず正式名称にして
あとは保管に頼るっていうのが一番いいかなとは思うんですよね
こういう命名とかをした上で今度それをファイルに落とし込んでいく
要はどういうファイルにするかっていうところで
基本的にはJSONが一般的っていう風に言われててそうなんだろうなと思うんですけど
この辺もJSONの中でどういう構造でデザイントークを表すかっていうところは
まさにここがW3Cのワーキンググループの中で今総案が決められてるらしいんですよね
ここがちょっとなかなか口では言いづらいんですけど
さっきの基本的にはキーバリューなんですけどボタンバックグラウンドっていうキーがあったとしたら
そこに対してシャープ0000っていうバリューがあるRGっていうのがあるんですけど
RGBとかXのバリューがあると
プラスして型っていうのがあってタイプカラーとかっていうのを持たせるんですよね
要はその値が何の型なのかっていうのをちゃんとJSONで定義しておいて
それによってカラーだったらRGBかXだよねってなって保管できたりとか
あとリントツールで構成かけられたりとかするっていうような
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
FigmaとW3Cの関係
Takaya Deguchi
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
この辺はすごいエネルギー的な話になっちゃうんですけど
このSpecifyっていうのはGUIなのか ウェブアプリなのかちょっと使ってないんでわかんないですけど
その中でアプリに出てくるデザイントークンとか アセットとかを全部一括管理するような
そういうようなプラットフォームらしいですね
そことFigmaもそうだし 例えばReactとかそういったものを連携させておくと
うまいことコード入ってくれるっていう感じの ツールなんじゃないかなと思いますね
そういう感じなので だからこそ今まだW3Cが相案ベースで作ってるっていうのだけど
先回りでそういうの多分こういう各種プロダクトって 見てると思うんですよね
だからオレオレフォーマットで作るっていうよりは
そういうフォーマットに追従しておくっていうのは 結構損がないのかなと思うっていう感じだと思いますね
特にFigma Adobe Figmaが絡んでるし MS GitHubが絡んでるとなると
やっぱその辺は多分絶対追従してくると思うし
まさについ最近FigmaのVariablesが出たとき 出た後に何かこの本によると
Figmaの公式のプラグインサンプルみたいのが あるらしくて
そこにまさにバリアブルズインポートプラグインみたいなのが出てるみたいですね
これを使うとW3Cのそのフォーマットに沿って JSON定義しておくと
それをそのプラグイン使うとインポートできて Figma上でバリアブルズとして表現できるっていうような
持ってこれるっていうようなものみたいですね
だから元々スターリディクショナリーみたいな そういうサードパーティーツール使ってたんだけど
今後直接それを参照できるようになるっていうのが 近い未来にあるんじゃないかなという感じですね
でもなんかこの本によると まだダークモード対応とか一部がされてないらしくて
そのツールがね バリアブルズインポートのツールが
kudakurage
てかそもそもなんかW3Cのその草案の方で ダークモードとかそのテーミングがまだ考慮されてないらしいんですよね
なんかねだからこれサンプルで出すんじゃなくて Figmaがプラグインしてるっていうのが
kudakurage
出せばいいじゃんとかさ
思ってたんだけど
Takaya Deguchi
結局今みんながいろいろ作って出してるんで
kudakurage
バリアブルズの
インポートエクスポート用のプラグインみたいなの
みんないろいろ使ってるんだけど
フィグマがやってくれよみたいな気持ち
みんな思ってると思うんだよね
なんでやらないのかなみたいなところが
多分あって
W3Cに関連するトピック
Takaya Deguchi
多分そこがW3Cに関わってるから
フィグマ自身が
kudakurage
そんな感じはするよね
Takaya Deguchi
先回りしてこれがデファクトだみたいな感じの
見え方になるとまずいとかそういうことじゃないのかな
分かんないけど
kudakurage
早く作ってくれよって
普通にさプラグインじゃなくて
Takaya Deguchi
そうなんですよね
kudakurage
バリアブルズのところからダウンロードさせてくれよ
コッケーさせてくれよみたいな
思うじゃん普通に
Takaya Deguchi
結局こういうものって
スタートはデザインから来るわけだから
デザインツール側でそれをカバーしてくれるのが
ベストですよね
kudakurage
さっきのトークン管理ツール
みたいなのもさ
ある程度フィグマでカンバー
後々したらいいんじゃないのって思ってるけどね
やっぱり
全部
Takaya Deguchi
そういう未来結構見えてるから
こういうスタートアップはどうするんだろうと
思いますけど
買収してもらうことが狙いなのかな
kudakurage
ですかね
いろいろ使いやすい機能みたいなのを
作ってるんだろうと思うけど
Takaya Deguchi
そういうのが
今現在っていう感じで
この辺りは本当に
1ヶ月先2ヶ月先で
状況が変わる話かなと
思いますね
全然このW3C周りの話
全然知らなかったんで
確かにこれに最初から準拠しておくのは
結構大事そうだなと思いましたね
あと最後は
チームの中でどう作っていくか
みたいな話がされていて
今までの流れを
どう進めていくかみたいな章で
例えば
スラックで進捗をこだしにして
なるべく一人のものにするっていうのは
みんなで決めていくといいですよとか
あと設計の理由を
なるべく残した方が良いとか
それは確かにすごいそうだなと思って
kudakurage
チームでやる場合はそうだよねやっぱり
Takaya Deguchi
まさにね
前も話したっけ
ちょっと覚えてないけど
クックパッドのデザインシステムを
10年ぶりに刷新するみたいな仕事を
フリーランスでやった時に
当時僕10年前の
多少見てたから
ゼロからゼロの状態だった時はいなかったけど
ゼロからゼロの状態だった時は
多少進捗してから見てたから
デザインツールとトークン管理ツール
Takaya Deguchi
ここはこういう理由なんだろうな
っていうのがすごい
歴史を知ってたからわかったんですけど
それやっぱそういうのがないと
なかなか難しいと思うから
こういう理由を残すっていうのは
すごい大事だなと思いましたね
kudakurage
だからそういう意味でも
やっぱりアベマのスピンドルとかは
めちゃくちゃよくできてるな
一つ一つめちゃくちゃ細かく
ここはこうしてるのかみたいなのを
ちゃんと説明して
後々また別のものを使うとか
作るとか変えていくとかってなった時にも
多分参照しやすいような形で
すごいドキュメントが残ってるんで
すごいなと思いました
Takaya Deguchi
デジタル庁のデザインシステムとかも
やっぱそういうところは
すごいよく考えられてるなと思いますね
あといいなと思ったのは
そもそもデザイントークンに
投資すべきかみたいな話があって
やっぱこう
別にこれを秘密にやったからといって
プロダクトがすごい伸びるわけではないんで
そもそもこう
慎重にしなきゃいけないですね
みたいな話が前提にありつつ
やっぱポイントとなるのは
プラットフォームとテーマの数っていう風に書かれてて
確かになと思って
対応プラットフォームがどれだけあるか
そのプロダクトがね
単一プロダクトであっても
複数プラットフォームに最初から対応するなら
やっぱ投資する価値は出てくると思うし
テーマっていうのが
Takaya Deguchi
モードだけじゃなくて
ひょっとしたらアンドロイドの
アテラエルユーみたいな
パーソナライズみたいなのをするなら
投資する価値あるかもしれないし
あと純粋にプロダクトの数が多かったら
それはやっぱ投資する価値が
どんどん出てくると思うし
そういうやっぱ
冒頭の話に戻るけど
文脈によってそのデジタルプロダクトとか
UIがどう変わっていくのか
っていうのを見極めるのが
やっぱ大事なのかなと思いましたね
うん
kudakurage
結構最近は特にアプリ周りとかだと
なんかもうダークテーマとか
ライトモードみたいなの対応って
なんか当たり前みたいな
なってるようなところが
僕はあるような気がするから
Takaya Deguchi
そうね
kudakurage
そう考えると
割と最初の割と早い段階で
なんか新しく作るっていうサービスとかだったら
もう一番最初は
なんとなく作っていくところから
始まっていくと思うんだけど
ある程度固まってきたら
割ともうその設計していった方が
後々全然楽だなって思うことが
Takaya Deguchi
そうですね
kudakurage
多いから割と早い段階だから
やってるような気はするね
Takaya Deguchi
そうですね
僕もやっぱ
やるやらないのゼロか一かってよりは
やるっていうのが前提なんだけど
その上でどの塩梅で
やる設計するのか
っていうところが大事かなと思います
kudakurage
やりすぎちゃってもねあれだから
結局使わないみたいなのがあったりするとあれだから
ある程度
使うこれは使うだろうなぐらいの
塩梅をなんか
極めてやるみたいなね
Takaya Deguchi
あとなんか
デザインシステムの設計と命名規則
Takaya Deguchi
ちょっとこの本からだいぶ話取れるけど
なんかそのさっきのCookpadの
10年ぶりにデザインシステムを
刷新するって仕事やってた時に思ったのは
その10年先を見越すと
いつかデザインシステムを取り替えるとか
壊すとかそういうことも
見据えないといけないな
というのはすごい思って
例えばすごい
簡単な話だけど
グレップしやすくする
要はソースコードから
そのキーとなる
名前を見つけやすくするみたいな
例えばなんちゃら
デザインシステムの名前を
プレフィックスにつけておくとか
なんかそういうの結構
大事だなと思いましたね
kudakurage
確かにね
Takaya Deguchi
それですごい苦労したから
その仕事やっててね
kudakurage
なかなかないもんねやっぱ
Takaya Deguchi
なかなかないんだけどね
そこまで
kudakurage
なかなかないから
考えないよねやっぱり最初に
Takaya Deguchi
そう考えない
kudakurage
でも確かにね
実装っていう意味では
そういう辺は
意識する必要性はあるんだよね
あるのかもね
Takaya Deguchi
うん
なんか結構取り除きやすくする
探しやすくするみたいな
なんかその辺は
名前考える上で
大事だなと思いましたね
まあなんか
やっぱこの本そうして読んでて
こういう周りの設計って
デザイナー的視点
さっきの
あの四角要素の
要は
あのカラーとかどう決めてくとか
タイプグラフィー
リズム感を持ってどう決めてくとか
そういったデザイナー的視点と
あと命名とか
ビルドとか
なんかそういうエンジニアリング的な視点の
両方が必要だし
あとやっぱこう
デザイントーク見いだす上では
平面的なオンスクリーンのものから
その構造をこう
見いださなきゃいけないと思うんですよ
さっきそれをずっと
こねこね僕らやってるって話をしてたけど
だからその構造をどう捉えるかってのも
人によってとか
人とか力量によって
変わってくるポイントだと思うから
まあだからやっぱこういうのって
デザイナーとエンジニアリング的な視点が
両方持ってる人がこう
やるのが求められるところだし
まあだからこそ難しいんだろうなと
改めて読んでて思いましたね
kudakurage
そうだね
Takaya Deguchi
うん
kudakurage
結局だからね
アウトプットするものは
大して変わんないからね
そのそれをいかに効率よく作るとか
あの変化に強くするとか
そういうことを考えるってとこだからね
Takaya Deguchi
うん
kudakurage
割と
エンジニア的な視点もやっぱ強いんだよな
そういう意味では
Takaya Deguchi
すごい地味だけど
まあ結構面白いかなと個人的には思うんですけどね
kudakurage
まあでも普通にね
あのあのエンジニアリング関係なくて
そのデザイン作っていくっていう上でもさ
やっぱりその辺をある程度一貫性
どうやって持って作っていくかとか
それが一人だったらまだいいかもしれないけど
Takaya Deguchi
チームでやるってなったら
kudakurage
で考えた時には
やっぱある程度その辺を組み立てて
構造化して考えておくっていうのは
必要な部分だと思うけどね
Takaya Deguchi
確かにね
デザインファイル上での構造化というか
kudakurage
そうそうそうそう
みんなが迷わないようにね
命名規則とってもさ
この色を使いたいんだけど
同じような色がいっぱいあるなみたいな
どれ使えばいいんだろうみたいな
あるじゃないですかやっぱり
Takaya Deguchi
そうね
kudakurage
それをどう細分化するのか
分解するのか
まとめるのかっていうのを
どう設計するって話だと思うんだよ
Takaya Deguchi
なんか僕正直エンジニアリング以上に
デザインやってる時に
どこまで構造化するかってところの方が
迷うんだよな
kudakurage
でも分かるよ
僕もだって未だに迷ってるもん
やっぱり
Takaya Deguchi
デザインフェーズの方が
明日してる可能性は高いって考えると
こんな話してるけど
結局
デザイナーモードになって
僕がフィグマ触る時も
ごちゃごちゃのファイルにしたりとかすることあるし
やっぱ難しいですよね
kudakurage
色ってやっぱ難しくて
Takaya Deguchi
難しい
kudakurage
なんで難しいかっていうと
色の
難しいところは
同じ色でも
例えば面積によって
感じ方が違ったりするわけですよ
Takaya Deguchi
確かに
kudakurage
例えばテキストとかで使ってる色と
背景色で使ってる色の見え方って
同じ色でも全然見え方違ったりするわけですよ
っていうところがあるから
そこを定義する時に
分けるべきか
一緒にするべきかとかって考えていくと
結構難しいんですよねやっぱり
Takaya Deguchi
そうですよね
kudakurage
っていうのがあるからね
なかなか
僕も未だに迷ってるんで
ボタンの背景色にするのか
コンポーネントの色にするのか
テキストの色にするのか
それをまとめるのかとか
Takaya Deguchi
別に目の前にいるから褒めるわけじゃないですけど
デザインファイルとエンジニアリング
Takaya Deguchi
歴代いろんなデザイナーと仕事してきて
一番エンジニアリング的に
エンジニア観点で
実装の落としやすいデザインなのは
本山さんのデザインファイルでしたね
kudakurage
本当ですか
多分物によると思うんですけど
僕も適当に作ってるやつもあるからね
Takaya Deguchi
でもそれは思いましたよ
やってて昔
kudakurage
でも別に僕がとかで話じゃなくて
やっぱり一緒に例えばやってる
藤健さんとかさ
そういう人とか
渡辺さんとかも割と綺麗なファイル作ったりするんだけど
Takaya Deguchi
もちろん
kudakurage
実装がどうかは分かんないけど
やっぱりある程度そういう視点がある人は
やりやすいものを作ってるような気はするけど
Takaya Deguchi
それは思います
でも結構やっぱそういう
命名とか構造化のところに
デザイナーのバックグラウンドが出るな
と思って
個人的には
僕立場的にいろんなデザイナーの見るから
そういうのは結構好きではあるんですよね
この人こういう人かな
みたいな想像するの
kudakurage
はいはいはい
確かにね
それは多分僕以上に見てるだろうからな
あんまり一緒に
いろんなデザイナーの人と
関わるんだよな
Takaya Deguchi
あんまり多くはないからねやっぱり
そうですよね
という感じでちょっと長くなっちゃったけど
すごいなんか
デザイントークンとデザインシステム
Takaya Deguchi
結構デザイントークンの話
本当に変わりや
まだまだ今後変わりやすいと思うから
2023年現在の話
っていう感じではあるんだけど
でもこの本すごい実践的で
すごいいい本だなと思ったんで
デザインシステムというか
そういうのに関わる人には
すごいおすすめですね
kudakurage
そうね
設計するときはいいんだろうなやっぱり
Takaya Deguchi
うん
kudakurage
まあでもねデザインシステム系はやっぱり
小さく始めるデザインシステム
はいいなと思いましたね
本としては
Takaya Deguchi
本当僕なんかいろんなところで
最近話してますね
小さくの本もそうだし
銀行とデザインの本もそうだけど
あの辺の方はすごい本当にいいなと思いますね
kudakurage
わかるよめちゃくちゃわかる
Takaya Deguchi
今日はそんなところですかね
お便りと配信情報
kudakurage
今日も
チェイドさんからお便りいただきましたけど
お便りいただいた方には
ご希望の方には
オリジナル付箋をお送りしてますので
ぜひぜひたくさん
ご質問ご感想リクエストなど
いただければなと思います
まあXにポストしていただいてるのも
いつも目に通させていただいてますし
まあ場合によっては
ショーノートにある
お便りのリンクから送っていただければ
配信内で取り入れたりしますので
どしどしいただければと思います
リサイザヘムは毎週金曜日に配信しています
Spotify、Apple Podcast、YouTubeなどで配信していますので
よかったらチェックしてみてください
ということで今回はここまで
また次回お会いしましょう
Takaya Deguchi
さよなら
さよなら
01:22:55

コメント

スクロール