Tweet
Tweet

Slide 1

Slide 1 text

by seya (@sekikazu01) なぜ私はコードを デザインに使いたいのか @UXPin meetup 2021/12/15

Slide 2

Slide 2 text

免責 「コードをデザインに使う」
 ワークフローは実運用で試せていないので、
 居酒屋で夢を語ってるくらいのテンションで聞いていた だけますと幸いです。

Slide 3

Slide 3 text

コードをデザインに使うとは？

Slide 4

Slide 4 text

こんな React コンポーネントがあるとして

Slide 5

Slide 5 text

それで描画した結果が
 デザインツール内で召喚できること

Slide 6

Slide 6 text

これの何が嬉しいの？

Slide 7

Slide 7 text

もう実装されたものはデザインにも あるはずだから意味なくね？

Slide 8

Slide 8 text

わかる

Slide 9

Slide 9 text

が、実は様々なユースケースが考えられます。 そんな訳でこのトークでは次のことを語っていきます u 私が悩んでいるこa u それを「コードをデザインに使うこと」がどう解 いてくれるのA u 運用上の課題

Slide 10

Slide 10 text

ちなみに現状どんなツールがあるか Figma にコードを import する何かとかはその内できそうな気はす るが、UXPin Merge みたいに HTML + CSS で描画している訳ではな いので限界はありそう。
 (例: Figma の Auto Layout は flex-wrap がない、など) 以外はなさそう…？

Slide 11

Slide 11 text

1. 抱えている課題

Slide 12

Slide 12 text

課題1. デザインのマスター管理がめん どくさい

Slide 13

Slide 13 text

デザインが実装時に調整されることは よくある 実装しづらい デザインだった ちょっとした修正を
 コードでやっちゃった 実機で触ってみたら
 調整したくなった

Slide 14

Slide 14 text

実装時に変更された後に デザインをそれに合わせて修正すること = デザインをマスター管理すること に意味はあるか？

Slide 15

Slide 15 text

結論、ない(気がする)

Slide 16

Slide 16 text

デザインを作る目的を考える 1. 仮説検証のため 2. 実装者に UI 設計の意図を伝えるため

Slide 17

Slide 17 text

1. 仮説検証のため ↓ すでに検証済みで実装まで 進んだものなので、この目 的には貢献しない

Slide 18

Slide 18 text

2. 実装者に UI 設計の
 意図を伝えるため ↓ すでに実装されているもの なので、この目的にも使え ない

Slide 19

Slide 19 text

デザインをマスター管理することに
 よる強いメリットはなさそう。 結論

Slide 20

Slide 20 text

ただし…役に立つこともなくはない a 全体感を持って眺めたい時に便Q a 新しい画面を作るときに再利用しやすくな2 a サービス全体の一貫したプロトタイプが作れる


Slide 21

Slide 21 text

「いつ」「どうやって」
 役に立つかが読みづらい 未来にどんな画面が作られて、どんな仮説を検証するかを読 むことはできないから ↓ デザインをマスターとして管理する
 ことの ROI が分かりづらい

Slide 22

Slide 22 text

課題2. デザインをちゃんとメンテナンス するのがめんどくさい

Slide 23

Slide 23 text

No content

Slide 24

Slide 24 text

No content

Slide 25

Slide 25 text

デザインをしっかり作るのにも
 コストがかかる U Auto LayouH U コンポーネント(Variants)を実装と同$ U プロトタイプのメンテナンス

Slide 26

Slide 26 text

「デザインをどこまで作り込むか」の
 判断は難しい これもう…
 実装した方が速くね？

Slide 27

Slide 27 text

課題3. ハンドオフがスムーズじゃない

Slide 28

Slide 28 text

ハンドオフとは？ 実装可能な状態になったデザインをエンジニアに手渡し、 実装し始めてもらうプロセスのことです

Slide 29

Slide 29 text

こんなことを思ったことはないですか？ うわっ？エンジニアが実装した画面、
 デザインと違い過ぎ…？ デザイナー の皆さん

Slide 30

Slide 30 text

デザインから意図が読みづらい… あれ？状態足りてないな… なんでデザインで作ったものを
 もう一回コードで書かなきゃいけないんだ？ エンジニア の皆さん こんなことを思ったことはないですか？

Slide 31

