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 Slide

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

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

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

    View Slide

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

    View Slide

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

    View Slide

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

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

    View Slide

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

    View Slide

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

    View Slide

  8. わかる

    View Slide

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

    View Slide

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

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

    View Slide

  11. 1. 抱えている課題

    View Slide

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

    View Slide

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

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

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

    調整したくなった

    View Slide

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

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

    View Slide

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

    View Slide

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

    View Slide

  17. 1. 仮説検証のため

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

    View Slide

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

    意図を伝えるため

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

    View Slide

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

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

    View Slide

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


    View Slide

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

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

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

    ことの ROI が分かりづらい

    View Slide

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

    View Slide

  23. View Slide

  24. View Slide

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

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

    View Slide

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

    判断は難しい
    これもう…

    実装した方が速くね?

    View Slide

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

    View Slide

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

    View Slide

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

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

    View Slide

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

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

    View Slide

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

    View Slide

  32. 2.
    打ち手としての

    コードをデザインに使う

    View Slide

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

    View Slide

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

    View Slide

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

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

    View Slide

  36. 再掲

    View Slide

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

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

    View Slide

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

    View Slide

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

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

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

    View Slide

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

    View Slide

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

    View Slide

  42. UXPin Merge の例

    View Slide

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

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

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

    View Slide

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

    View Slide

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

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

    View Slide

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

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

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

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

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

    View Slide

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

    View Slide

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

    View Slide

  54. まとめ

    View Slide

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

    View Slide

  56. ご静聴

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

    View Slide

  57. 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 Slide