Upgrade to Pro — share decks privately, control downloads, hide ads and more …

なぜ私はコードをデザインに使いたいのか

seya
December 15, 2021

 なぜ私はコードをデザインに使いたいのか

seya

December 15, 2021
Tweet

More Decks by seya

Other Decks in Design

Transcript

  1. by
    seya (@sekikazu01)
    なぜ私はコードを

    デザインに使いたいのか
    @UXPin meetup 2021/12/15

    View full-size slide

  2. 免責
    「コードをデザインに使う」

    ワークフローは実運用で試せていないので、

    居酒屋で夢を語ってるくらいのテンションで聞いていた
    だけますと幸いです。

    View full-size slide

  3. コードをデザインに使うとは?

    View full-size slide

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

    View full-size slide

  5. それで描画した結果が

    デザインツール内で召喚できること

    View full-size slide

  6. これの何が嬉しいの?

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  9. ちなみに現状どんなツールがあるか
    Figma にコードを import する何かとかはその内できそうな気はす
    るが、UXPin Merge みたいに HTML + CSS で描画している訳ではな
    いので限界はありそう。

    (例: Figma の Auto Layout は flex-wrap がない、など)
    以外はなさそう…?

    View full-size slide

  10. 1. 抱えている課題

    View full-size slide

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

    View full-size slide

  12. デザインが実装時に調整されることは
    よくある
    実装しづらい

    デザインだった
    ちょっとした修正を

    コードでやっちゃった
    実機で触ってみたら

    調整したくなった

    View full-size slide

  13. 実装時に変更された後に

    デザインをそれに合わせて修正すること
    =
    デザインをマスター管理すること
    に意味はあるか?

    View full-size slide

  14. 結論、ない(気がする)

    View full-size slide

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

    View full-size slide

  16. 1. 仮説検証のため

    すでに検証済みで実装まで
    進んだものなので、この目
    的には貢献しない

    View full-size slide

  17. 2. 実装者に UI 設計の

    意図を伝えるため

    すでに実装されているもの
    なので、この目的にも使え
    ない

    View full-size slide

  18. デザインをマスター管理することに

    よる強いメリットはなさそう。
    結論

    View full-size slide

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


    View full-size slide

  20. 「いつ」「どうやって」

    役に立つかが読みづらい
    未来にどんな画面が作られて、どんな仮説を検証するかを読
    むことはできないから

    デザインをマスターとして管理する

    ことの ROI が分かりづらい

    View full-size slide

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

    View full-size slide

  22. デザインをしっかり作るのにも

    コストがかかる
    U Auto LayouH
    U コンポーネント(Variants)を実装と同$
    U プロトタイプのメンテナンス

    View full-size slide

  23. 「デザインをどこまで作り込むか」の

    判断は難しい
    これもう…

    実装した方が速くね?

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  26. こんなことを思ったことはないですか?
    うわっ?エンジニアが実装した画面、

    デザインと違い過ぎ…?
    デザイナー の皆さん

    View full-size slide

  27. デザインから意図が読みづらい…
    あれ?状態足りてないな…
    なんでデザインで作ったものを

    もう一回コードで書かなきゃいけないんだ?
    エンジニア の皆さん
    こんなことを思ったことはないですか?

    View full-size slide

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

    View full-size slide

  29. 2.
    打ち手としての

    コードをデザインに使う

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  32. 効用2.
    デザインのメンテナンスは

    (そんなに)頑張らなくて良くなる

    View full-size slide

  33. Web の実装をデザインに使えるから

    ”デザインの実装”が不要になる(?)

    View full-size slide

  34. つまり Figma とかでのデザインがいらな
    くなるってコト!?

    View full-size slide

  35. コードが使えるのは当然ながら

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

    (正直この辺は実運用してみないと自信ない)
    という訳でもない。

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  38. UXPin Merge の例

    View full-size slide

  39. コードベースでデザインすると、

    コードで実現できないデザインは

    作れないというメリット(場合によってはデメ
    リット)もある

    View full-size slide

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

    View full-size slide

  41. 運用上の課題1.
    デザインシステムが必要

    (というかパターンライブラリ)

    View full-size slide

  42. コードで使えるのは既存の資産

    新規のコンポーネントばかりだと価値が
    出づらい

    View full-size slide

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

    View full-size slide

  44. そんなこともなさそう!

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  47. “コード” と一口に言っても 

    Web もあればネイティブアプリもある
    Web のデザイン

    Web の実装
    モバイルのデザイン

    モバイルの実装
    しばらくはこっちしか恩恵を受けられなさそうな香りがする

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  51. ご静聴

    ありがとうございました!

    View full-size slide

  52. 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/
    参考文献

    View full-size slide