Slide 31 text

デザインの意図がしっかり伝わるのは大変 デザインとコードは違う構造で作られるので 必ず齟齬が生まれる

Slide 32

Slide 32 text

2. 打ち手としての コードをデザインに使う

Slide 33

Slide 33 text

効用1. 実装されたものをデザインに使え るので、同期する必要がなくなる

Slide 34

Slide 34 text

頑張ってデザインをマスター管理しなくて も、いつでもコードから最新のものを持っ て来れるように 最新！ デザインに使う

Slide 35

Slide 35 text

効用2. デザインのメンテナンスは
 (そんなに)頑張らなくて良くなる

Slide 36

Slide 36 text

再掲

Slide 37

Slide 37 text

Web の実装をデザインに使えるから
 ”デザインの実装”が不要になる(?)

Slide 38

Slide 38 text

つまり Figma とかでのデザインがいらな くなるってコト！？

Slide 39

Slide 39 text

コードが使えるのは当然ながら
 既に実装されたものだけ i 新規のページやコンポーネントは Lo-Fi なデザインツールでまず作c i 既存の資産で作れる部分は初手か ら Hi-Fi なプロトタイプが作れる という形で用途に応じて使い分 けるスタイルになりそう。 (なので”デザインの実装”も結局幾分か必要な予感)
 (正直この辺は実運用してみないと自信ない) という訳でもない。

Slide 40

Slide 40 text

効用3. ハンドオフが楽 & 確実に

Slide 41

Slide 41 text

だってコードを使っているんだもの

Slide 42

Slide 42 text

UXPin Merge の例

Slide 43

Slide 43 text

コードベースでデザインすると、
 コードで実現できないデザインは
 作れないというメリット(場合によってはデメ リット)もある

Slide 44

Slide 44 text

3. 実際に使う上での課題

Slide 45

Slide 45 text

運用上の課題1. デザインシステムが必要
 (というかパターンライブラリ)

Slide 46

Slide 46 text

コードで使えるのは既存の資産
 新規のコンポーネントばかりだと価値が 出づらい

Slide 47

Slide 47 text

つまり、それなりに成熟したプロダク トでないと使えないのか…？

Slide 48

Slide 48 text

そんなこともなさそう！

Slide 49

Slide 49 text

汎用的なコンポーネントライブラリで作る 前提なら初期開発フェーズから使えそう。 MUI Chakra UI Ant Design

Slide 50

Slide 50 text

運用上の課題2. 複数プラットフォームでのワーク フローは難しいかも？

Slide 51

Slide 51 text

“コード” と一口に言っても 
 Web もあればネイティブアプリもある Web のデザイン ↓ Web の実装 モバイルのデザイン ↓ モバイルの実装 しばらくはこっちしか恩恵を受けられなさそうな香りがする

Slide 52

Slide 52 text

運用上の課題3. ワークフローが複雑になりそうな 予感がする

Slide 53

Slide 53 text

新規の画面を作る時に既存の資産で作れるか/作れないか 作れない場合、新規の要素をデザインシステムに組み 込むか (これはどちらにしろデザインシステム運用する上で発生するタスクな気 がするけど) のような分岐が発生するため、開発時のオーバーヘッド にならないためにワークフローは工夫して設計する必要 がありそう

Slide 54

Slide 54 text

まとめ

Slide 55

Slide 55 text

x コードをデザインは「システム化されたデザイン」 の実装を一元化できs x どんなシーンで有効そう$ x デザインシステムがそれなりに発達しているとこ ろでのプロトタイプ・デザイン作a x コンポーネントライブラリを採用しているとこ ろでの初期の爆速開% x デザインシステムを作ろう x みんなも試して知見をシェアしてみよう☝️

Slide 56

Slide 56 text

ご静聴 ありがとうございました！

Slide 57

Slide 57 text

How PayPal Scaled Their Design Process with UXPin Merge https://www.uxpin.com/studio/blog/paypal-scaled-design-process-uxpin-merge/ ここがすごいぞUXPin Merge | 8つのポイントを紹介 https://qiita.com/xrxoxcxox/items/1a806f85e2a586b87634 Bridging The Gap Between Designers And Developers https://www.smashingmagazine.com/2021/10/bridging-gap-between-designers-developers/ 参考文献