yuheijotaki.com

【イベント】Front-End Study #4「いま考えるユーザー体験とデザイン」

ForkwellさんのオンラインイベントFront-End Study #4「いま考えるユーザー体験とデザインの世界」を視聴しました。
フロントエンドエンジニアがデザインとどう向き合うべきかという興味のあるテーマの中で各セッションを聞けたので、メモと感想を残しておきます。

セッション

  • 基調講演「フロントエンドエンジニアが今学ぶべきデザイン」
  • セッション1「共創するためのデザイン批評」
  • セッション2「サービス横断デザインシステムのフロントエンド開発に携わって学んだこと」

基調講演「フロントエンドエンジニアが今学ぶべきデザイン」

サイバーエージェント 谷さん
発表Figma： https://www.figma.com/file/a4m5ohTjU6JWZ80CGVTAMd/Front-End-Study-%234?node-id=44%3A103

FLOCSSのは知ってましたが、魅せるiPhoneサイトもこの方だったんですね。昔とてもお世話になりました。
スマホのリキッド実装と拡縮実装の両方どっちが正解やスタンダードが分からなくて、本読んで腑に落ちた記憶があります。

フロントエンドエンジニアができること

マイクロインタラクション

表現としてのエフェクトはデザイナー
ただリアクションには多くの領域が含まれる（VoiceOverに対してなど）のでエンジニア側も一緒に考える必要。

レイアウト

ずれているのが問題というより設計された情報の意味や狙っている効果がなくなることが問題
そうならないために「デザイン」をプロセスとして遡る必要がある
レイアウトの意図、情報構造の設計を理解してそれに適したマークアップをする

パフォーマンス

Core Web Vitals（LPC/FID/CLS）
CLSの向上は実装する段階ではもうどうしようもないこともある
状態ごとのパターンのデザインを作る

デザインへの接し方

  • デザインの批評・レビューをする
  • デザインの仕組みをつくる
  • UIデザインのアプローチを変える
  • デザインツールを使ってみる

デザイナーとフロントエンジニアのデザインの境界はない
職務ではなく役割として考える

質疑応答

Q.異なる職種でやってよかったこと、うまくいかなかったこと
新規のタイミングからみんなでFigmaに向かいあってやるとよい
デザイナーは途中経過のものは見られたくないみたいな感覚が初期はあるがそこを1回乗り越える

感想

レイアウトのところでピクセルパーフェクト論ではなく、伝えたいことが伝わるかが大事というところでちょっとハッとしました。
自分はデザイナーの意図汲んでコーディングするの得意と思ってますが、完璧に再現できるのが大事というよりは本質的にユーザーに届くかが大事だなと思って今後はその視点でやっていこうと思いました。
Figmaの使い方にちょっと触れていましたが、考えてみたらこれワイヤーとデザイン並行で同じところに描けるのでおもしろいですね。

セッション1「共創するためのデザイン批評」

ClassDo takanoripさん
スライド： https://speakerdeck.com/takanorip/gong-chuang-surutamefalsedezainpi-ping

デザイン批評の基本

デザインがプロダクトの目的を達成するために適切かどうかを判断する
批評には適切な方法がある

デザイン批評とデザインレビューの違い

  • デザイン批評：デザインが目的を達成できるか判断するための分析手法
  • デザインレビュー：デザインの承認や合意形成のために行われるミーティング。

ベストプラクティス

  • 質問で始める
  • 感情のままに話さない
  • 自分の意見が正しいと思い込まない
  • 意見を押し付けない
  • 長所について話す
  • 「誰の視点から考えているか」を考える

おおまかにスタンスとしてはコードレビューと同じですね

見た目にとらわれない = 見た目の好き嫌いを表明することは「批評」ではない
エンジニアがデザインに口出しし辛い風潮があるのは見た目に意識が行っているからで、本質に焦点を当てることが必要になる

デザイン批評

  • デザインの目的を理解する
    • なぜこのデザインにしたのか、これがレビューの「基準」になる
  • 使いやすさを確認する
    • 達成したいことを迷わず達成できるか
  • ダークパターンになっていないか

デザインレビューで考慮すべきポイント

  • UIの一貫性（一貫性のないデザインを鵜呑みにしない）
    • スタイル
    • コンポーネントの役割
    • インタラクション
  • 実装難易度
    • 本来はデザインつくる前に確認する
  • データとUI
    • データ構造とUIに矛盾がないか

みんなではじめるデザイン批評 はデザイナーもエンジニアも読んだほうが良い

感想

どこからどこまでがデザイン批評と定義されどういうメリットがあるのか話されていたのでその点が一番勉強になりました。
見た目にとらわれない、っていうのはなるほどなあと。
ある程度慣れが必要とも感じますがデザイン確認するとき基本実装可否についての確認に留まってしまっていましたが、もうちょっと踏み込んでやってみようと思いました。

セッション2「サービス横断デザインシステムのフロントエンド開発に携わって学んだこと」

ヤフー 春野さん
ヤフーのデザインシステム「Riff」の開発においての話

デザインシステムを作る目的

  • UIデザインの品質向上
    • デザインの当たり前品質を担保する
  • UIデザインの業務効率化
    • 車輪の再開発を防ぐ

制作物としてはスタイルガイドとUIライブラリに分けられる

デザインシステム制作の流れ

  • スタイルガイド制作グループ
  • UIデザインキット制作グループ

  • コーディング開発グループ それぞれ5名程度、兼務でジョイン

  • プロダクト側へヒアリング

  • 必要なスタイルガイド、コンポーネント洗い出し

取り入れているツール

React/TypeScript/StoryBook
ビジュアルのテストツールには reg-suit
これはVRT（ビジュアルリグレッションテスト）というものでビジュアル面のテストが行える
reg-suitは変更前と変更後のキャプチャを撮って差分を確認できる

感想

ビジュアルリグレッションテスト、初めて知りましたが便利そうで使ってみたいですね。
デザインシステム制作チームの人員ってYahooでもだいたい兼務でということだったので結構大変そうだなと・・・
最後にメインの仕事のノウハウ持ってこられるというのを聞いてメリットもあるなあと感じました。

全体感想

一応括りはフロントエンドの勉強会で視聴人数はそこまでなかったと思いますが、平日夜にオンラインで1000人規模で興味持たれるイベントもすごいよなあと感じました。スポンサーもついてライトなTV番組みたいです。
全体としては、登壇した方々は自分と同じフロントエンドエンジニアという職種で、組織として個人としてデザインへの関わり方の熱量がちょっと違うなというところでモチベーションが高まりました。自分ももともとデザインから入った世界というのもあり、そこにもっと向き合う必要がありそうです。

次回もなかなかつよつよなメンツなので参加してみたいと思います。