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

「機能」に対するデザインと開発の焦点を合わせる

sakito
September 21, 2023

 「機能」に対するデザインと開発の焦点を合わせる

sakito

September 21, 2023
Tweet

More Decks by sakito

Other Decks in Design

Transcript

  1. 「機能」に対するデザインと開発の焦点を合わせる
    フロントエンドの開発生産性〜Online Conference〜「これからのフロントエンドの未来」

    生産性を高めるためにフロントエンドとデザインでそもそも議論したいこと

    View Slide

  2. sakito

    サイボウズ株式会社 | Design Technologist

    2019年に現職のサイボウズに中途入社しフロントエンドエキスパート
    チームに所属、2022年にデザインシステムチームを立ち上げ、2023年か
    ら自社製品であるkintoneのデザイン責任者とデザイン室のリーダーに
    なる。プロダクトと全社のデザイン組織づくりやプロセスの改善がいま
    のお仕事。犬が好き。
    自己紹介

    View Slide

  3. デザイナーとエンジニアで「機能」に対する焦点が異なる

    View Slide

  4. デザイナーとエンジニアで「機能」に対する焦点が異なる
    デザイナー エンジニア
    同じ機能を見ているが、

    焦点が異なると・・・

    View Slide

  5. デザイナーとエンジニアで「機能」に対する焦点が異なるで起きる問題
    p 機能の焦点が異なることでコンポーネントの切り口や独立性に齟齬が生まれY
    p エンジニアが考えてたコンポーネント設計と食い違…
    p データの取得単位やエラーを出す単位などに違いが生まれてくY
    p デザインされたものを実装するコストがあがってくY
    p リリースの遅延につながY
    p これらの焦点の違いは運用を重ねていくほど問題が浮き彫りになってくる

    View Slide

  6. デザイナーとエンジニアで「機能」焦点を当てる

    View Slide

  7. デザイナーとエンジニアで「機能」焦点を当てる - Atomic Designは悪くなかった
    Å 代表的なものとしてAtomic Designがある(いま推し進めたいというわけではない’
    Å コンポーネントをAtoms,Molecules,Organismsに分け、これらを組み合わせて機能を作”
    Å できた機能を組み合わせるTempates,Pagesという概念もあ”
    Å これらのAtomsなどの概念は、デザイナーとエンジニアで粒度を合わせるための共通言語的なものだっ¶
    Å ディレクトリ構成などが綺麗になるのはこれの副次的な効i
    Å うまくいかないの多くの場合に片方だけでやってしまうことがあ”
    Å デザイナー、エンジニアどちらかだけがAtomic Designを取り入れ”
    Å => 「機能」に対する焦点は合っていない => Atomic Design辛g
    Å Atomic Designの目的は自体は悪いものではなかった
    引用元: 

    atomic design

    https://bradfrost.com/blog/post/atomic-web-design/

    View Slide

  8. デザイナーとエンジニアで「機能」焦点を当てる - 一緒にドキュメントを書く
    i デザインができた段階で振る舞いと機能についてドキュメントを書くと認識が揃うコミュニ
    ケーションができt
    i デザイナーとエンジニアでコミュニケーションが発生する部分をテンプレートにしてお
    i インタラクションの挙動、機能が動作する、データ取得の単位...et—
    i 機能名や要素名へa
    i ドキュメントという中間生成物をきっかけにデザインと実装の観点を盛り込む

    デザイナー エンジニア
    ドキュメント
    エンジニア観点
    デザイナー観点

    View Slide

  9. デザイナーとエンジニアで「機能」焦点を当てる - 一緒にドキュメントを書く
    ‘ ドキュメントと機能コンポーネントがあることで一種のコンポーネントライブラリが作成できX
    ‘ コンポーネントライブラリやデザインシステムは1つだけである必要はなp
    ‘ プロダクト全体を包括する全体的なコンポーネントライブラリ、デザインシステd
    ‘ 各プロダクト毎に存在するローカルのコンポーネントライブラリ、デザインシステd
    ‘ ドキュメントと機能セットができることで、全体と各チームのローカルの行き来が可能になる
    参照元:Design System Tiers 

    https://medium.com/eightshapes-llc/design-system-tiers-2c827b67eae1

    View Slide

  10. デザイナーとエンジニアで「機能」焦点を当てる - Figma
    p Figmaのプロトタイプ機能でEventの発火などを
    含んだ条件分岐ができるようになっX
    p デザイナーがFigmaで作ったUIに対して、エン
    ジニアがFigmaのプロトタイプを作ってみると
    認識を合わせることができg
    p ノーコードで作成できるので、コードを書い
    たあとよりも認識の齟齬に気づいた時の手戻
    りが早い場合があg
    p エンジニアもFigmaを使えるようになっておく
    とお得
    参照元:Free Prototyping Tool: Build Interactive Prototype
    Designs | Figma

    https://www.figma.com/prototyping/

    View Slide

  11. まとめ
    y デザイナーとエンジニアの焦点を合わせるのは、プロダクトを運用するにあたって、

    双方にメリットがあ1
    y コミュニケーションを取るための共通言語をつくっていこう!


    詳しい話はこの後のディスカッションで...!!!

    View Slide